[Conny Westh]

När man modellerar en databas så ska man se till att alla värden är atomära, dvs odelbara i sin grundform, dvs man skriver tiltalsnamn för sig och efternamn för sig, postnr för sig och postort får även det en egen kolumn.

Värsta skräckexemplen jag sett är när man lagt ihop förnamn, efternamn, gatuadress, postnr, ort, land i samma kolumn..... hjärnsläpp, hur ska man då hantera ett urval på kunder som har ett visst postnr eller bor på en speciell ort?


Viktigt att man döper alla kolumner till unika namn för annars kan man få problem vid joinar av flera olika tabeller. Man kan slarva lite här med främmande nycklar, men det får man leva med.

När man döper en tabell ska man döpa den i singularis exempelvis tabellen Order och Orderrad, plural använder man i de transienta listorna Exempelvis i C# skulle man kunna deklarera

List<Order> orders = new List<Order>();

(om vi kör med engelska i koden).

Om man har en räknare som Primärnyckel i Order-tabellen så bör den heta orderID eller orderNr och inte enbart id, eftersom id då kommer att komma i namnkonflikt med id i Faktura-tabelen om man gör en join mellan dem. Visserlign kan man använda ett alias på kolumnen vid en join men man ska ha som princip att alltid försöka skapa så stabila datastrukturer som möjligt i databasen för den kommer leva under många år och det kommer troligen att byggas många stödsystem runt, denna databas, då vill man ha konsekvent namnsättning och tydlighet och definitivt inga namnkonflikter.

Använd naturliga primärnycklar om det finns, det underlättar enormt om man kan få en koppling till en extern datakälla med uppdateringar. För att ta ett enkelt exempel så är postnummer en extern datakälla då det är typ posten som uppdaterar dem. Då är det ju smidigt om man kan få en uppdateringa av dem och med ett enklt SQL-script kan uppdatera hela min databas genom att koppla ihop mina kunders adresser med ett enkelt postnummer.

[sca]

ConnyWesth: Jag tackar så enormt mycket för din Feedback. Den kommer hjälpa mig och säkert många andra som befinner sig i likvärdig situation som jag. Infon är guld värd.

Om jag tänker så här när det gäller momentet order:

order_tbl -> Ska innehålla grundläggande information och tilldela ordern ett ordernummer.
För att detta ska vara möjligt har jag funderat ut en lösning likt rutinen:

Ett PHP-script tar infon från vem som handlar och skjuter i denna infon (adresser och övriga kunduppgifter) i order_tbl och vi får då även ett order_id (som är satt till primary key på auto-update).
När PHP-scriptet fortsätter att exekveras tar den ut order_id't från order_tbl och placerar detta numret tillsammans med alla de produkterna som kunden har beställt vid detta tillfälle.

Är det en bra lösning?

Samtidigt undrar jag hur man kan göra för att motverka att om två kunder beställer vid samma tidpunkt så att de inte får upp den andras beställning på grund av extremt minimalt tidsspann. Så här tänker jag:

Kund 1 lägger en beställning 23:50:00
Kund 2 lägger en beställning 23:50:01

Det jag tänker på är att när scripten körs så blir det ett visst spann och säg att kund två lägger sin beställning precis innan scriptet för kund 1 ska hämta order_id't kan det ju bli så att den hämtar kund 2's order id. (Om scriptet väljer att hämta det senaste order-id't i tabellen.) Teoretiskt är det ju en risk, men hur stor är chansen att detta händer om man gör så eller finns det ett annat tillvägagångssätt?

Jag hoppas ni hänger med på vad jag menar.

[jonny]

Ett gott råd till sca är att läsa på ordentligt om databasdesign eftersom inläggen anger att det är mycket kvar att lära där