Zoals al duidelijk is uit de titel ben ik bezig met een database te ontwerpen voor een shop die ik ga maken 
. De bedoeling is dat als je bijvoorbeeld een artikel gaat toevoegen aan een categorie van de shop, je zelf kenmerken via een admin gedeelte kunt toevoegen.
Dus stel dat ik een t-shirt wil verkopen, dan moet ik in mijn admin een optie zoals kleur, maat kunnen opgeven. En aan die opties moet dan dus de keuzes ook zelf kunnen verzinnen..
Ook wordt het de bedoeling dat je meteen bij die optie een input mogelijkheid kunt geven. Dus of je een select field, of text field oid erbij wilt gebruiken. Ik heb hierbij deze database geschetst:
Dit zijn dus mijn 3 tables waarin alle opties inkomen. Dit kan in de admin worden toegevoegd.
Dit is de table waar alles bij elkaar komt. art_id is het id van het product waar nog een aparte table van is.
Als jullie uit dit wazige verhaal komen wil ik graag jullie mening hierover. Is dit wel efficient genoeg? (omdat ik van zoveel losse tables gebruik maak). En zoniet, wat kan ik eraan veranderen? 
. De bedoeling is dat als je bijvoorbeeld een artikel gaat toevoegen aan een categorie van de shop, je zelf kenmerken via een admin gedeelte kunt toevoegen.Dus stel dat ik een t-shirt wil verkopen, dan moet ik in mijn admin een optie zoals kleur, maat kunnen opgeven. En aan die opties moet dan dus de keuzes ook zelf kunnen verzinnen..
Ook wordt het de bedoeling dat je meteen bij die optie een input mogelijkheid kunt geven. Dus of je een select field, of text field oid erbij wilt gebruiken. Ik heb hierbij deze database geschetst:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| +-------------------+ | Opt_Name Table | +----+--------------+ | id | naam | +----+--------------+ | 1 | maat | | 2 | kleur | | 3 | eigen tekst | +----+--------------+ +-----------+ | Opt Table | +----+------+ | id | naam | +----+------+ | 1 | xl | | 2 | l | | 3 | rood | +----+------+ +-------------------+ | Input Type Table | +----+--------------+ | id | naam | +----+--------------+ | 1 | select | | 2 | box | | 3 | text | +----+--------------+ |
Dit zijn dus mijn 3 tables waarin alle opties inkomen. Dit kan in de admin worden toegevoegd.
code:
1
2
3
4
5
6
7
8
9
| +-----------------------------------------------+ | Combi (table waar alles bijelkaar komt) | +----+--------+----------+--------+-------------+ | id | art_id |opt_nm_id | opt_id | inp_type_id | +----+--------+----------+--------+-------------+ | 1 | 1 | 1 | 2 | 1 | | 2 | 1 | 1 | 3 | 1 | | 3 | 1 | 2 | 1 | 2 | +----+--------+----------+--------+-------------+ |
Dit is de table waar alles bij elkaar komt. art_id is het id van het product waar nog een aparte table van is.
Als jullie uit dit wazige verhaal komen wil ik graag jullie mening hierover
. Is dit wel efficient genoeg? (omdat ik van zoveel losse tables gebruik maak). En zoniet, wat kan ik eraan veranderen?
:strip_icc():strip_exif()/u/7418/the_hat_icon.jpg?f=community){kind=icon}
:strip_icc():strip_exif()/u/69009/eend.jpg?f=community)
en dan eens niet gaan denken in programmeren databases en weet-ik-veel-wat maar gewoon eens bedrijftechnisch gaan nadenken wat je allemaal voor mogelijkheden in je pakket wilt hebben. Bedenk ook alle processen, dus de manier waarop de gebruiker gaat werken en begin dan pas met je db.
/u/43729/gor.JPG?f=community)