[Alg/DB] Hoe verschillende soorten 'producten' opslaan*

[Verwijderd]

Hallo ik ben bezig met het onderdeel producten voor mijn website manager, ik heb een tabel gemaakt waarin ik vrijwel elk soort product kan plaatsen, zodat ik het op meerdere websites kan toepassen.

Ik had zelf de volgende veldnamen in gedachten, om verschillende informatie weer te geven en diverse berekeningen te maken of om te zoeken.

Iemand nog een suggestie voor een veld?
Lees : Kolomnaam ( Kolominhoud )

id ( 1 )

artikelnummer ( 00000000000001 )

barcode ( 00000000000000 )

categorie ( /producten/hoofdcategorie/ondercategorie/categorie/etc/ )

merk ( Merknaam )

model ( Model of Type )

omschrijving ( Tekstomschrijving voor meta tags )

trefwoorden( Woorden voor meta tags )


inhoud ( MSHTML (voor; algemene, technische en overige productinformatie) )

cijfer ( Cijfer van 1 tot 10 (stijlen) )

status ( Nieuw of Tweedehands )

aanbieding ( Ja of Nee )

gewicht ( 0.00 (KG) )

levertijd ( 0 dagen (of direct leverbaar) )

prijs_opmerking (% korting, Superstunt, Topprijs, Bodemprijs etc.)

prijs_van ( 0,00 )

prijs_voor ( 0,00 )

verwijderings bijdrage ( 0,00 )

downloads ( - )

bijpassende producten ( - )

media ( Afbeeldingen, Flash, Etc. )

Overigs lijkt het mij handig om hiernaast de mogelijkheid te geven om velden wel of niet te gebruiken met bepaalde instellingen.

[Noork]

Dit lijkt me eigenlijk onzin om een site op deze manier op te bouwen. Je kunt toch voor een specifieke klant de informatiebehoefte analyseren. Ik kan wel een lijst met 100.000 kolommen bedenken als 't moet om alle typen van producten op te kunnen nemen.

lengte, hoogte breedte, inhoud, vereisten, stof/materiaal, platform etc etc bedenk het maar.

[ Voor 17% gewijzigd door Noork op 16-09-2005 18:03 ]

[Verwijderd]

Ja hoor 100.000, dat kun jij vast wel bedenken, maar goed, elk product heeft een merk en een prijs lijkt me, dus ik doel eigenlijk op de meer algemenere velden, enerzijds heb ik klanten waarmee ik er niet uit kom, en anderzijds klanten die ik nog moet binnenhalen ervoor Maar alle suggesties welkom.


Het gaat erom dat de algemene velden kunnen worden ingevuld door slimme forms om het zo maar even te noemen, en andere specificere informatie die niet bij elk soort ingevuld hoeft (of willen) kan worden geplaatst in inhoud, met bijvoorbeeld ongesorteerde lijsten met technische specificatie's, die kan de klant er dan zo in typen/plakken.

[ Voor 36% gewijzigd door Verwijderd op 16-09-2005 18:16 ]

[djluc]

Je opzet is zeker niet generiek. Dan kan je beter iets als:
tabel producten
-id
-naam (Dell Laptop M50)

producten-eigenschappen
-productID
-eigenschapID
-waarde (Pentium IV 3 Ghz)

tabel eigenschappen
-id
-naam (Processor)

[Verwijderd]

Inderdaad, alles in één grote tabel stoppen lijkt me niet echt gewenst...

[Verwijderd]

Ik wil het ook wel verdelen over meerdere tabellen maar wat zijn de voor of nadelen, overigs wil ik bepaalde informatie wel in de forms groeperen.

Ik kan nu nog alle kanten op,

[ Voor 12% gewijzigd door Verwijderd op 16-09-2005 18:19 ]

[Verwijderd]

Voordeel is dat het overzichtelijker is.

Nadeel is dat je de tables moet linken op een of andere manier.

[mylar]

voordeel van djluc's aanpak:
heel moduleerbaar en je kan het voor veel toepassingen gebruiken

nadeel:
je gaat veel joins moeten leggen tussen de tabellen, wat bij veel producten minder performant zal zijn, en ook je queries gaan er minder duidelijk uitzien door het ontbreken van views in mysql.

[Verwijderd]

Ik heb een databaseboek en daar maken ze wel views aan in MySQL...?

[Verwijderd]

Tja ik begin nu te twijfelen of ik de tabel ga verdelen, mijn opzet is nu dat elk product (zo doe ik dit ook met pagina's) een kolom 'categorie' heeft, daarin komt de url te staan van waar het product moet worden weergegeven op de site, dus bijvoorbeeld '/producten/categorie/etc/etc/etc/', op die manier onstaan de volgende links: http://www.domeinnaam.com/producten/categorie/etc/etc/etc/, als je naar deze link zou gaan zie je alle producten die die categorie hebben, en vervolgens kan worden doorgeklikt naar de details pagina.

Mijn tweede vraag is eigenlijk, hoeveel rijen kun je aan een tabel toevoegen (wil het allemaal nog lekker werken), ik maak eigenlijk steeds maar kleine selectie's dus als er 10000 in staan roep ik die niet alle 10000 tegelijk op.

[ Voor 9% gewijzigd door Verwijderd op 16-09-2005 18:46 ]

[Remco]

Verwijderd schreef op vrijdag 16 september 2005 @ 18:45:

Mijn tweede vraag is eigenlijk, hoeveel rijen kun je aan een tabel toevoegen (wil het allemaal nog lekker werken), ik maak eigenlijk steeds maar kleine selectie's dus als er 10000 in staan roep ik die niet alle 10000 tegelijk op.

Hangt er van af.
Wat is je hardware
Wat is je memory
Hoe is je database opgebouwd.
Wat voor query doe je.
etc
etc
etc

Maar ik zal me om 10.000 rijen niet echt zorgen maken.

[Verwijderd]

djluc schreef op vrijdag 16 september 2005 @ 18:14:
Je opzet is zeker niet generiek. Dan kan je beter iets als:
tabel producten
-id
-naam (Dell Laptop M50)

producten-eigenschappen
-productID
-eigenschapID
-waarde (Pentium IV 3 Ghz)

tabel eigenschappen
-id
-naam (Processor)

Ik ben ook voor deze aanpak. In deze thread werden reeds een aantal nadelen van deze aanpak gegeven. Een ander nadeel is dat je alle eigenschappen als string (VARCHAR met lengte 255? TEXT?) opslaat, en dus niet gebruik kan maken van typische bijzonderheden mbt. een bepaalde kolomtype. De eigenschap Gewicht (uit je lijstje bovenaan) zal dus ook een string zijn, hoewel hier betere datatypes voor zijn (FLOAT?).

[whoami]

Dit riekt een beetje naar een soort van inheritance, maar dan in een database-way.

Er zijn 3 manieren om zo iets op te lossen:
- de manier zoals jij het wil doen: één logge tabel met daarin alle columns
Nadeel: vrijwel alle velden moeten nullable zijn, onoverzichtelijk, niet gestructureerd
- een tabel per soort product
- een tabel die de eigenschappen bevat die ieder product moet bevatten, en dan per 'soort product' een andere tabel die gejoined is met die 'globale' tabel.

Welke method je hier verkiest, hangt een beetje af van wat je wil doen. Zelf zou ik eigenlijk vrijwel nooit voor de eerste manier kiezen, omdat het imho minder beheersbaar is.

Mijn tweede vraag is eigenlijk, hoeveel rijen kun je aan een tabel toevoegen (wil het allemaal nog lekker werken), ik maak eigenlijk steeds maar kleine selectie's dus als er 10000 in staan roep ik die niet alle 10000 tegelijk op.

Wat bedoel je ? Vraag je je af hoeveel records een tabel kan bevatten ? miljoenen.
Om enkel die rijen op te halen die je interesseren, zal je je eens in SQL moeten verdiepen. Je kan nl. specifieren welke gegevens je wil ophalen.

Let er ook op dat het niet de bedoeling is om hier een 'opsomtopic' van te maken, want zo begint jouw topicstart wel.... Het is niet de bedoeling dat iedereen hier zomaar kan roepen welk veld je nog zou kunnen toevoegen aan jouw tabel. Zoals eerder al geopperd werd, is dat zowiezo geen goeie manier om je DB te maken. Maak een analyse.
Om die reden heb ik ook ff jouw topic-titel veranderd.

[Verwijderd]

mylar schreef op vrijdag 16 september 2005 @ 18:28:
voordeel van djluc's aanpak:
heel moduleerbaar en je kan het voor veel toepassingen gebruiken

nadeel:
je gaat veel joins moeten leggen tussen de tabellen, wat bij veel producten minder performant zal zijn, en ook je queries gaan er minder duidelijk uitzien door het ontbreken van views in mysql.

Views zijn ten eerste niet een vereiste om duidelijkheid te krijgen in je queries en de performance per join is verwaarloosbaar en hangt grotendeels af van je model, indices, en wijze waarop je data al vroegtijd in je queries filtert.

[Verwijderd]

Bedankt allemaal ik ga kijken wat ik ga doen