[mysql] ordernummers maken

auto_increment?

En dan dat als id gebruiken bij het aanmaken van entries in je Order<>Product tabel.

Misschien een autoincrement veld maken, en dat toevoegen aan de datum bij het aanmaken van de order?

kun je niet iets maken met de rand functie
php heeft in iedergeval een rand(); functie
mischien is het ook makkelijk je script taal te vermelden want ik denk dat je dit in je scripts moet doen en niet in je mysql database



zoiets zouw in php een getal van tussen de 0 en 99999 opleveren die je aan je ordernummer kan prakken.

maar iedere order heeft toch een unieke rij met een id als ik het goed heb ???
dan kun je iets van jaar+maand+rijnummer = uniek nummer

auto_increment is hier niet echt mooi omdat die altijd op zal blijven tellen, terwijl je maandelijks weer bij 1 kan beginnen, niet waar?

RSD schreef op 03 september 2004 @ 00:40:
Daarnaast als de order uit meerdere produkten bestaat, staan er meerdere rijen met hetzelfde ordernr. Dit is samen 1 order. Hoe kan ik het nu zo krijgen dat elke order een uniek nummer krijgt.

Maar ik neem aan dat je een tabel hebt met alle ordernummes en een tabel met de producten die bij een order(nummer) hoort?

Ja, je zou de seconde van de dag (of maand dus) kunnen nemen.

Ik zie het een beetje als de forumsoftware vBulletin. Die heeft 1 tabel met de threads en 1 met alle posts. alle posts hebben een threadID. Zo query je alle posts die bij de thread hoort.
Het voordeel hiervan is dat je de specifieke thread (order) informatie als poster (klantnummer) etc maar 1x hoeft op te slaan en niet per product dat onder de order valt.

[ Voor 75% gewijzigd door Room42 op 03-09-2004 00:56 ]

je kunt gewoon time() gebruiken voor je ordernrs (da's een system call, geloof dat PHP hetzelfde doet.) Je krijgt dan het aantal seconden sinds 1 januari, 00:00 1970. Je moet dan alleen even opletten dat je niet de mist in gaat als er in dezelfde seconde twee orders geplaatst worden.

RSD schreef op 03 september 2004 @ 00:57:
Misschien dan idd time() gebruiken en dan daar nog een random nummer achter plakken. Dan is de kans heel klein dat in de zelfde tijd dat ordernr gepakt wordt.

Maar wel aanwezig. En als het kan gebruren, dan zal het, volgens Murphy's law ook vroeg of laat gebeuren.

Je zult dus eerst moeten checken of het ordernummer nog niet bestaat.

Even een select op de database doen om te kijken of het al bestaat voordat je het aanmaakt, en zolang dat nummer bestaat opnieuw een random getal maken...

hangt er een beetje vanaf hoe druk je je DB gaat gebruiken. Hoe vaker je ordernummers toevoegd hoe groter de kand dat er een dubbele in komt.

time() is misschien wel een oplossing maar ook wel heel dubbel als je ook al jaar en maand in het ordernummer hebt staan.

waarom niet ordernummer_ID als primary key met auto_increment in de database en als tweede kolom 'datum' die bestaat uit jaartal plus maand? het ordernummer dat je dan in het bedrijf gebruikt is een combinatie van die twee kolommen.

Een order bouw je op met 2 tabellen:
- Order (heeft een veld ID)
- OrderDetail (heeft een veld OrderId)

Wil je 1 order opvragen dan doe je dat door het volgende SQL Statement:

SELECT * FROM Order INNER JOIN OrderDetail ON (Order.ID = OrderDetail.OrderId) WHERE Order.ID = x

x is dus het order is dat je wil opvragen.

ivm die autonummering:

Je doet eerst ff een SELECT van je laatste order van die dag
(SELECT TOP 1 ID FROM Order WHERE Order.ID = JaarMaandDag% ORDER BY Order.ID DESC)

Tel daar 1 bij op en voila, je hebt je volgende uniek nummer.

PS: Deze methode is niet 100% te vertrouwen als je met veel users zit die tegelijk orders aanmaken. ff een voorbeel waar het fout kan lopen.

Gebruiker A vraagt laatste Order ID op = 20042903013
Gebruiker B vraagt laatste Order ID op = 20042903013
Gebruiker A plaatst een nieuw order met ID 20042903014 (= 20042903013 + 1)
Gebruiker B plaatst een nieuw order met ID 20042903014 (= 20042903013 + 1)
=> hier loopt het dus fout

Wil je dit probleem opvangen moet je het programma zo schrijven dat wanneer er een order wordt weggeschreven en er zich een fout voordoet ( 2 dezelfde ID's), terug het laatste Order ID opvraagt en herprobeerd dit weg te schrijven in de database.

Is het ook niet een idee om de User-ID van degene die de order aanmaakt, op te nemen in de order-ID?

Zoiets als [20040903(auto-incr-num)User-ID], aangezien een User nooit op EXACT hetzelfde moment een zelfde order aan zal maken, of maak ik hier nu een denkfout?

Mja, 't kan ja. Maar waarom zou je 't willen? Het is maar een nummertje hoor, de enige voorwaarde eraan is dat 'ie uniek moet zijn. Valt op te lossen door 'm in je ordertabel als primary key te definieren.

Je hebt helemaal gelijk Cyber, ik was ff de basisregels van t Normaliseren vergeten.

Maar heeft dit dan ook niet te maken met 'table-locking' en dat soort zaken? (wat de DB-engine ook moet ondersteunen uiteraard). Nouja, als het een Primary key is, dan is er uiteraard niets aan de hand, want zoals men weet is een Primary NOT NULL en UNIQUE

Ja, je moet em zowiezo de primary of unique-flag meegeven.

[ Voor 31% gewijzigd door Room42 op 03-09-2004 02:40 ]

Heel belangrijk puntje wat vaak over het hoofd gezien wordt in allerlei tutorials etc... Als men een ordernummer net zo ziet als een factuurnummer moet je van de belastingdienst er altijd voor zorgen dat je ordernummers een niet onderbroken reeks zijn.

Een factuur dient een uniek factuurnummer te bevatten. Het factuurnummer dient opeenvolgend te zijn, met één of meer reeksen, waarmee de factuur eenduidig wordt geïdentificeerd

Je kunt dus niet zomaar een uniek nummer genereren. En je moet ervoor zorgen dat een eenmaal aangemaakt nummer nooit meer verwijderd kan worden.

Wat je bijvoorbeeld ziet in een voorbeeld applicatie als de Northwind database van MS Access is dat men een factuurnummer genereerd op het moment dat er een nieuwe order wordt aangemaakt. Als het aanmaken van de order gecancelled wordt, dan wordt er de eerstvolgende keer weer een ander nummmer gegenereerd. Volgens de regels mag dit dus niet, want dan komt er een gat in de reeks.

[ Voor 25% gewijzigd door kaandorp op 03-09-2004 09:58 ]

Room42 schreef op 03 september 2004 @ 00:51:
auto_increment is hier niet echt mooi omdat die altijd op zal blijven tellen, terwijl je maandelijks weer bij 1 kan beginnen, niet waar?

Ja, als je wel de jaar+maand voor het nummer plakt, anders krijg je geen unieke nummers. Maar imo is een autoincrement toch het mooiste. Je kan hem ook een sprong laten maken bij een nieuwe maand, maar dan krijg je dus echt gaten in je reeks ordernummers.

Gewoon een order maken met order_id (autoincrement, primary key), klant_id, datum, status, etc. En daarna een tabel met rijen van diezelfde order_id, met product_id, etc vullen.

Een ordernummer is een abstractie, als je die betekenis gaat geven door er een daum in te verwerken oid ben je imo niet handig bezig. Gewoon lekker 1 reeks maken.

NB: En een key maken dmv een random generator is helemaal ranzig.