Welke techniek kan wat ik wil?

[om3ega]

Ik ben e.e.a op het papier aan het zetten voor een systeem wat ik wil gaan ontwikkelen. Nu is het zo dat ik geen die-hard afgestudeerd progammeur ben en leer altijd weer bij.

Zo loop ik wel eens tegen dingen aan waarvan ik het wiel opnieuw van uit probeer te vinden terwijl je er later achter komt (aldoende leert men) dat er al iets voor bestaat.

Zo ook het volgende. Wat ik wil weten is of er een bepaalde techniek bestaat die het probleem wat ik heb afvangt. Geef me een clue , een richting , keywords zodat ik daar in kan duiken. Op dit moment heb ik namelijk dat even niet.

Stel...

je hebt een webshop , met o.a. videokaarten , memory , cpu's etc etc..

Elke object heeft zijn eigen eigenschappen , maar die kunnen veranderen.

Voorbeeldje :

Videokaart A
Memory : 256 MB
Bus : AGP
VGA uitgang : Ja
DVI uitgang : Nee

zo kan je dus alle eigenschappen van je videokaart omschrijven en netjes in een database zetten. Je kan een tabel maken met colommen met values daarin.

Maar , gedurende de tijd zal deze tabel vervuilen. Waarom? Omdat bijvoorbeeld VGA aansluiting over 5 jaar (ik noem maar wat) niet meer wordt gebruikt en er een nieuwe standaard is. Ditzelfde geld voor processoren , memory en alle andere componenten.

Toch is het handig dat je alle eigenschappen van een component kan beschrijven zodat je ook kan vergelijken en zoeken (laat alle kaarten zien met een DVI uitgang)

Iets zegt me dat je dit niet zo makkelijk kan doen in een database (mysql bijvoorbeeld) omdat je te veel mutaties gaat krijgen (je tabel wordt steeds uitgebreider en onoverzichtelijker)

Hoe kan je nou toch op een goede manier je data opslaan , verwerken , toekomst vast (dus voorbereid op nieuwe technieken etc) zonder dat je elke keer je programma , database structuur etc moet wijzigen.

[DropjesLover]

alles goed bijhouden en verouderde items er uit gooien? dan heb je toch geen database vervuiling? helaas is dat natuurlijk wel redelijk tijdrovend

[sPENKMAN]

Maar , gedurende de tijd zal deze tabel vervuilen. Waarom? Omdat bijvoorbeeld VGA aansluiting over 5 jaar (ik noem maar wat) niet meer wordt gebruikt en er een nieuwe standaard is. Ditzelfde geld voor processoren , memory en alle andere componenten.

Zodra je geen produkten meer hebt met deze standaard zal er ook niet naar gelinkt worden d.m.v. een ID. Oftewel; zoek naar de ID's die voorkomen bij deze productomschrijving, indien deze nergens meer voorkomt kan je deze verwijderen.

Of denk ik nou te simpel?

[djluc]

table products
* id
* price

table properties_products
* propertyID
* productID
* value

table properties
* id
* name

[Verwijderd]

Waarom zou je een oude videokaart uit je database verwijderen? Voor een webshop kun je net zo goed ergens in een kolommetje aangeven dat het product niet meer wordt verkocht. Wil je een order tabel bij gaan houden, dan is het toch prettig als je ook nog oude orders naar boven kunt halen.

Over de nieuwe eigenschappen: die zet je in een aparte tabel. Elk product heeft dan een n:m relatie met de eigenschappen tabel. In de koppeltabel die je ovor die relatie krijgt, heb je dan simpelweg een kolom met de waarden. Het zoeken wordt er wel een stuk complexer door.

[kalechinees]

Mijn ideeen:
Geef elke productgroep (en subproductgroep) een verwijzing naar een structuur tabel. In deze tabel kun je gewoon de velden ingeven welke gebruikt moeten worden per productgroep

bv

code:

Videokaarten (structuur_id = 1)
    DVI
    Dsub
    TV out
CPU
    Intel (structuur_id =2)
       S478
          FSB
          maxtemp
          blabla
       S775
          FSB
          maxtemp
          blabla
    AMD (structuur_id =2)
          S939
          AM2

[djluc]

Hoe werk je dat dan uit in je databasestructuur? Dan kom je toch op hetzelfde terecht?

[JKVA]

Wat je wil, is in feite een dynamische tabel die per record verschilt.
Dus bij een CPU heb je geen veld resolutie en bij een monitor geen veld diskgrootte.

Dit kun je realiseren op de manier van djluc.
Dus een product tabel en een eigenschap tabel.
Daar leg je een koppeltabel tussen met als extra kolom de waarde van je eigenschap behorende bij dit specifieke product.

Zo heb je geen lege plekken in je tabel en groeit deze niet tot ongekende grootte.

(eigenlijk is dit alleen maar een toelichting op djluc's post.

[Verwijderd]

djluc schreef op zaterdag 12 augustus 2006 @ 11:40:
Hoe werk je dat dan uit in je databasestructuur? Dan kom je toch op hetzelfde terecht?

Klopt, zijn idee kan handig zijn voor de invoer van gegevens in een of ander onderhoudssysteem. Voor de werking van de webshop zelf zou het niet uit moeten maken, dan krijg je in principe de structuur die jij en ik beschreven.

[djluc]

Ben het trouwens even wat verder aan het uitdenken. Je kunt er nog een extra tabelletje bij doen:

table templates (o.i.d.)
* id
* name

En dan een koppeltabel:

table properties_templates
* propertyID
* templateID

Nu kan je bijvoorbeeld een template videokaart aanmaken waarmee je in je backend meteen de juiste velden te zien krijgt. Dat is handiger dan iedere keer de juiste properties uitzoeken.

[om3ega]

Hmm , daar had ik nog niet aan gedacht...

Je krijgt dan als het ware een soort van template inderdaad..
Ik ga eens even kijken of ik dat kan uitwerken in een werkend geheel

Bedankt voor het brainstormen!

[djluc]

Het werkt, ik heb het zo namelijk al eens in de praktijk gemaakt. Vergeet trouwens geen sorteerveldjes aan te brengen, dat is wel nodig in je templates anders wordt het al snel gezien als een irritante feature.

[MisterData]

Het lijkt een beetje op Google Base als ik het goed begrijp?

[Depress]

MisterData schreef op zaterdag 12 augustus 2006 @ 18:03:
Het lijkt een beetje op Google Base als ik het goed begrijp?

Nee hoor, denk elke grotere webshop.

Je zou zoals DJ zegt gewoon ID's kunnen maken, deze schijden met een ',' en zo ook meerdere items kunnen toevoegen.

[djluc]

Depress schreef op zaterdag 12 augustus 2006 @ 18:09:
[...]
Nee hoor, denk elke grotere webshop.

Je zou zoals DJ zegt gewoon ID's kunnen maken, deze schijden met een ',' en zo ook meerdere items kunnen toevoegen.

Ik neem aan dat je mij bedoeld? Zoja: Ik ga echt niemand aanraden om komma seperated zaken in een veldje op te slaan...

Verder lijkt de opzet wel degelijk op Google base waarmee je ook attributen aan objecten kunt hangen. Het is gebaseerd op het idee dat je elk object op een universele manier op kunt slaan in een relationele database wat ook wel object relational mapping genoemd wordt.

[JKVA]

djluc schreef op zaterdag 12 augustus 2006 @ 18:31:
[...]
Ik neem aan dat je mij bedoeld? Zoja: Ik ga echt niemand aanraden om komma seperated zaken in een veldje op te slaan...

Verder lijkt de opzet wel degelijk op Google base waarmee je ook attributen aan objecten kunt hangen. Het is gebaseerd op het idee dat je elk object op een universele manier op kunt slaan in een relationele database wat ook wel object relational mapping genoemd wordt.

Ik zou dit persoonlijk geen OR Mapping noemen. Dit is een indeling van tabellen/velden die het mogelijk maakt om op een generieke manier dynamisch attributen toe te wijzen aan een "object"/entiteit.

OR Mapping zorgt in feite voor een extra laag tussen je relationele database en je OO programmeertaal en maakt het mogelijk om (in memory) objecten op te slaan en op te halen omdat deze tussenlaag e.e.a. converteert van object naar sql en vice versa.

[djluc]

Ik zeg ook dat het er op gebaseerd is, het is zeker niet hetzelfde alleen al omdat het inderdaad vaak een extra layer is in je applicatie.

[JaQ]

djluc schreef op zaterdag 12 augustus 2006 @ 17:56:
Het werkt, ik heb het zo namelijk al eens in de praktijk gemaakt.

Het werkt absoluut, maar heb je ook al eens naar je SQL gekeken? Nou heb ik het idee dat jij wel redelijk SQL kan en ook nog wel e.e.a. weet over RDBMS-en en SQL-tuning, maar dit soort datamodellen wil je toch eigenlijk iemand aandoen.

Dit soort "4 tabellen modellen om de hele wereld in op te slaan" zijn ronduit spuuglelijk en zouden m.i. direct verboden moeten worden. Je bent vast bekend met het verhaal van Dhr. Kyte over dit soort modellen? Daarmee zeg ik denk ik wel genoeg... _{deze link komt ondertussen al verrassend vaak terug op dit forum}

[Knutselsmurf]

JaQ schreef op zondag 13 augustus 2006 @ 13:08:
[...]


Het werkt absoluut, maar heb je ook al eens naar je SQL gekeken? Nou heb ik het idee dat jij wel redelijk SQL kan en ook nog wel e.e.a. weet over RDBMS-en en SQL-tuning, maar dit soort datamodellen wil je toch eigenlijk iemand aandoen.

Dit soort "4 tabellen modellen om de hele wereld in op te slaan" zijn ronduit spuuglelijk en zouden m.i. direct verboden moeten worden. Je bent vast bekend met het verhaal van Dhr. Kyte over dit soort modellen? Daarmee zeg ik denk ik wel genoeg... _{deze link komt ondertussen al verrassend vaak terug op dit forum}

Hoewel het inderdaad slecht is om je hele database zo op te bouwen, kan het voor onderdelen wel een oplossing zijn. Voor het hier besproken geval is het in mijn ogen een oplossing. Verder zijn we natuurlijk benieuwd wat in jouw ogen dan wel een juiste oplossing voor dit probleem is.

[djluc]

Het mooiste is zo'n object relational mapping layer in je applicatie. En dan het lieft een die in een snellere taal dan PHP is geschreven. De oplossing om de wereld op te slaan in 1 tabel is inderdaad niet altijd de mooiste, vereist inderdaad redelijk ingewikkelde queries en heeft een relatief hoge systemload. Maar het is tegelijkertijd wel goed beheersbaar door de users en het is flexibel genoeg om de data op te kunnen slaan. Je kunt natuurlijk ook een tabel met 100+ kolommen maken maar dat is ook niet echt een oplossing die erg mooi is. Zeker niet omdat je dan bijvoorbeeld weer een tabel krijgt waarin je de kolomnamen moet gaan vertalen enzo. Uiteindelijk is dit toch niet zo heel erg evil als het lijkt...

[JaQ]

Knutselsmurf schreef op zondag 13 augustus 2006 @ 16:01:
[...]
Hoewel het inderdaad slecht is om je hele database zo op te bouwen, kan het voor onderdelen wel een oplossing zijn. Voor het hier besproken geval is het in mijn ogen een oplossing. Verder zijn we natuurlijk benieuwd wat in jouw ogen dan wel een juiste oplossing voor dit probleem is.

Het probleem dat ik daar mee heb is dat de code daardoor nogal lastig te onderhouden wordt. Naast dat je namelijk dynamische kolommen hebt, heb je dus ook dynamische formulieren, met bijbehorende dynamische business logica. De onderhoudbaarheid van dit soort systemen is op zijn zachts gezegt lastig. Persoonlijk ben ik daarom voorstander van het uitschrijven van je kolommen.

Neem nou precies het voorbeeld dat de TS geeft. Op het moment dat er een nieuwe feature komt in hardware heb je op zijn minst 1 nieuw attribuut van zo'n stuk hardware (meer is uiteraard mogelijk). Daarnaast heeft zo'n attribuut een domein (bijvoorbeeld boolean, of een integer met een bereik van 0-1000, whatever). Dit domein dient gecontroleerd te worden door een stukje code, aangezien je user input hebt. Daarnaast wil je misschien ook nog wat business logica (bijvoorbeeld AGP sluit PCI express uit, etc). Dit wil je nog steeds allemaal in dit generieke model stoppen? Dikke kans dat je bij de meeste nieuwe attributen die je wilt toevoegen opnieuw de (zeer lastig te volgen) code in moet.

Maar zelfs al moet dat niet. Nu laat je gebruiker X met je programma werken. Deze gebruiker is toevallig applicatiebeheerder en wordt geacht je programma te kennen. Over het algemeen is een gebruiker geen techneut, wat rechtstreeks impliceert dat de denkwijze anders is dan de denkwijze van een techneut. Probeer het attribuut naam - attribuut waarde concept eens aan je vriendin uit te leggen en quiz haar daarna (zolang ze tenminste geen techneut is ). Snap je waar ik op doel?

Dit zijn mijn argumenten nog voordat ik over performance van een draak als deze begin. Wat is nou het probleem met accepteren dat de wereld veranderd. Wijzigingen in de realiteit betekenen wijzigingen in je model van de realiteit (wat je database ontwerp nog steeds is). Dat je hierdoor wijzigingen in je programma moet aanbrengen is vervelend, maar absoluut begrijpelijk.

djluc schreef op zondag 13 augustus 2006 @ 16:09:
Het mooiste is zo'n object relational mapping layer in je applicatie. En dan het lieft een die in een snellere taal dan PHP is geschreven. De oplossing om de wereld op te slaan in 1 tabel is inderdaad niet altijd de mooiste, vereist inderdaad redelijk ingewikkelde queries en heeft een relatief hoge systemload. Maar het is tegelijkertijd wel goed beheersbaar door de users en het is flexibel genoeg om de data op te kunnen slaan. Je kunt natuurlijk ook een tabel met 100+ kolommen maken maar dat is ook niet echt een oplossing die erg mooi is. Zeker niet omdat je dan bijvoorbeeld weer een tabel krijgt waarin je de kolomnamen moet gaan vertalen enzo. Uiteindelijk is dit toch niet zo heel erg evil als het lijkt...

Wat jij dus als voordeel ziet, zie ik als nadeel. De beheersbaarheid door en flexibiliteit voor gebruikers is m.i. een facade. Vertalingen van kolomnamen zijn m.i. dikke onzin, het meertalig opzetten van een applicatie staat volledig los van de database structuur.

[ Voor 18% gewijzigd door JaQ op 13-08-2006 16:46 ]

[prototype]

Aaah, de aloude afweging tussen flexbiliteit, performance en onderhoudbaarheid... persoonlijk ruik ik nu enerzijds overengineering, maar anderzijds heb ik er ook wel begrip voor; je queries wegen zo iig straks vrij zwaar. Dit zou je opzich eventueel kunnen optimaliseren door caching door te voeren, zodat je dus alleen een performance penalty hebt bij het bouwen van je cached data, en dat gaat per update. De heuristiek hierachter is dat de ratio product bekijken : product updaten bedraagt namelijk vrijwel zeker in het voordeel van product bekijken is. Besef je wel goed dat er ook consequenties weer hangen achter deze vorm van redundancy, afhankelijk van hoe je dit evt wil gaan implementeren.

[soulrider]

zoiets kan 't makkelijkst opgelost worden
via een database die op correcte wijze wordt genormaliseerd.

zoals djluc je ook al wou aangeven.

aparte tabellen voor:
producten:
soort product. (vga-kaart, scherm, tobo, mamaplank, ...)
mogelijkheden
waardes van mogelijkheden

en dan 1 tabel die bv die laatste 2 aan elkaar linkt
en dan 1 tabel die bv die tabel aan de producten linkt.

resultaat: ook al verwijder je dan bv alle videokaarten die een vga aansluiting hebben uit je aanbod, dan kan je later alsnig (als je oude hardware gaat resellen bv alsnog aanduiden dat je een kaart hebt met vga aansluiting.

effe serieus nadenk werk wat er allemaal van info is en dit als database bekijken en dan normaliseren.

google er effe op

effe aanvullen op bovenliggende posten:

1 tabel is hier niet echt schoon: je gaat veel lege ruimte hebben
en wat als er later nog nieuwe aansluitingen gaan ontstaan ?

1 tabel met bv 1000 records:
1 nieuwe kolom kost je per record bv 8 byte's: voila 8 kB wegegooid voordat je nog maar 1 product hebt ingegeven dat er gebruik van maakt.
1 miljoen records: al direct 8 MB weggesmeten.

met goede normalisatie: 8 byte's voor de record in de juiste tabel + x-tal bytes voor unieke ID waarmee ie aan een product kan gekoppeld worden.
(+ natuurlijk de bytes in de link-tabel maar die zijn er enkel als er ook daadwerkelijk een product is dat dit typeaansluiting of eigenschap heeft)

qua opslag kan dit meestal wel serieus verschil maken mss niet in het begin maar wel naar toekomst toe. 1 GB database omdat jij 20000 producten hebt met mss in totaal 200 verschillende eigenschappen die elk 250 bytes in beslag nemen qua opslag ?
(20000x200x250 = 1 miljard...)

terwijl dit na normalisatie mss slechts 8x20k+ 250x20k +8x200 + 250x200 = 258*20k + 258*200 + linktabel kost (5,16 miljoen + 51.600 + linktabel) aan opslag kost
laten we nog ruim afronden naar boven: 50 MB
merk het verschil effe en dus ook wrs de snelheid en de tijd dat je ermee kunt werken ;-)

(ben zelf ooit begonnen aan een tool waarmee je pc's kon samenstellen en dus geen amd-cpu met een intel-mb kon kiezen, enkel de juiste latjes qua ram kreeg voorgesteld ev. van mogelijkheden van moederbord enzo ... nooit afgekregen wegens te weinig tijd / goesting gekregen voor die normalisatie enzo)

[ Voor 51% gewijzigd door soulrider op 15-08-2006 23:21 ]

[prototype]

soulrider schreef op dinsdag 15 augustus 2006 @ 23:07:
zoiets kan 't makkelijkst opgelost worden
via een database die op correcte wijze wordt genormaliseerd.

zoals djluc je ook al wou aangeven.

aparte tabellen voor:
producten:
soort product. (vga-kaart, scherm, tobo, mamaplank, ...)
mogelijkheden
waardes van mogelijkheden

en dan 1 tabel die bv die laatste 2 aan elkaar linkt
en dan 1 tabel die bv die tabel aan de producten linkt.

resultaat: ook al verwijder je dan bv alle videokaarten die een vga aansluiting hebben uit je aanbod, dan kan je later alsnig (als je oude hardware gaat resellen bv alsnog aanduiden dat je een kaart hebt met vga aansluiting.

effe serieus nadenk werk wat er allemaal van info is en dit als database bekijken en dan normaliseren.

google er effe op

effe aanvullen op bovenliggende posten:

1 tabel is hier niet echt schoon: je gaat veel lege ruimte hebben
en wat als er later nog nieuwe aansluitingen gaan ontstaan ?

1 tabel met bv 1000 records:
1 nieuwe kolom kost je per record bv 8 byte's: voila 8 kB wegegooid voordat je nog maar 1 product hebt ingegeven dat er gebruik van maakt.
1 miljoen records: al direct 8 MB weggesmeten.

met goede normalisatie: 8 byte's voor de record in de juiste tabel + x-tal bytes voor unieke ID waarmee ie aan een product kan gekoppeld worden.
(+ natuurlijk de bytes in de link-tabel maar die zijn er enkel als er ook daadwerkelijk een product is dat dit typeaansluiting of eigenschap heeft)

qua opslag kan dit meestal wel serieus verschil maken mss niet in het begin maar wel naar toekomst toe. 1 GB database omdat jij 20000 producten hebt met mss in totaal 200 verschillende eigenschappen die elk 250 bytes in beslag nemen qua opslag ?
(20000x200x250 = 1 miljard...)

terwijl dit na normalisatie mss slechts 8x20k+ 250x20k +8x200 + 250x200 = 258*20k + 258*200 + linktabel kost (5,16 miljoen + 51.600 + linktabel) aan opslag kost
laten we nog ruim afronden naar boven: 50 MB
merk het verschil effe en dus ook wrs de snelheid en de tijd dat je ermee kunt werken ;-)

(ben zelf ooit begonnen aan een tool waarmee je pc's kon samenstellen en dus geen amd-cpu met een intel-mb kon kiezen, enkel de juiste latjes qua ram kreeg voorgesteld ev. van mogelijkheden van moederbord enzo ... nooit afgekregen wegens te weinig tijd / goesting gekregen voor die normalisatie enzo)

Ik vraag me af in hoeverre je de bovenstaande reacties daadwerkelijk hebt gelezen. Dat normaliseren flexibiliteit bevordert is al lang duidelijk, maar we hebben het nu ook over de gevolgen van die normalisatie; een simpele productoverzicht kost nu gewoon enkele innerjoins die nou ook niet bepaald goedkoop zijn. JaQ had 'm al aangehaald, maar 'k zal 't maar nog een keer doen:

Dr Kyte

[soulrider]

prototype schreef op woensdag 16 augustus 2006 @ 00:32:
[...]


Ik vraag me af in hoeverre je de bovenstaande reacties daadwerkelijk hebt gelezen. Dat normaliseren flexibiliteit bevordert is al lang duidelijk, maar we hebben het nu ook over de gevolgen van die normalisatie; een simpele productoverzicht kost nu gewoon enkele innerjoins die nou ook niet bepaald goedkoop zijn. JaQ had 'm al aangehaald, maar 'k zal 't maar nog een keer doen:

Dr Kyte

vrij goed doorlezen, maar 't was ook enkel tips naar de ts toe.

iedereen begon over normalisatie en de snelheid ervan (neg. en pos.)
ik ook over de gevolgen qua opslag (pos.) hoe goed heb jij mijn post gelezen ;-)

hij wou enkele tips, hij heeft ze.

Hij gaat zelf een afwegen moeten doen tussen gebruikte ruimte / snelheid van database / moeilijkheid 't schrijven van de behorende sql-code/ de verwerkingstijd van die code....
zoals de persoon boven mijn vorige post zei

dan mag hier een discussie bezig zijn hoe ver je moet/mag normaliseren, is handig om een inzicht te geven maar beetje way over als het normaliseren nog niet eens bekend klinkt bij ts ...

Je weet niet waarvoor de ts het gaat gebruiken:

prive of openbaar, moet het snel gaan of mag het effe duren, ...

't is aan hem om 't overwegen en zelf op zoek te gaan wat voor hem 't beste is.

google-actie's van hem kunnen nu gebeuren

heel kort door de bocht antwoord op de vraag in de topic titel en de uitleg in zijn startpost:

"een naar eigen kennis en ervaring genormaliseerde database met daarrond een vlot bedienbare gui"
als ie het niet vlot genoeg bedienbaar vind: zich indiepen in het domein en met de nieuwe kennis verdergaan. een database is niet zomaar op 1,2,3 correct gemaakt.
vooral data-mining-database's niet.

[ Voor 11% gewijzigd door soulrider op 16-08-2006 01:22 ]