Beoordeling simpel database ontwerp
Ik ben bezig met het opstellen van een simpele webshop die uiteindelijk ook ingezet zal gaan worden. Ik heb zojuist een database ontwerpje gemaakt en vroeg mij af of jullie nog op of aan merkingen hebben/hadden.
http://www.imgmonster.com/uploads/d6e300688350e82ab72f95a0fe27abc2.jpg
userActivated is hier een veld wat een 1 of een 0 kan bevatten, bij een 1 heeft de gebruiker geactiveerd.
userAdmin kan ook 1 of 0 bevatten, simpel rechten systeem dus.
productCat = productCategory
basketOrderDate wordt pas ingevuld wanneer iemand afrekent, is die nog null dan is het dus nog een winkelwagen artikel.
basketCode wil ik gebruiken als code die men als betalingskenmerk moet gebruiken bij het overboeken van het geld.
Dat is de huidige opzet, mochten er dingen niet geheel duidelijk zijn dan hoor ik dat graag.
Ik zet verder nog met het probleem dat het kan zijn dat een bepaald product in meerdere maten en/of kleuren beschikbaar is, hoe kan ik dat het beste aanpakken?
Gewijzigd op 01/01/1970 01:00:00 door Nils Kuijpers
Ik neem aan dat je een sha1 hash van het wachtwoord opslaat (het daadwerkelijke wachtwoord hoef je niet op te slaan, en is eigenlijk alleen maar onveilig) Een sha1 hash is altijd 40 karakters lang, dus dan zou je CHAR(40) als type voor dat veld kunnen gebruiken.
Het is met webshops altijd wat lastig waar je de prijs moet opslaan. Stel dat je de prijs opslaat in de product-tabel, en op maandag koopt iemand een product. Nu verander je de prijs op woensdag, en nu komt dat wat je op maandag op de factuur van iemand hebt gezet niet meer overeen met dat wat er in je database staat. Misschien is het daarom wel handig om in die koppeltabel waar ik het eerder over had ook de prijs van het product op te slaan.
Speciale eigenschappen zou je op een ingewikkelde manier aan producten, en aan de koppeltabel kunnen toekennen, iets a la:
product_eigenschap_categorieen
- id (1)
- naam
product_eigenschappen
- id (2)
- product_id (3)
- categorie_id (1)
- waarde
- prijs (6)
producten
- id (3)
~ de rest ~
mandjes
- id (4)
- user_id
- ordered_on
mandje_producten
- id (5)
- mandje_id (4)
- product_id (3)
- prijs
mandje_product_eigenschappen
- mandje_product_id (5)
- product_eigenschap_id (2)
- prijs (kopie van 6 op het moment van toevoegen)
Maar zoals je al ziet wordt dit nogal ingewikkeld. Je zou het ook via serialize als string op kunnen slaan in de producten-tabel en in de mandje_producten-tabel, dan ben je al die eigenschap-tabellen weer kwijt. Nadeel is dan wel dat je de controle die de database je kan bieden weer kwijt bent, maar juist die controle is iets lastigs. Want wat doe je wanneer een bepaalde eigenschap van een product verandert of vervalt? Om je oude mandjes op orde te houden zou je kopieën kunnen maken van de eigenschappen in de mandje_product_eigenschappen koppeltabel, of je moet de eigenschap niet uit de product_eigenschappen tabel gooien, maar simpelweg onzichtbaar maken. Dat laatste is het mooist, en dat zou je misschien ook wel kunnen doen voor de producten zelf wanneer ze veranderen. Een extra original_id in de producten-tabel zou je kunnen gebruiken om revisies van bepaalde producten terug te vinden, om zo nog beter de relaties in de database te kunnen bewaren.
edit: misschien is zo'n soort opzetje wel het mooist:
producten
- id
- vervanger_id (DEFAULT NULL)
~ allemaal eigenschappen, beschrijving etc. ~
- prijs
- eigenschappen
- aangemaakt_op
- vervallen_op
winkelmandje
- id
- user_id
- aangemaakt_op
- verzonden_op
winkelmandje_producten
- id
- product_id
- eigenschappen
- winkelmandje_id
- toegevoegd_op
Alle koopbare producten:
SELECT * FORM producten WHERE vervanger_id IS NULL
Product veranderen:
INSERT INTO producten (...) VALUES (...)
UPDATE producten SET vervanger_id = @last_inserted_id WHERE id = @origineel_product_id
Wanneer je nu de prijs verandert (en daarvoor een INSERT in de producten
tabel doet) verandert er niet zomaar iets in de oude winkelmandjes.
Ik vind het zelf altijd wel prettig om bij alle inserts sowieso een DATETIME te
hebben. Op die manier kan je vrij gemakkelijk een bepaalde periode bekijken voor
statistieken, of bepaalde rows verwijderen wanneer er in een bepaalde periode
iets heel erg fout is gegaan.
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -