[Alg]normalizen van db? hoe ver?

[muis|IA]

ik zit hier naar een acces db te kijken.
Er is in een tabel "producten" een veld "zichtbaar", een product kan zichtbaar zijn of niet.
Nu zou ik zeggen van gebruik een "0" voor niet zichtbaar en een "1" voor zichtbaar.
Maar in deze db staat een tabel "constanten" waar 2 velden inzitten nl: "id" en "omschrijving".
er is in dit geval een record met id = 3 en omschrijving = "zichtbaar" en een record met id = 4 en omschrijving = "niet zichtbaar"
is dit nou optimaal optimalizeren of is dit overbodig
(ik hoop trouwens dat ik dit een beetje begrijpelijk heb neergezet)

[BasieP]

ik denk dat 'omschrijving' niet bedoeld was om 'niet zichtbaar' neer te zetten eigenlijk
verder kan je 'zichtbaar' en 'niet zichtbaar' inderdaad met een 1 en een 0 doen, maar echt duidelijker wordt het er dan niet op

[gorgi_19]

Erhm.. Nee.. Ik snap er niets van. Wat je volgens mij bedoeld:

Producten:
ProductID Autonumber
Naam Tekst
Zichtbaar True/False

Constanten
ID autonumber
Omschrijving Tekst
Waarde Tekst / numeriek (naar gelang de waarde)

edit:

Nu wel, ik vind het in ieder geval overbodig..

[ Voor 13% gewijzigd door gorgi_19 op 09-01-2003 11:27 ]

[muis|IA]

ja idd zoals je zegt (ongeveer)
en dat is dus producten.zichtbaar gekoppeld aan constanten.id

[gorgi_19]

muis|IA schreef op 09 januari 2003 @ 11:27:
ja idd zoals je zegt (ongeveer)
en dat is dus producten.zichtbaar gekoppeld aan constanten.id

En dat is naar mijn idee overbodig...

Aangezien een product per definitie zichtbaar of onzichtbaar is, kan imho dit beter opgevangen worden door een booleanveld in de productentabel.

Ik zou deze relatie dus niet eens aanbrengen.

[ Voor 7% gewijzigd door gorgi_19 op 09-01-2003 11:28 ]

[BasieP]

muis|IA schreef op 09 January 2003 @ 11:27:
ja idd zoals je zegt (ongeveer)
en dat is dus producten.zichtbaar gekoppeld aan constanten.id

dat lijkt me wel weer nutteloos, aangezien het toch vrij duidelijk is dat '1' wel zichtbaar is en '0' niet zichtbaar

om nou daarvoor een extra tabel in het leven te roepen

[Verwijderd]

Kwa normalisatie volstrekt overbodig; het is altijd true of false. Ga je er meer een statusveld van maken dan kan het wel handig zijn. En gezien de nummering (id's) heeft er ooit meer in de tabel gestaan!

[ Voor 21% gewijzigd door Verwijderd op 09-01-2003 11:32 ]

[Janoz]

Die extra koppeling is eigenlijk alleen nodig waneer je vanaf het begin niet zeker weet wat alle opties zijn. Denk bijvoorbeeld aan de vestigingen van een bedrijf. Dat is nu constant, maar over een paar jaar zou er nog een pandje gehuurd kunnen worden.

In dit geval is vanaf het begin duidelijk wat de mogenlijke opties zijn. Ik neem niet aan dat er over enkele tijd ook een 'beetje zichtbaar' optie toegevoegd zou moeten worden.

[muis|IA]

Zo is er ook een tabel:
geslacht:
ID Autonumber
geslacht Tekst

Dit schijnt dan optimaal geoptimaliseerd te zijn, want als je een geslacht opeens "man" wilt noemen ipv "m" is dit makkelijk.
Maar het lijkt mij dat je dat soort dingen vooraf bepaald

[Verwijderd]

Boyce-Cott Normal form: Alle mogelijke foreign keys zijn primary keys (toch?)

[gorgi_19]

muis|IA schreef op 09 January 2003 @ 11:35:
Zo is er ook een tabel:
geslacht:
ID Autonumber
geslacht Tekst

Dit schijnt dan optimaal geoptimaliseerd te zijn, want als je een geslacht opeens "man" wilt noemen ipv "m" is dit makkelijk.
Maar het lijkt mij dat je dat soort dingen vooraf bepaald

Het probleem dat je nu schetst is een presentatietechnisch iets, niet iets van een dataprobleem.

Ben je nu bezig met de teksten eenvoudig op te te slaan of ben je met data bezig.

[ Voor 19% gewijzigd door gorgi_19 op 09-01-2003 11:39 ]

[Verwijderd]

Verwijderd schreef op 09 January 2003 @ 11:36:
Boyce-Cott Normal form: Alle mogelijke foreign keys zijn primary keys (toch?)

Lol, boyce Codd (niet met t), nog even leren voor databases van morgen!

[TheGhostInc]

Even over Access... (hehe)

AAAHHH, normalisaties in access kunnen echt rampzalig zijn, nu zul je er waarschijnlijk geen last van krijgen, maar een grote Access DB zuigt echt gigantisch.
Je krijgt me dan een partij queries om je oren, daar wordt zelfs MySQL bang van

[gorgi_19]

TheGhostInc schreef op 09 January 2003 @ 11:59:
Even over Access... (hehe)

AAAHHH, normalisaties in access kunnen echt rampzalig zijn, nu zul je er waarschijnlijk geen last van krijgen, maar een grote Access DB zuigt echt gigantisch.
Je krijgt me dan een partij queries om je oren, daar wordt zelfs MySQL bang van

Wat is het verschil in normalisaties tussen bijvoorbeeld Access en SQL server?
Waarom is Microsoft Access slecht op dit gebied? (heb het nu niet over performance, maar normalisatie)

[Verwijderd]

Verwijderd schreef op 09 januari 2003 @ 11:38:
[...]
Lol, boyce Codd (niet met t), nog even leren voor databases van morgen!

Haha... Ja was alweer een jaartje of 3 geleden dat databases....

[Creepy]

TheGhostInc schreef op 09 January 2003 @ 11:59:
Even over Access... (hehe)

AAAHHH, normalisaties in access kunnen echt rampzalig zijn, nu zul je er waarschijnlijk geen last van krijgen, maar een grote Access DB zuigt echt gigantisch.
Je krijgt me dan een partij queries om je oren, daar wordt zelfs MySQL bang van

Moet je ook niet je queries door access laten genereren
(als je zelf goed aan het normaliseren gaat, ben je zelf ook wel in staat om je eigen queries te bedenken i.p.v. access te laten gokken wat jij wil)

[jvdmeer]

Zolang er natuurlijk alleen met de status 'zichtbaar' 'niet zichtbaar' wordt gewerkt, is deze normalisatie overbodig. Maar, dit biedt wel toekomstmogelijkheden als:
status:
5..100: zichtbaar voor speciale doelgroepen

Maar waarschijnlijk is het dan beter om daar weer een aparte groepen en tussentabel voor aan te maken.

[Verwijderd]

Als je naar Boyce Codd normaliseert (is uitgebreidere versie van 3NF) zul je nagenoeg nooit problemen hebben met db anomalies. 4 en 5 NF zijn alleen voor zeer zelden voorkomende gevallen.

[Gerco]

Het zou weleens handig kunnen zijn om het op die manier te doen...

We hebben bijvoorbeeld hier in de personeelstabel een veldje man/vrouw, dat is een nummertje1/2. In een andere tabel (andere db ook trouwens, de translation db) staat dus 1 = man, 2 = vrouw. Op die manier kun je gemakkelijk je applicatie vertalen, hoef je alleen maar even die tabel te veranderen, anders moet je je resource file veranderen (en aangezien deze prog taal niet aan resource files doet...).

[Orphix]

Ik vind dit ook geen overbodige luxe. Waarom niet?
Nou in Access kan je heel makkelijk (keuze)lijstjes maken die hun gegevens halen uit een tabel (of query). Je kan dan de omschrijving laten zien (zichtbaar,onzichtbaar) terwijl automatisch het bijbehorende id wordt opgeslagen in de huidige record.

Dit brengt trouwens ook geen performanceverlies met zich mee. Enkel als je de tabel 'constanten' in de query meeneemt dmv een join zal de performance (ietsje) achteruit gaan. Maar dit zal in veel gevallen (intern gebruik) niet nodig zijn.
Bekijk het vanuit de gebruikerskant, stel deze query wordt benaderd via excel voor een minder gevorde pc gebruiker. Die zal makkelijker kunnen filteren op 'zichtbaar' dan op '1' (of 0?)

[Janoz]

Maar op dat moment ben je (zoals gorgi_19 eerder al zei) bezig metde presentatie laag. Het hoort bij de view en niet bij de data. Een mapping van bepaalde codes naar human readable tekst is iets dat onderdeel uit maakt van de presentatie laag en niet je buisness logic.

[Gerco]

Janoz schreef op 09 January 2003 @ 20:28:
Een mapping van bepaalde codes naar human readable tekst is iets dat onderdeel uit maakt van de presentatie laag en niet je buisness logic.

Neemt niet weg dat je die mapping ook best mag voorbereiden in je database (translation database/tabel). Als je bij het ontwerp van het datamodel geen enkele rekening mag houden met hoe het gepresenteerd moet worden (zoals mogelijkheid tot vertalen) ga je wel erg moeilijk doen.

[gorgi_19]

Wat heeft je datalaag met je presentatielaag te maken? Naar mijn idee niets; desnoods noem je alle kolomnamen a, b, c.

Anders heeft het namelijk ook geen zin om uberhaupt van een datalayer, business logic layer of presentation layer te spreken. en deze lagen te scheiden.

Stel je voor dat je besluit om een andere voorkant (presentation layer) te maken. In principje moet je dan je gehele database overnieuw ontwerpen, omdat er een complete mix is van beiden.

[ Voor 4% gewijzigd door gorgi_19 op 09-01-2003 21:16 ]

[Gerco]

gorgi_19 schreef op 09 January 2003 @ 21:15:
Wat heeft je datalaag met je presentatielaag te maken? Naar mijn idee niets; desnoods noem je alle kolomnamen a, b, c.

Dat zou je inderdaad kunnen doen, maar als je dus helemaal geen data als "Man" "Vrouw" in je database mocht opnemen kon je ook niet vertalen! Je buisness logic hoeft helemaal niet te weten dat dat tabelletje uberhaupt bestaat om die 1 en 2 te kunnen gebruiken. Dat tabelletje is er puur voor de mooiheid van de interface.

Als je helemaal niets van je data mag gebruiken om je interface te bepalen zouden user settings over kleuren, plaatsen en dat soort dingen ook absoluut niet mogen (je bent dan immers interface informatie in je database aan het opslaan, oeeeeh evil!)

[gorgi_19]

Gerco schreef op 09 January 2003 @ 21:21:
[...]

Dat zou je inderdaad kunnen doen, maar als je dus helemaal geen data als "Man" "Vrouw" in je database mocht opnemen kon je ook niet vertalen! Je buisness logic hoeft helemaal niet te weten dat dat tabelletje uberhaupt bestaat om die 1 en 2 te kunnen gebruiken. Dat tabelletje is er puur voor de mooiheid van de interface.

Afhankelijk van de strictheid van de keuze, is een booleanveld voor dit voorbeeld in principe ook voldoende, maar dat terzijde. Je kan best data (in de vorm van gegevens) opnemen in je database, het moet volledig losstaan van je datastructuur.

Als je helemaal niets van je data mag gebruiken om je interface te bepalen zouden user settings over kleuren, plaatsen en dat soort dingen ook absoluut niet mogen (je bent dan immers interface informatie in je database aan het opslaan, oeeeeh evil!)

Deze gegevens gaan dan netjes via je data layer, business logic naar je presentation layer en is in principe een vorm van content en hebben geen invloed op je datastructuur.

[Gerco]

gorgi_19 schreef op 09 januari 2003 @ 21:26:
Deze gegevens gaan dan netjes via je data layer, business logic naar je presentation layer en is in principe een vorm van content en hebben geen invloed op je datastructuur.

Een tabelletje om een code zoals true of false te vertalen naar een waarde als "Man" en "Vrouw" heeft ook geen invloed op je datastructuur. Het is dan immers een gebruikersinstelling om aan te geven hoe de gebruiker de waarde True/False in het veld Geslacht van de personeelstabel wil zien. Dat is een vorm van content en gaat dan netjes van de Data, door de buisness naar de presentation layer en heeft niets te maken met je datamodel.

[ Voor 4% gewijzigd door Gerco op 09-01-2003 21:40 ]

[gorgi_19]

* gorgi_19 krijgt steeds meer het idee dat we gigantisch langs elkaar heen lopen te praten en hetzelfde bedoelen...

[Gerco]

gorgi_19 schreef op 09 januari 2003 @ 21:51:
* gorgi_19 krijgt steeds meer het idee dat we gigantisch langs elkaar heen lopen te praten en hetzelfde bedoelen...

Zou best wel eens kunnen

[djluc]

Het zou gewoon onlogisch zijn om letterlijk man of vrouw in de db te zetten bij een record waar het er om gaat om een profiel van iemand op te slaan, dat is dus van belang!, omdat het dan onmogelijk wordt om een andere taal of wat dan ook te gebruiken. Dan moet je natuurlijk niet gaan roepen dat je geen uiterlijke gegevens in de db mag zetten zoals kleuren want dat slaat natuurlijk helemaal nergens op, daar gaat het nu niet over.