[Database] Hoe pak je dit aan ?

[maartenba]

Ok, ik weet niet hoe ik deze topic moet openen, maar ik had dus een vraagje over hoe je het best aanpakt om producten in een database te stoppen...

Stel: je verkoopt TV's en videorecorders. Dit zijn 2 producten, met allemaal verschillende eigenschappen:
TV -> Breedte, Hoogte, Diepte, aantal zenders
Video -> Breedte, Hoogte, Diepte, aantal "koppen", opnametimer (ja/nee)

Nu wil ik een tabelletje "product" gaan maken, waarin ik een TV en een videorecorder wil stoppen. Als ik deze als volgt opstel wordt het nogal een grote tabel:
PRODUCT (id, naam, type, breedte, hoogte, diepte, aantal zenders, aantal koppen, opnametimer)

Heb al proberen normaliseren maar ik geraak er volledig niet uit

[Verwijderd]

ik zou voor elk verschillend product een tabel maken dus een voor TV en een voor de video's

[LordLarry]

apparaat: breedte, hoogte, diepte
tv: apparaat, zenders
video: apparaat, koppen, opnametimer

[maartenba]

LordLarry schreef op 27 augustus 2002 @ 12:16:
apparaat: breedte, hoogte, diepte
tv: apparaat, zenders
video: apparaat, koppen, opnametimer

Zo had ik dus ook gedacht, maar leek me nogal omslachtig...
Kzal deze dan maar proberen

[LordLarry]

Tja, dit is normaliseren.
Je hebt nu geen dubbele gegevens. Soms wordt er besloten om voor de snelheid of makkelijkheid niet volledig te normaliseren, maar dat is de keus die je zelf moet maken.

[Xandrios]

Gewoon voor elk soort product een eigen tabel maken.
In elk tabel kun je dan de velden opnemen met de specificaties die bij het bijbehorende product horen.

Dat je een wat langere query krijgt, is mischien wat lastig met het bouwen van je applicatie, maar verder boeit het geen zak hoor

'k ben nu met een site bezig die een tabel heeft met 45 velden...geeft totaal geen problemen

[Verwijderd]

En wat nu als er een videorecorder of een tv bijkomt met een geheel nieuwe techniek? Dan kun je dus je dbmodel geheel aanpassen. Ik zou het persoonlijk als volgt aanpakken:

table: cat_devices
id: auto increment
cat_name: text

table: devices
id: auto increment
device_name: text
cat_device: integer (gekoppeld aan id uit cat_devices)

Nu kun je dus onbeperkt categorien aanmaken en onbeperkt devices (tv, vcr etc.)

Nu moet je nog de eigenschappen gaan vastleggen. Aangezien deze veel veranderen wil ik geen kolommen gaan gebruiken, en gewoon per eigenschap een record aanmaken.

prop_devices:
id: auto increment
prop_id: integer (id van property uit properties table)
dev_id: integer (id van het device (tv, vcr, etc) uit de devices table)

Deze bovenstaande tabel is dus puur bedoeld om de koppeling te leggen tussen de devices en de properties.

En dan een tabel met de properties, deze zou je evt, met een extra tabel nog eens kunnen onderverdelen in categorien:

table: properties
id: auto increment
prop_name: text

[LordLarry]

Inderdaad. Alleen een beetje lastig een GUI maken daarvoor. Het lijkt me persoonlijk een beetje over de top voor wat maartenba wil. Maar ik kan het mis hebben

[ACM]

Verwijderd schreef op 27 augustus 2002 @ 12:41:
prop_devices:
id: auto increment
prop_id: integer (id van property uit properties table)
dev_id: integer (id van het device (tv, vcr, etc) uit de devices table)

Deze bovenstaande tabel is dus puur bedoeld om de koppeling te leggen tussen de devices en de properties.

Wat doet die id daar dan?

[Verwijderd]

ACM schreef op 27 augustus 2002 @ 13:03:

[...]

Wat doet die id daar dan?

Deze kan je gebruiken om de relatie op te heffen Wat dacht je dan?

Overigens zou je dan *dat is waarschijnlijk jouw insteek* de relatie kunnen opheffen door een DELETE FROM table WHERE device = integer AND property = integer statement uit te voeren, maar ik persoonlijk vindt het altijd netter en veiliger om dit soort acties adhv een auto increment uit te voeren.

[Verwijderd]

Mischien moet je aparte tabellen aanmaken voor elk apparaat afzonderlijk en dan met queries gaan werken. en relaties zoals Gordijnstok zegt.

[Verwijderd]

Verwijderd schreef op 27 augustus 2002 @ 13:52:
[...]


Deze kan je gebruiken om de relatie op te heffen Wat dacht je dan?

Overigens zou je dan *dat is waarschijnlijk jouw insteek* de relatie kunnen opheffen door een DELETE FROM table WHERE device = integer AND property = integer statement uit te voeren, maar ik persoonlijk vindt het altijd netter en veiliger om dit soort acties adhv een auto increment uit te voeren.

Da's puur gevoelsmatig. Als je het zonder id doet (zoals ACM ook al zei) weet je tenminste zeker dat je ook geen dubbele koppeling maakt. Device en property vormen dan samen de primary key. Je db zorgt er dan wel voor dat je er niet 2 dezelfde van aanmaakt.
Leg de checks ed altijd zoveel mogelijk bij je database en niet in je software.

Verder wel leuk ontwerp btw.

[chris]

OF.....je gaat met xml werken. Hier is het makkelijker om extra informatie per "item" aan te maken. Maar of dit een nuttige toevoeging aan het topic is weet ik niet zeker...

[akakiwi]

TBL_Apparaten
------------------------------------------
Id
Naam

TBL_Eigenschappen
------------------------------------------
Id
Naam {bijvoorbeeld: doorsnee, breedte, zenders, teletekstpagina's, geheugen, kleur}
Type {bijvoorbeeld: tekst, nummer, tekstgebied dropdown}

edit:

TBL_ApparaatEigenschappen
------------------------------------------
EigenschapId
ApparaatId
Waarde {bijvoorbeeld: 82cm, 100cm, 32, 1200 snelgeheugen, 512Md SDRAMM, rood}

Al met al niet al te moeilijk

[ Voor 0% gewijzigd door akakiwi op 27-08-2002 14:42 . Reden: normaliseren ;) ]

[GraasGast]

Als het niet belangrijk is om te kunnen sorteren op die eigenschappen (ORDER BY aantal_knoppen oid) dan kan het handig zijn om gewoon 1 tabel 'producten' te gebruiken:

table products:
-product_id (int, auto_increment)
-category_id (int)
-product_name (varchar)
-product_description (blob)
-product_price (float)

table category
-category_id (int, auto_increment)
-category_name (varchar)

in description geef je dan gewoon van elk product een beschrijving, zodat je ook andere dingen kan verkopen als tv's en videorecorders.

[Verwijderd]

/dev/null schreef op 27 augustus 2002 @ 14:37:
OF.....je gaat met xml werken. Hier is het makkelijker om extra informatie per "item" aan te maken. Maar of dit een nuttige toevoeging aan het topic is weet ik niet zeker...

Klok horen luiden, maar je weet niet waar de klepel hangt

GraasGast schreef op 27 augustus 2002 @ 14:43:
Als het niet belangrijk is om te kunnen sorteren op die eigenschappen (ORDER BY aantal_knoppen oid) dan kan het handig zijn om gewoon 1 tabel 'producten' te gebruiken:

Dat weet je vaak niet van te voren (of dat blijkt later toch te moeten). Je kunt er beter rekening mee houden dat het wel moet kunnen.

table products:
-product_id (int, auto_increment)
-category_id (int)
-product_name (varchar)
-product_description (blob)
-product_price (float)

table category
-category_id (int, auto_increment)
-category_name (varchar)

in description geef je dan gewoon van elk product een beschrijving, zodat je ook andere dingen kan verkopen als tv's en videorecorders.

Maar dan kun je toch beter gewoon Gordijnstoks ontwerpje nemen?
Daar kun je de naam ook opslaan en beschrijving en prijs zijn gewoon property's (beschrijving over verschillende kolommen verdeeld, waarschijnlijk).

[maartenba]

Ok, ik ben nu vertrokken vanuit het ontwerp van Gordijnstok:

tblAPPARAAT(id, categorieid, naam)
tblCATEGORIE(id, naam)
tblEIGENSCHAP(id, eigenschapsnaam)
tblCATEGORIEEIGENSCHAP(categorieid, eigenschapid)
tblAPPARAATEIGENSCHAP(apparaatid, eigenschapid, waarde)

Eventueel zou ik tblCATEGORIEEIGENSCHAP nog kunnen laten vallen ?

[Verwijderd]

maartenba schreef op 28 augustus 2002 @ 10:19:
Ok, ik ben nu vertrokken vanuit het ontwerp van Gordijnstok:

tblAPPARAAT(id, categorieid, naam)
tblCATEGORIE(id, naam)
tblEIGENSCHAP(id, eigenschapsnaam)
tblCATEGORIEEIGENSCHAP(categorieid, eigenschapid)
tblAPPARAATEIGENSCHAP(apparaatid, eigenschapid, waarde)

Eventueel zou ik tblCATEGORIEEIGENSCHAP nog kunnen laten vallen ?

Dat moet je zelf weten. Op zich is het wel handig om hem er in te houden, aangezien een aantal eigenschappen hetzelfde zijn binnen een categorie. Anders moet je steeds opnieuw verzinnen welke eigenschappen je ook al weer wilde.

Succes ermee.

[LordLarry]

maartenba schreef op 28 augustus 2002 @ 10:19:
Ok, ik ben nu vertrokken vanuit het ontwerp van Gordijnstok:

Heb je al bedacht hoe je de GUI daarvoor gaat maken? Ik kan me voorstellen dat het lastig wordt in het geval van een windows programma. Een webpagina is misschien nog wel te doen. Ik zou zo'n model wel afstemmen daarop

[Verwijderd]

Een GUI maken adhv mijn ontwerp; eitje. Ik heb voor roll based security (author, editor, publisher, etc.) van een cms systeem wat ik ooit heb gemaakt een nog veel ingewikkelder dbmodel moeten gebruiken. Zo ingewikkeld, dat ik op een gegeven moment zelf zoiets had van " erm.. waarom had ik het zo aangepakt?" maar gelukkig had ik het goed gedocumenteerd op papier

Ik maakte toen gebruik van 4 koppeltabellen omdat ik goedkeuring door zowel groepen als individuen wilde laten doen

[Verwijderd]

LordLarry schreef op 28 augustus 2002 @ 11:54:
[...]

Heb je al bedacht hoe je de GUI daarvoor gaat maken? Ik kan me voorstellen dat het lastig wordt in het geval van een windows programma. Een webpagina is misschien nog wel te doen. Ik zou zo'n model wel afstemmen daarop

Dat maakt in principe niks uit. De SQL blijft hetzelfde. Alleen de manier van uitlezen zal verschillen. Het lijkt me niet dat je je datamodel zodanig op je applicatie afstemt dat het niet meer (of moeilijk) te gebruiken is met andere software.

Stel bijvoorbeeld dat hij inderdaad nu een windows programma gaat maken. Prima, hij past zijn datamodel daar op aan en implementeerd de boel bij de klant. 3 maanden later belt de klant op dat ze ook een website willen met productinformatie. Tja...

edit: Daarbij zie ik niet in waarom je dit niet zou kunnen toepassen in een windowsprogramma.
edit2: Ik zie dat Gordijnstok me al weer voor is met mijn eerste edit

[thomaske]

tblAPPARAATEIGENSCHAP(apparaatid, eigenschapid, waarde)

Misschien makkelijk om je 'waarde' op te delen in 2 stukken. het eerste gedeelte wordt de echte waarde van de eigenschap en het tweede gedeelte wordt het achtervoegsel (of hoe je het ook wilt noemen)

Wanneer je bijvoorbeeld harddisks de verdeling maakt tussen: 'waarde' en 'Gigabyte'
voordeel hiervan is dat je makkelijk kan sorteren op je eigenschappen

[LordLarry]

Verwijderd schreef op 28 augustus 2002 @ 12:19:
[...]
Dat maakt in principe niks uit. De SQL blijft hetzelfde. Alleen de manier van uitlezen zal verschillen. Het lijkt me niet dat je je datamodel zodanig op je applicatie afstemt dat het niet meer (of moeilijk) te gebruiken is met andere software.

edit: Daarbij zie ik niet in waarom je dit niet zou kunnen toepassen in een windowsprogramma.

Alles kan. Ik had het er over dat het misschien te ver doorgedraven is voor de eisen die gesteld zijn.

Stel je voor dat je een eigenschap in de database toevoegt, hoe zie ik die dan terug in de GUI? Laat je alle alle eigenschappen per device zien in een tabel? dat kan, maar is niet altijd gewenst. Ga je dan runtime forms opbouwen en dan afhankelijk van de eigenschappen componenten op het scherm zetten? Das al weer wat lastiger.

Stel bijvoorbeeld dat hij inderdaad nu een windows programma gaat maken. Prima, hij past zijn datamodel daar op aan en implementeerd de boel bij de klant. 3 maanden later belt de klant op dat ze ook een website willen met productinformatie. Tja...

En? Kan dat niet met het DB model dat ik voorstelde dan?

Als je denkt of afspreekt dat de klant zeer waarschijnlijk toekomstige wijzigingen wil hebben kan je inderdaad beter voor het los opgezette model kiezen.

Je kan altijd ook nog gewoon de klant laten betalen voor de wijzigingen die je moet doen

Kortom: Ik zeg niet dat de ene beter is als de andere, maar ik probeer alleen duidelijk te maken waar je rekening mee moet houden als je voor een bepaald model kiest. Degene met de meeste mogelijkheden (en meestal het ingewikkelst) is niet altijd automatisch de gewenste IMHO

[LordLarry]

Zo zie je maar weer aan thomaske's voorstel: Je kan het steeds genrieker maken, maar waar is de grens?

Je kan ook het zo ver doortrekken zodat je op een gegeven moment een database in een database hebt gebouwd

[Verwijderd]

Over die GUI moet je helemaal geen zorgen maken. Dat is pas je presentatielaag. Zolang je gegevens in de database allemaal een kloppende relatie hebben, kun je deze op welke manier dan ook presenteren.

Hoe je eigenschappen gaat weergeven, dat is een eigen keus. Je kunt zeggen dat niet alle eigenschappen per direct relevant zijn, en zodoende moet je evt een boolean field toevoegen onder de noemer "ShowInstant" of iets derg.

Overigens snap ik niet helemaal hoe we bij deze wending richting GUI opbouw zijn gekomen. Met een dergelijke databasestructuur is het namelijk totaal niet moeilijk om een GUI eromheen te zetten.

Je bekijkt een paar afbeeldingen van interfaces en dan denk je bij jezelf "Verrek, wat loop ik nou moeilijk te doen".

[maartenba]

Ik denk dat de GUI best wel te doen is, moet op een website komen, maar dat maakt niet zoveel verschil met een andere app...

tblAPPARAAT -> naampjes van de apparaten
tblCATEGORIE -> categorie waarin het apparaat hoort
tblEIGENSCHAP -> een eigenschap die een apparaat KAN hebben
tblCATEGORIEEIGENSCHAP -> lijkt me handig voor de invoer van apparaateigenschappen, zodat je meteen de namen van de eigenschappen kan ophalen in je invoerscherm
tblAPPARAATEIGENSCHAP -> de uiteindelijke eigenschappen van het apparaat, kga er wel dit van maken:
tblAPPARAATEIGENSCHAP(apparaatid, eigenschapid, waarde, eenheid)
Dan kan je zoals hierboven gezegd netjes op "GB" etc. gaan sorteren.

Jullie zijn schatten !

[Verwijderd]

LordLarry schreef op 28 augustus 2002 @ 12:47:
Je kan altijd ook nog gewoon de klant laten betalen voor de wijzigingen die je moet doen

tja. Dat kan, maar dan moet je je hele datamodel om gaan gooien. Dat is voor mij een signaal dat je eerste model gewoon niet goed was.

Ik zeg niet dat de ene beter is als de andere, maar ik probeer alleen duidelijk te maken waar je rekening mee moet houden als je voor een bepaald model kiest.

Ik ook

Verwijderd schreef op 28 augustus 2002 @ 12:53:
Over die GUI moet je helemaal geen zorgen maken. Dat is pas je presentatielaag. Zolang je gegevens in de database allemaal een kloppende relatie hebben, kun je deze op welke manier dan ook presenteren.

Precies.

[LordLarry]

Verwijderd schreef op 28 augustus 2002 @ 13:16:
tja. Dat kan, maar dan moet je je hele datamodel om gaan gooien. Dat is voor mij een signaal dat je eerste model gewoon niet goed was.

1 kolom erbij, maar inderdaad, het blijft een wijziging.
Maar wat als ze besluiten dat ze een leverancier bij willen houden met adres gegevens? Dan moet je jouw model ook om gooien. Dus daarmee is jouw model ook niet goed?

Over die GUI moet je helemaal geen zorgen maken. Dat is pas je presentatielaag. Zolang je gegevens in de database allemaal een kloppende relatie hebben, kun je deze op welke manier dan ook presenteren.

Klopt als een bus. Er zit alleen een tijdsverschil in het implementeren van de beide opties. Qua GUI en DB ontwerp. Dat zou een overweging kunnen zijn om voor het ene of het andere te kiezen. Ook de mogelijkheid tot uitbereidbaarheid speelt een rol. En als laatste zit er een performence verschil tussen de beide.

[Verwijderd]

Tabel ITEMS (id, parentID, Item, Value)

Dit werkt altijd!

[Verwijderd]

LordLarry schreef op 28 augustus 2002 @ 13:51:
[...]

1 kolom erbij, maar inderdaad, het blijft een wijziging.
Maar wat als ze besluiten dat ze een leverancier bij willen houden met adres gegevens? Dan moet je jouw model ook om gooien. Dus daarmee is jouw model ook niet goed?

Jawel, want mijn producten blijven verder dan hetzelfde. Voor relatie/leverancier beheer kun je gewoon een apart stuk programma schrijven.
Het enige is de koppeling met je producten.

Jouw wijziging is heel anders. Maar ok, we komen er volgens mij toch niet uit, er zijn voor allebei dingen te zeggen. Als je snel een product wilt opleveren kun je misschien beter jouw manier nemen. Ik vind alleen dat dat niet handig/herbruikbaar is.

[LordLarry]

Dan zijn we het toch nog eens

[Zoijar]

Verwijderd schreef op 27 augustus 2002 @ 13:52:
[...]


Overigens zou je dan *dat is waarschijnlijk jouw insteek* de relatie kunnen opheffen door een DELETE FROM table WHERE device = integer AND property = integer statement uit te voeren, maar ik persoonlijk vindt het altijd netter en veiliger om dit soort acties adhv een auto increment uit te voeren.

Bij een n:m relatie moet je natuurlijk nooit een aparte auto-increment PK maken. Je kan dan dezelfde relatie twee keer in je tabel hebben, dat is raar. Het is dus niet netter en zeker niet veiliger
Gewoon uit je schema halen op automatische piloot, "ik zie een n:m relatie, ik maak een nieuwe tabel en de PK is de samenstelling van de PKs van de twee entiteiten waar de relatie tussen ligt"

[Verwijderd]

LordLarry schreef op 28 augustus 2002 @ 15:22:
Dan zijn we het toch nog eens

klopt

Klaas schreef op 27 augustus 2002 @ 14:13 onder andere:
[...]

Da's puur gevoelsmatig. Als je het zonder id doet (zoals ACM ook al zei) weet je tenminste zeker dat je ook geen dubbele koppeling maakt. Device en property vormen dan samen de primary key. Je db zorgt er dan wel voor dat je er niet 2 dezelfde van aanmaakt.
Leg de checks ed altijd zoveel mogelijk bij je database en niet in je software.

En toen schreef Zoijar op 28 augustus 2002 @ 15:33:
[...]

Bij een n:m relatie moet je natuurlijk nooit een aparte auto-increment PK maken. Je kan dan dezelfde relatie twee keer in je tabel hebben, dat is raar. Het is dus niet netter en zeker niet veiliger
Gewoon uit je schema halen op automatische piloot, "ik zie een n:m relatie, ik maak een nieuwe tabel en de PK is de samenstelling van de PKs van de twee entiteiten waar de relatie tussen ligt"

Errm... Zie ik nou 'n echo

_{edit: Hmm, als ik er nu zo zelf naar kijk komt 't wel een beetje lullig over. Zo bedoel ik 't niet}

[Zoijar]

Verwijderd schreef op 28 augustus 2002 @ 16:05:
Errm... Zie ik nou 'n echo

_{edit: Hmm, als ik er nu zo zelf naar kijk komt 't wel een beetje lullig over. Zo bedoel ik 't niet}

Maakt niet uit

Ik had die andere post niet gelezen. Maar in principe zeg ik ook iets anders. Het klonk zo alsof het een keuze is die je maakt en dat het allebei wel kan. Maar dat is niet zo, het is echt fout ontwerp.

[Verwijderd]

Zoijar schreef op 28 augustus 2002 @ 16:30:
[...]


Maakt niet uit

Ik had die andere post niet gelezen. Maar in principe zeg ik ook iets anders. Het klonk zo alsof het een keuze is die je maakt en dat het allebei wel kan. Maar dat is niet zo, het is echt fout ontwerp.

Dat ben ik met je eens. Het is echt onveilig als je voor een koppeltabel weer een aparte id gaat maken. Het zal _meestal_ wel goed gaan, maar da's natuurlijk geen reden