[Datamodel] Start

woensdag 7 april 2004 21:22

Op zich ziet het er niet verkeerd uit. Wat ik ABSOLUUT zou doen is die prefixes weggooien. PR_ID en CK_ID, wat zijn dat? ProductID, geen PR_ID. COM_Naam is bv minder goed, kies Naam, het zit al in een tabel, Compleet. Ik zou 'Compleet' overigens CompleetProduct noemen en CompleetProduct zou ik CompleetProductSamenstelling of iets dergelijks noemen.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

de mouw is uit de aap

Boss schreef op 07 april 2004 @ 21:04:
ik vind het idee van hoe je 'samengestelde' producten opslaat een beetje vreemd, maar dat komt misschien omdat ik je producten niet helemaal ken. Van een samengesteld product kan je nu bijv. ook 1 onderdeel op 'verkocht' zetten, terwijl dat toch niet zou moeten kunnen?

Inderdaad, je moet denk ik een product welke samengesteld is uit maar één product toch zien als samengesteld product, althans database technisch is dat handiger.

woensdag 7 april 2004 21:25

Acties:

Verwijderd

Topicstarter

Daar heb je inderdaad gelijk in maar ik moet wel producten op verkocht kunnen zetten. Misschien moet ik voor complete producten ook een verkocht kolom toevoegen maar dan houd je jouw probleem dat losse producten op verkocht gezet zouden kunnen. Zoals gezegd werk ik hier voor het eerst mee dus misschien heb je een beter voorstel om dit te doen?

Misschien zoals Seweso zegt om alle producten als samengestelde te zien, misschien wat tips hoe de tabellen er dan uit komen te zien?

[ Voor 17% gewijzigd door Verwijderd op 07-04-2004 21:28 ]

woensdag 7 april 2004 21:33

Acties:

de mouw is uit de aap

Volgens mij heb je de volgende dingen nodig:

productgroep
• kan één of meerdere producten bevatten.
• kan verkocht worden
• heeft een aanbieder
• heeft een prijs

product
• technische gegevens

aanbieder
• bla bla

Maar ja, allemaal leuk en aardig maar wat moet je ermee? Stel dat je inderdaad een bestek in de database invoert. Moet je dan elke lepel apart invoeren? Kijk als het om unieke items gaat (antiek?) kan ik me dat voorstellen. Maar een lepel is een lepel en een vork is ook gewoon maar een vork. Daar zou ik niet te veel bytes aan willen spenderen...

woensdag 7 april 2004 23:22

Acties:

Verwijderd

Topicstarter

Ja, het gaat inderdaad om allemaal unieke producten.

Misschien is een ander voorbeeld beter. Stel het gaat om artikelen uit een slaapkamer. Je kan een compleet ingerichte slaapkamer kopen maar op de site worden ook losse componenten als bedden, kledingkasten, nachtkastjes etc. verkocht. Ik moet dus makkelijk alle losse producten kunnen tonen maar ook de complete slaapkamers met dus een lijst van alle producten die in die complete slaapkamer voorkomen inclusief details daarover.

Jij zegt dan: zet alle details over een product in tabel product en geef elk product een productgroepcode. Is het een los product dan heeft het een unieke productgroepcode en behoort een product tot een complete slaapkamer dan hebben meerdere producten dezelfde productgroepcode. Zet ik dan in de productgroeptabel ook een verwijzing naar de categorie zodat je weet of het om een los product gaat of een compleet product of plaats je dat op Product niveau?

donderdag 8 april 2004 10:43

Acties:

de mouw is uit de aap

Verwijderd schreef op 07 april 2004 @ 23:22:
...
Zet ik dan in de productgroeptabel ook een verwijzing naar de categorie zodat je weet of het om een los product gaat of een compleet product of plaats je dat op Product niveau?

Dat laatste hoef je niet bij te houden, dat is namelijk een afleidbaar-feit. Ik leg uit: Als je wil weten of een groep uit maar één product bestaat en dus een "los product" is, dan hoef je alleen maar te tellen hoeveel producten er binnen die groep zitten. "SELECT COUNT(*) FROM `product` WHERE `group` = '$groupid'"; Bij 1 product is het een "los product" en bij > 1 is het een "compleet product".

Als je dingen dubbel in een database opslaat dan moet je ook dingen dubbel programmeren (meer werk). Gebruik altijd zo min mogelijk tabellen, zo min mogelijk velden en gebruik zo min mogelijk rijen om gegevens op te slaan.

donderdag 8 april 2004 11:01

Acties:

Boss

+1 Overgewaardeerd

Je zou het nog anders kunnen doen. Bij het slaapkamer voorbeeld moest ik denken aan de situatie waarin een product (bed bijvoorbeeld) het onderdeel kan zijn van verschillende samengestelde producten.
Dan moet je dus echt 1 tabel maken met alle losse producten (de onderdelen) en daarna een tabel met de combinaties. En dan nog steeds kan het ook voorkomen dat een combinatie uit slechts 1 product bestaat!

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.

donderdag 8 april 2004 13:32

Acties:

Verwijderd

Topicstarter

Boss> Ik begrijp geloof ik niet helemaal waarin jouw aanpak verschilt van die van Seweso. In beide gevallen heb je toch een tabel met losse producten (Product) en een tabel voor samengestelde (productgroep tabel van Seweso).

Dat laatste hoef je niet bij te houden, dat is namelijk een afleidbaar-feit.

Ik dacht dat het misschien later met queries handiger zou zijn. I.p.v dat je via een count moet bepalen of het een los/compleet product het gewoon op j/n zet. Voor losse producten zou een querie dan toch makkelijk moeten zijn: geef me alle producten uit categorie 1 (bed) en die niet onderdeel uitmaken van compleet product.

Aangezien ik nog weinig met PHP/SQL heb gewerkt kan ik nog niet zo goed overzien welke consequenties alles heeft.

donderdag 8 april 2004 17:11

Acties:

vrijdag 9 april 2004 00:24

seweso schreef op 08 april 2004 @ 10:43:
Dat laatste hoef je niet bij te houden, dat is namelijk een afleidbaar-feit. Ik leg uit: Als je wil weten of een groep uit maar één product bestaat en dus een "los product" is, dan hoef je alleen maar te tellen hoeveel producten er binnen die groep zitten. "SELECT COUNT(*) FROM `product` WHERE `group` = '$groupid'"; Bij 1 product is het een "los product" en bij > 1 is het een "compleet product".

NOOIT je model aanpassen aan queries. Het model is statisch en moet correct zijn. Daarna ga je je model pas queryen.

Als je dingen dubbel in een database opslaat dan moet je ook dingen dubbel programmeren (meer werk). Gebruik altijd zo min mogelijk tabellen, zo min mogelijk velden en gebruik zo min mogelijk rijen om gegevens op te slaan.

Dus jij pleit voor 1 grote tabel? De TS heeft een vraag, het lijkt me dan ook verstandig om de persoon van goed advies te voorzien. Wat jij hierboven geeft is prutsen, sorry. Een goed uitgenormaliseerd model heeft t.a.t. de voorkeur, het is nl. het directe resultaat van een abstract correct model.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Verwijderd

Topicstarter

Een goed uitgenormaliseerd model heeft t.a.t. de voorkeur, het is nl. het directe resultaat van een abstract correct model.

Klinkt goed maar kun je me ook op weg helpen om tot zoiets te komen! Ben erg benieuwd hoe jouw design eruit zou zien.

vrijdag 9 april 2004 01:09

Acties:

LinuX-TUX

Wat jij wil leren is het samenstellen van een Database waarin alle vragen naar mogelijke informatie in kunnen worden beantwoord

Ik heb hier een boek liggen naast me, dat ik schat op minimaal 1 Kilo papier

(ISBN: 90-430-0595-9)

Vergeef me als de volgende begrippen vaag beginnen te worden, ik had eerst ook zoiets van "heee, let's make a movie database, whoppa, that fits and also works, lets go on", maar nu ik wat serieuser met het onderwerp bezig ben ivm m'n opleiding begint het echt harder en harder te worden.

Wat je voor jezelf zou moeten maken is een ERD. An E R D what? Een Entiteit Relatie Diagram (klinkt niet in het nederlands, maar klopt wel

) Hierin loop je alle onderwerpen/entiteiten af en geef je ze allemaal attributen die daarbij behoren. (Entiteit:>Personen Attributen>ID,naam,adres,postcode,woonplaats)

Zoals je hierboven vroeg richting "wat is een normalisatie"? Klein voorbeeld: Personen: ID, naam,adres,postcode,woonplaats. <> Een generaal tabel, met 2 sub-type tabellen: 1 voor de klanten (bijvoorbeeld bedrijf waar ze werken) en 1 voor de medewerkers (06 nummer voor als ze in het weekend opgeroepen moeten worden). Helaas zag ik niet 123 in jouw voorbeeld waar het bij toegepast kon worden, maar het is ook niet zo vroeg meer

Ga alsjeblieft voor jezelf een echte E R D maken. (link is een voorbeeldje inclusief kardinaliteit en slecht gedefinieerde relaties

) Hiermee loop je express tegen een hoop "maar wat als, dan, anders" vragen op, waardoor je uiteindelijk een mooi algemeen, op de toekomst voorbereid geheel krijgt. De queries die daaruit volgen kunnen dan soms wat moeilijk zijn en omslachtig lijken, maar je database des te efficienter.

Tot slot: waarom geven wij bijna geen direct antwoord op je vraag? Daarvoor zou je in een chatkanaal moeten zitten. We weten gewoonweg niet hoe gedetailleerd en uitgebreid je alles voor elkaar wil gaan krijgen. Voor die Complete producten en losse producten had ik zelf een koppeltabel in gedachten, maar wie ben ik

Voor de rest zal de huidige opbouw wel aan jouw eisen (kwa zoeken) voldoen.

vrijdag 9 april 2004 09:01

Acties:

vrijdag 9 april 2004 09:32

Ik zou toch meer pleiten voor een NIAM/ORM model: http://www.orm.net.
Gratis ORM modeler voor windows:
http://www.microsoft.com/...39-4286-B8B6-7A9B84CFA709

Je modelt het model daarin en genereert dan de DDL Sql ermee.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

de mouw is uit de aap

EfBe schreef op 08 april 2004 @ 17:11:
[...]
Dus jij pleit voor 1 grote tabel? De TS heeft een vraag, het lijkt me dan ook verstandig om de persoon van goed advies te voorzien. Wat jij hierboven geeft is prutsen, sorry. Een goed uitgenormaliseerd model heeft t.a.t. de voorkeur, het is nl. het directe resultaat van een abstract correct model.

Ja nee hèhè je kunt inderdaad ook te weinig tabellen hebben, misschien was uitleg over hoe je een goede relationele database moet maken beter (m.b.v. een linkje misschien). Maar dan ben je iemand ook niet echt concreet aan het helpen. Hoewel het natuurlijk wel heel leerzaam kan zijn als je zelf een beetje loopt te freubelen.

Het is trouwens wél mogelijk om een heel systeem te bouwen op maar één tabel. Ik heb namelijk zo (met maar 5 velden) een systeem gebouwd waarmee je allerlei objecten kan opslaan. Dus waar je classen in kan definieren met eigenschappen en waar je objecten kan toevoegen van een bepaalde class (waarbij de grafische user-interface voor dat object automatisch word gegenereerd zodat je de eigenschappen kan wijzigen).

vrijdag 9 april 2004 09:46

Acties:

cameodski

seweso schreef op 09 april 2004 @ 09:32:
Het is trouwens wél mogelijk om een heel systeem te bouwen op maar één tabel. Ik heb namelijk zo (met maar 5 velden) een systeem gebouwd waarmee je allerlei objecten kan opslaan. Dus waar je classen in kan definieren met eigenschappen en waar je objecten kan toevoegen van een bepaalde class (waarbij de grafische user-interface voor dat object automatisch word gegenereerd zodat je de eigenschappen kan wijzigen).

En waarom heb je toen gebruik gemaakt van een database. Je had dan net zo goed tekstbestanden kunnen gebruiken?

[ Voor 4% gewijzigd door cameodski op 09-04-2004 09:46 ]

Never underestimate the power of

vrijdag 9 april 2004 10:57

Acties:

de mouw is uit de aap

cameodski schreef op 09 april 2004 @ 09:46:
[...]

En waarom heb je toen gebruik gemaakt van een database. Je had dan net zo goed tekstbestanden kunnen gebruiken?

Een database is toch wel een heel stuk sneller dan een tekst bestand, mits je gericht informatie zoekt.

Als de TS ook met classen wil werken (dus dat je voor een bed andere eigenschappen kan bijhouden dan bij een vork) dan is dit niet offtopic en anders moet die discussie wellicht ergens anders gevoerd worden (als men het nog niet snapt).

vrijdag 9 april 2004 11:16

Acties:

vrijdag 9 april 2004 11:48

seweso schreef op 09 april 2004 @ 09:32:
Ja nee hèhè je kunt inderdaad ook te weinig tabellen hebben, misschien was uitleg over hoe je een goede relationele database moet maken beter (m.b.v. een linkje misschien). Maar dan ben je iemand ook niet echt concreet aan het helpen. Hoewel het natuurlijk wel heel leerzaam kan zijn als je zelf een beetje loopt te freubelen.

Een datamodel maken is een serieuze taak, dat begint niet met freubelen, maar met het lezen van wat theorie over hoe en wat. Iedere gek en zn broer kunnen wat tabelletjes in elkaar flanzen met een wizard. Dat maakt het nog geen goed datamodel. Een datamodel dat niet correct is zorgt ervoor dat de applicatie ook niet correct te bouwen is. Het heeft dan ook inmense impact op je applicatie en kijken naar het aantal tabellen of velden is GEEN juiste manier om te bepalen of je op de juiste weg zit. Het gebruiken van een modelleringstechniek die in een half uurtje te leren is echter wel.

Het is trouwens wél mogelijk om een heel systeem te bouwen op maar één tabel. Ik heb namelijk zo (met maar 5 velden) een systeem gebouwd waarmee je allerlei objecten kan opslaan. Dus waar je classen in kan definieren met eigenschappen en waar je objecten kan toevoegen van een bepaalde class (waarbij de grafische user-interface voor dat object automatisch word gegenereerd zodat je de eigenschappen kan wijzigen).

Ik kan een systeem bouwen met 1 tabel en 2 fields: ID (GUID) en een binair field waarin in het object serialize. Nuttig? nee in het geheel niet, want het is niet te querien. Als ik 10 entities heb met ieder 10 attributes, dan heb ik dus 10 tables met ieder 10 fields, en een hele rits constraints (foreign, unique, primary key). Gewoon die free modeller gebruiken en wat theorie over ORM lezen en je hebt binnen een uur een model klaar wat correct is en werkt en onderhoudbaar is.

seweso schreef op 09 april 2004 @ 10:57:
Een database is toch wel een heel stuk sneller dan een tekst bestand, mits je gericht informatie zoekt.

Nou, in jouw opzet lijkt me dat niet.

Als de TS ook met classen wil werken (dus dat je voor een bed andere eigenschappen kan bijhouden dan bij een vork) dan is dit niet offtopic en anders moet die discussie wellicht ergens anders gevoerd worden (als men het nog niet snapt).

Wat hebben de classes te maken met het model? Ik denk toch echt dat de TS meer kaas van datamodellering snapt dan jij.

[ Voor 14% gewijzigd door EfBe op 09-04-2004 11:17 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

de mouw is uit de aap

EfBe schreef op 09 april 2004 @ 11:16:
[...]

Een datamodel maken is een serieuze taak, dat begint niet met freubelen, maar met het lezen van wat theorie over hoe en wat. Iedere gek en zn broer kunnen wat tabelletjes in elkaar flanzen met een wizard. Dat maakt het nog geen goed datamodel. Een datamodel dat niet correct is zorgt ervoor dat de applicatie ook niet correct te bouwen is. Het heeft dan ook inmense impact op je applicatie en kijken naar het aantal tabellen of velden is GEEN juiste manier om te bepalen of je op de juiste weg zit. Het gebruiken van een modelleringstechniek die in een half uurtje te leren is echter wel.

[...]

Ik kan een systeem bouwen met 1 tabel en 2 fields: ID (GUID) en een binair field waarin in het object serialize. Nuttig? nee in het geheel niet, want het is niet te querien. Als ik 10 entities heb met ieder 10 attributes, dan heb ik dus 10 tables met ieder 10 fields, en een hele rits constraints (foreign, unique, primary key). Gewoon die free modeller gebruiken en wat theorie over ORM lezen en je hebt binnen een uur een model klaar wat correct is en werkt en onderhoudbaar is.

[...]

Nou, in jouw opzet lijkt me dat niet.

[...]

Wat hebben de classes te maken met het model? Ik denk toch echt dat de TS meer kaas van datamodellering snapt dan jij.

Misschien is het handiger om hier verder te discussieren en om hier concreet de TS te helpen

vrijdag 9 april 2004 11:58

Acties:

Verwijderd

@ EfBe

Ik zou zeker niet kiezen voor een veldnaam 'Naam' in een tabel.

Stel dat je nog een tabel hebt met een veldnaam 'Naam'.
Dat krijg je dus problemen als je bijvoorbeeld een select doe.
(je kunt natuurlijk "Select P.Naam AS productnaam FROM tblProducten P" doen, maar ik pleit toch voor duidelijke namen en minder script)

Ook is het onderscheid in je script vaak niet duidelijk als je geen duidelijke veldnamen gebruikt.

Dus in een tabel 'Producten':

lngProductID
lngPr_CategorieID (sleutel naar lngCategorieID in tabel 'Categorieen')
txtPr_Naam

En in een tabel 'Categorieen':

lngCategorieID
txtCa_Naam

[ Voor 18% gewijzigd door Verwijderd op 09-04-2004 12:00 ]

vrijdag 9 april 2004 12:57

Acties: