[SQL] En waarom normaliseer jij niet?

[BikkelZ]

Ik kwam het vandaag weer tegen........een statusveld in een tabel waarbij de vijf verschillende statussen gewoon in plain text er in gerost zijn. Iedereen die ik er over spreek zweert altijd netjes te normaliseren tot Boyce Codd and beyond, maar tóch lopen er rakkers rond die een database blijven zien als een verzameling CSV bestandjes.

Ik wil aan de ene kant de achterliggende reden weten waarom duurbetaalde en getrainde professionals tóch voor die - in mijn ogen - inferieure oplossing kiezen, en aan de andere kant kan dit topic misschien ook nog wel als een soort van coming out topic werken

Want je weet dat ze er zijn en toch ontkent iedereen het

[zwippie]

Omdat het er snel even tussengefrot moest worden? Of omdat het er al 3 jaar zo staat en niemand het durft te veranderen?

Bedoel je in je voorbeeld trouwens dat er een enum wordt gebruikt ipv een aparte statustabel? Vind ik soms nog wel te rechtvaardigen...

[disjfa]

Er kunnen 20.000 redenen zijn dat dit zo inelkaar zit. Wat is precies het problem. Zoals meneer boven mij, een enum. Indexje erop (niet al te netjes maar kan) of iets dergelijks.

Waar zit het probleem?

[BikkelZ]

Geen ENUM, gewoon een VARCHARretje. Nog een mooi voorbeeld uit die database: een tabel met 235 kolommen. Maar als er ENUMmetjes gebruikt worden is het wel OK, toch?

Overigens is het status veld ook weer een veld wat op diverse plaatsen terug komt als pulldown of vinkopties. Ga je dan een SELECT DISTINCT doen of zoiets dergelijks of ram je het er dan gewoon hard in?

[momania]

Klinkt gewoon als: "legacy"

En meestal wegen de kosten voor het verbeteren niet op tegen de baten.

Als je het in nieuwe systemen nog tegenkomt heb je gewoon te maken met programmeurs/database ontwerpers die niet in het 'vak' thuis horen

[Creepy]

Het feit dat iets als een VARCHAR in een DB zit wil nog niet zeggen dat er in de code geen enum wordt gebruikt.

Het kan prima zijn dat je bijv. status codes hardcoded hebt omdat er in de code specifieke zaken moeten gebeuren afhankelijk van de status. Als je dan een tabel hebt waar alle beschikbare statussen in hebt staan moet je dus de lijst met statussen op twee plekken gaan bijhouden. Ook is het dan mogelijk een nieuwe status in de DB toe te voegen die dan niet zal gaan werken omdat de code die status niet kent.

Op het moment dat je een SELECT DISTINCT moet doen dan om alle beschikbare statuscodes op te halen dan ben je idd fout bezig en zou je die status tabel wat mij betreft wel moeten hebben.

[ Voor 3% gewijzigd door Creepy op 28-01-2008 16:09 ]

[BikkelZ]

Kijk mij lijkt het het makkelijkste om alles uit de steuntabel Status te halen, wil ik een bepaalde status toevoegen of aanpassen, doe ik dat op één plek en dan wordt het automagisch in heel mijn applicatie opgenomen doordat alles om die tabel draait.

Het gaat om een status als 'accoord', 'opgeleverd', 'afgehandeld', dat soort dingen, dus niet een heel specifieke statuscode.

[disjfa]

accoord, apgeleverd en afgehandeld zijn 3 heel verschillende statussen. Nog steeds geen probleem met een normaal varchar veld.

Waarom zou je alle velden in een db moeten hebben staan?

[Koppensneller]

Deze kwam ik ooit tegen op het werk:

[Creepy]

Als die status voor de code zelf nietszeggend is (en daar lijkt het bij jou over te gaan) dan lijkt het me niet meer dan normaal dat je daar een losse tabel voor hebt. Je hebt dan inderdaad ook de mogelijkheid om on the fly zaken toe te voegen en aan te passen. Maar zoals ik al probeerde te uit te leggen kan het dus prima zijn dat je zo'n tabel juist niet wil hebben als je code er van afhankelijk is en als bijv. die status voor de gebruiker niet (direct) zichtbaar is.

@koppensneller: ieeuw, komma's in de DB om meerdere zaken aan te kunnen geven in 1 veld. Dit is wat mij betreft een duidelijk voorbeeld van niet goed normaliseren (of beter: helemaal niet normaliseren ).

[ Voor 18% gewijzigd door Creepy op 28-01-2008 16:24 ]

[BikkelZ]

Het is in dit geval trouwens MSSQL, dus het ENUM argument telt eigenlijk niet eens.

disjfa schreef op maandag 28 januari 2008 @ 16:15:
accoord, apgeleverd en afgehandeld zijn 3 heel verschillende statussen. Nog steeds geen probleem met een normaal varchar veld.

Waarom zou je alle velden in een db moeten hebben staan?

Omdat ik dan niet alleen alle zaken die afgehandeld zijn moet hebben, maar ook de zaken die DFWHnswls of afgehandel zijn. ENUM daar wil ik nog best een discussie over opstarten, maar een steuntabel gewoon een VARCHAR kolom maken is bullshit.

Creepy schreef op maandag 28 januari 2008 @ 16:20:@koppensneller: ieeuw, komma's in de DB om meerdere zaken aan te kunnen geven in 1 veld. Dit is wat mij betreft een duidelijk voorbeeld van niet goed normaliseren (of beter: helemaal niet normaliseren ).

Hahaha ik snapte niet eens wat er mis was met het voorbeeld tot ik jouw post las. Ik was gewoon niet voorbereid op dit niveau van amateurisme om het te herkennen

[ Voor 35% gewijzigd door BikkelZ op 28-01-2008 16:28 ]

[zwippie]

KoppenSneller schreef op maandag 28 januari 2008 @ 16:17:
Deze kwam ik ooit tegen op het werk:

[afbeelding]

Daar word je inderdaad niet vrolijk van.

Zo ken ik iemand die nog steeds denkt dat een one-table-to-rule-them-all aanpak goed werkt: 1 tabel in je database die álle gegevens bevat...

Maar zo te zien zijn er dus iig 4 redenen om niet te normaliseren:
- Geen verstand van databases
- Legacy db en code
- Tijdgebrek
- Programmeur/ontwerper heeft een hele slimme manier gevonden om het anders te doen

_{Dit onderwerp komt trouwens ook elk jaar weer een keer terug hier op GoT}

[BikkelZ]

whoami schreef op maandag 28 januari 2008 @ 16:32:
.
toch maar weg.
Je weet nooit wie er meeleest.

Tja dat probleem heb ik ook wel eens, dat het praktijkvoorbeeld te herkenbaar is

[Koppensneller]

Creepy schreef op maandag 28 januari 2008 @ 16:20:
@koppensneller: ieeuw, komma's in de DB om meerdere zaken aan te kunnen geven in 1 veld. Dit is wat mij betreft een duidelijk voorbeeld van niet goed normaliseren (of beter: helemaal niet normaliseren ).

Toen ik de ontwikkelaar in kwestie daar op aansprak, zei hij dat hij daar een functie had geschreven die prima kon splitten op die komma's, en dat het dus geen enkel probleem was.

[Creepy]

Zo'n discussie is hier op GoT ook meerdere malen voorbij gekomen. Je krijgt dan ook nog opmerkingen als "met een LIKE '%3%' kan je prima de alle zaken ophalen die als doelgroep item nummer 3 hebben". Dat zo'n query geen indexen kan gebruiken en met veel rijen zo traag is als dikke stront lijkt sommige mensen totaal te ontgaan.

[BikkelZ]

KoppenSneller schreef op maandag 28 januari 2008 @ 16:45:
[...]


Toen ik de ontwikkelaar in kwestie daar op aansprak, zei hij dat hij daar een functie had geschreven die prima kon splitten op die komma's, en dat het dus geen enkel probleem was.

Zonder hem hadden we nu nooit str_explode gehad!

Respect is op zijn plaats

Ik kom overigens een een kolom 'autotelefoon' tegen, ik zet mijn fiches in op 'legacy'

Creepy schreef op maandag 28 januari 2008 @ 16:50:
Zo'n discussie is hier op GoT ook meerdere malen voorbij gekomen. Je krijgt dan ook nog opmerkingen als "met een LIKE '%3%' kan je prima de alle zaken ophalen die als doelgroep item nummer 3 hebben". Dat zo'n query geen indexen kan gebruiken en met veel rijen zo traag is als dikke stront lijkt sommige mensen totaal te ontgaan.

LIKE dat is wel een aardig dure operatie. Maar natuurlijk niet zo duur als iemand die in .Net wel paginating gebruikt maar geen LIMIT parameters instelt: alles wordt dan opgehaald....

[ Voor 39% gewijzigd door BikkelZ op 28-01-2008 16:53 ]

[Anoniem: 45234]

Als ik business intelligence functionaliteit meer nodig is voor mij een reden om niet verder te normaliseren dan naar 2de normaalvorm.

[D-Raven]

KoppenSneller schreef op maandag 28 januari 2008 @ 16:17:
Deze kwam ik ooit tegen op het werk:

[afbeelding]

ARG die column Prefixes . Ik weet niet of ik de enige ben, maar ik vindt die dingen verschrikkelijk. Het gebruik van een alias in een query vindt ik 10x duidelijker.

[Anoniem: 26306]

D-Raven schreef op maandag 28 januari 2008 @ 19:15:

ARG die column Prefixes . Ik weet niet of ik de enige ben, maar ik vindt die dingen verschrikkelijk. Het gebruik van een alias in een query vindt ik 10x duidelijker.

Ik schrijf zelfden queries. Het moet eigenlijk geen bal uitmaken wat je gebruikt. Je kunt mij niet vertellen dat je het onduidelijk vindt. Het is gewoon een afspraak die waarschijnlijk is gemaakt binnen een bedrijf, en daaraan houd je je vervolgens.

[frickY]

Creepy schreef op maandag 28 januari 2008 @ 16:50:
Zo'n discussie is hier op GoT ook meerdere malen voorbij gekomen. Je krijgt dan ook nog opmerkingen als "met een LIKE '%3%' kan je prima de alle zaken ophalen die als doelgroep item nummer 3 hebben". Dat zo'n query geen indexen kan gebruiken en met veel rijen zo traag is als dikke stront lijkt sommige mensen totaal te ontgaan.

Was het maar zo simpel. Helaas wordt het al snel iets als

SQL:

WHERE
   col = '3' OR
   col LIKE '3,%' OR
   col LIKE '%,3' OR
   col LIKE '%,3,%'

Je wilt tenslote niet matchen met '20, 30, 40'.

@Deathraven
Nooit joins op 4 of meer tabellen gebruikt? Of alias je dan ook vrolijk door? En mocht je een tabel voor de 2de, 3de etc keer moeten queryen dan hanteer je dezelfde benamingconventies bij het aliassen of doe je het elke keer weer net een beetje anders?
Prefixen zijn imho een must.

[ Voor 18% gewijzigd door frickY op 28-01-2008 19:27 ]

[Anoniem: 26306]

frickY schreef op maandag 28 januari 2008 @ 19:24:

Was het maar zo simpel. Helaas wordt het al snel iets als

SQL:

WHERE
   col = '3' OR
   col LIKE '3,%' OR
   col LIKE '%,3' OR
   col LIKE '%,3,%'

Je wilt tenslote niet matchen met '20, 30, 40'.

Je mist het punt. Het gaat hem er niet om om een slecht genormaliseerd model nog enigszins te kunnen gebruike. Je moet dit gewoon niet willen. Echt niet.

[frickY]

Volledig mee eens. Mijn punt was dan ook een beetje dat het verbazingwekkend is dat er geen lichtje gaat branden die bovenstaande lopen uit te tikken.

[Kalentum]

BikkelZ schreef op maandag 28 januari 2008 @ 15:39:
Ik wil aan de ene kant de achterliggende reden weten waarom duurbetaalde en getrainde professionals tóch voor die - in mijn ogen - inferieure oplossing kiezen, en aan de andere kant kan dit topic misschien ook nog wel als een soort van coming out topic werken

Luiheid. Gebrek aan kennis van relationele databases. Haastwerk. Een statusveld wat er aanvankelijk niet in bedacht was maar vlak voor oplevering er nog even ingerost wordt. Etc etc. Het is geen perfecte wereld

Zolang dat lijstje met statussen maar op 1 plek staat (in zo'n geval dus in de applicatie) en het aantal records beperkt blijft dan is er uit database oogpunt niet zoveel mis mee (redunantie enzo).

[curry684]

BikkelZ schreef op maandag 28 januari 2008 @ 15:39:
Ik wil aan de ene kant de achterliggende reden weten waarom duurbetaalde en getrainde professionals tóch voor die - in mijn ogen - inferieure oplossing kiezen

Omdat het merendeel van die overbetaalde en slecht getrainde prutsers te stom is om een computer aan te mogen raken, laat staan programmeren.

Meestal is het geen legacy-code, en is er geen verdedigbare reden om stom te ontwikkelen, maar zijn het legacy developers die in de ICT zijn gegaan omdat ze computerspelletjes leuk vonden, omdat ze een auto kregen of omdat het zo leuk verdiende. Of erger nog, omdat ze geen werk konden vinden in hun eigen volstrekt niet-technische vakgebied. Whatever the reason, het is kansloos om te denken dat in ICT wel iedereen verstand van zaken zou hebben en z'n vak zou beheersen als je je indenkt hoeveel prutsers er rondlopen op minder complexe en ongrijpbare vakgebieden.

[Brains]

Er doet zich nu ook een "nieuw" fenomeen voor: het opslaan van XML in een veld. MS SqlServer heeft hier "leuke" hulpmiddelen voor om bijv. xml naar een temptable om te zetten of zelfs te querien op XML nodes.

Dit leidt tot dezelfde problemen als die hierboven genoemd worden: het plaatsen van Indexen kan een probleem worden. Voor tijdelijke opslag van geserialiseerde objecten kan het handig zijn, mits je ze goed indentificeerbaar maakt. Workflow Foundation doet het op deze manier.

[BikkelZ]

curry684 schreef op maandag 28 januari 2008 @ 21:27:
[...]

Omdat het merendeel van die overbetaalde en slecht getrainde prutsers te stom is om een computer aan te mogen raken, laat staan programmeren.

Meestal is het geen legacy-code, en is er geen verdedigbare reden om stom te ontwikkelen, maar zijn het legacy developers die in de ICT zijn gegaan omdat ze computerspelletjes leuk vonden, omdat ze een auto kregen of omdat het zo leuk verdiende. Of erger nog, omdat ze geen werk konden vinden in hun eigen volstrekt niet-technische vakgebied. Whatever the reason, het is kansloos om te denken dat in ICT wel iedereen verstand van zaken zou hebben en z'n vak zou beheersen als je je indenkt hoeveel prutsers er rondlopen op minder complexe en ongrijpbare vakgebieden.

....of omdat je je HBO-I diploma cadeau krijgt voor het op tijd opdagen bij tentamens en het uit je hoofd knallen van de vragen achterin het boek in Nederland.

[curry684]

BikkelZ schreef op maandag 28 januari 2008 @ 21:42:
[...]


....of omdat je je HBO-I diploma cadeau krijgt voor het op tijd opdagen bij tentamens en het uit je hoofd knallen van de vragen achterin het boek in Nederland.

Ook waar helaas.

[Creepy]

Anoniem: 45234 schreef op maandag 28 januari 2008 @ 16:51:
Als ik business intelligence functionaliteit meer nodig is voor mij een reden om niet verder te normaliseren dan naar 2de normaalvorm.

Als je meer nodig wat is dan en misschien een beetje? Ik kan er geen chocola van maken wat je bedoelt.

Wilde gok: je hebt een datawarehouse voor reporting en daar wil je blijkbaar niet verder dan de 2de NV.

[cocoskoek]

frickY schreef op maandag 28 januari 2008 @ 19:24:

@Deathraven
Nooit joins op 4 of meer tabellen gebruikt? Of alias je dan ook vrolijk door? En mocht je een tabel voor de 2de, 3de etc keer moeten queryen dan hanteer je dezelfde benamingconventies bij het aliassen of doe je het elke keer weer net een beetje anders?
Prefixen zijn imho een must.

Ik prefix ook nooit, ik begrijp je punt wel. Maar prefixen met underscores of hoofdletters zal het allicht iets leesbaarder kunnen maken.

[Meekoh]

Creepy schreef op maandag 28 januari 2008 @ 21:56:
[...]

Als je meer nodig wat is dan en misschien een beetje? Ik kan er geen chocola van maken wat je bedoelt.

Wilde gok: je hebt een datawarehouse voor reporting en daar wil je blijkbaar niet verder dan de 2de NV.

Ik ben het toch wel eens met hylke. Ga jij maar eens grote complexe rapportages maken mbv Business intelligence tools. Dat gaat niet op ver genormaliseerde databases. Eigenlijk durf ik zelfs te zeggen dat voor Datawarehousing (Business Intelligence) gewone relationele databases totaal niet geschikt zijn! En dan nog ik heb sommige databases gezien waar ze wel een beetje erg ver waren doorgeslagen in hun normalisatie. Om de meest simpele data op te halen had ik al bijna 10 joins nodig.

[The Eagle]

Stom toeval wil dat ik de laatste paar weken nogal aan het smartcoden ben
Oftewel: we hebben een lijst met translate waarden, en op basis van een bepaalde criteria moet met die translatewaarden een dowpdownlist gevuld worden. Dat krijg je als je 3 systemen moet concolideren in 1 systeem en de 3 eigenaren willen wel graag hun eigen codes enzo houden

[Creepy]

Moshe85 schreef op maandag 28 januari 2008 @ 22:06:
[...]


Ik ben het toch wel eens met hylke. Ga jij maar eens grote complexe rapportages maken mbv Business intelligence tools. Dat gaat niet op ver genormaliseerde databases. Eigenlijk durf ik zelfs te zeggen dat voor Datawarehousing (Business Intelligence) gewone relationele databases totaal niet geschikt zijn! En dan nog ik heb sommige databases gezien waar ze wel een beetje erg ver waren doorgeslagen in hun normalisatie. Om de meest simpele data op te halen had ik al bijna 10 joins nodig.

Ik zeg niet dat ik het niet met hem eens ben, wel dat ik moet gokken wat hij nu bedoelt

[Meekoh]

Creepy schreef op maandag 28 januari 2008 @ 22:21:
[...]

Ik zeg niet dat ik het niet met hem eens ben, wel dat ik moet gokken wat hij nu bedoelt

aaaah op die fiets

[curry684]

Moshe85 schreef op maandag 28 januari 2008 @ 22:06:
[...]


Ik ben het toch wel eens met hylke. Ga jij maar eens grote complexe rapportages maken mbv Business intelligence tools. Dat gaat niet op ver genormaliseerde databases. Eigenlijk durf ik zelfs te zeggen dat voor Datawarehousing (Business Intelligence) gewone relationele databases totaal niet geschikt zijn! En dan nog ik heb sommige databases gezien waar ze wel een beetje erg ver waren doorgeslagen in hun normalisatie. Om de meest simpele data op te halen had ik al bijna 10 joins nodig.

Daarom maak je ook onderscheid tussen OLTP databases (sterk genormaliseerd) en OLAP databases (sterk gedenormaliseerd en geconcentreerd in stermodellen). De bedoeling is dat je je feitelijke werk doet op de OLTP voor performance en integriteit, en vervolgens bijv. eenmaal per dag of uur data update naar de read-only OLAP waar je je cubes en rapportages tegen bouwt.

Nofi maar met een uitspraak als "Eigenlijk durf ik zelfs te zeggen dat voor Datawarehousing (Business Intelligence) gewone relationele databases totaal niet geschikt zijn" doe je mij in twijfel trekken of jij wel geschikt bent voor je vak

[ Voor 13% gewijzigd door curry684 op 28-01-2008 22:50 ]

[BikkelZ]

Moshe85 schreef op maandag 28 januari 2008 @ 22:06:
[...]


Ik ben het toch wel eens met hylke. Ga jij maar eens grote complexe rapportages maken mbv Business intelligence tools. Dat gaat niet op ver genormaliseerde databases. Eigenlijk durf ik zelfs te zeggen dat voor Datawarehousing (Business Intelligence) gewone relationele databases totaal niet geschikt zijn! En dan nog ik heb sommige databases gezien waar ze wel een beetje erg ver waren doorgeslagen in hun normalisatie. Om de meest simpele data op te halen had ik al bijna 10 joins nodig.

Je gooit alles in SP's en views en daarmee verberg je de complexiteit voor de applicatie. Is het zo dat je continu zeer specifieke queries moet runnen om je data op te halen dan kan het wel wat lastiger zijn. Maar ik zie slecht genormaliseerde databases als views waar ik niet omheen kan werken als het moet. Dus je zou in principe er voor moeten zorgen dat er eenvoudige interfaces bestaan voor jouw BI tools op alle databronnen die gebruikt worden om BI rapportages te maken. En ik denk niet dat als je een hekel hebt aan het JOINen van data dat je dan bij BI helemaal in de goede hoek zit

Ik denk dat de applicaties waarmee gewerkt wordt om die gegevens die er in die databases moeten om gemined te worden juist wel goed genormaliseerd moeten zijn, om de integriteit van de data te waarborgen.

[ Voor 7% gewijzigd door BikkelZ op 28-01-2008 22:52 ]

[Psychokiller]

We hebben hier op het werk eveneens een tabel waarin statussen niet zijn genormaliseerd, hierbij wisselt het aantal statussen per applicatie af tussen de 25 en de 50. In iedere statuskolom wordt een datetime opgeslagen waarmee we bijhouden wanneer een actie is uitgevoerd. (Bijvoorbeeld: Inschrijving bevestigd, brief verstuurd etc)
Voor de betekenis van de status hebben we een tabel met de kolomnr en de betekenis.

De argumenten om het hier niet te normaliseren zijn vooral opslag en gemak met ophalen:
- 1 kolom met een datetime vs. 1 rij met een statusnr, datetime en evt autoincrement. Ik schat dat 90% van de kolommen uiteindelijk gevuld zal zijn, de andere 10% zullen dus altijd NULL zijn.

- De statussen worden in al onze aplicaties weergegeven als kolommen met vaak het aantal maal dat deze is gevuld. Voor de weergave is het stukken eenvoudiger om 1 rij per persoon/inschrijving met alle statussen te krijgen dan bv 5 rijen per persoon/inschrijving omdat je 5 statussen hebt.

Hoewel we wel de discussie gevoerd hebben dat een tabel met 50 dezelfde velden eigenlijk 'niet kan', kan ik me inmiddels best inleven in de argumenten hiervoor.

[Anoniem: 26306]

Psychokiller schreef op maandag 28 januari 2008 @ 23:07:

Hoewel we wel de discussie gevoerd hebben dat een tabel met 50 dezelfde velden eigenlijk 'niet kan', kan ik me inmiddels best inleven in de argumenten hiervoor.

Ik niet. Het is vrijwel altijd met een goede user interface op te lossen dat je ook een iets complexere tabelstructuur handig kunt onderhouden. Dát is namelijk wat er volgens mij meestal aan schort.

[Anoniem: 33810]

BikkelZ schreef op maandag 28 januari 2008 @ 21:42:
[...]


....of omdat je je HBO-I diploma cadeau krijgt voor het op tijd opdagen bij tentamens en het uit je hoofd knallen van de vragen achterin het boek in Nederland.

Sorry hoor, ik weet niet precies wat voor beeld jij hebt van het HBO, of op welke school jij HBO-I hebt gedaan, maar ik ben nu bezig op de Fontys en ben op software engineering en database gebied best tevreden tot nu toe (helft 1e jaar).

[zwippie]

offtopic:
Aangezien een plaatje vaak meer zegt dan woorden:

_normaliseren

[curry684]

Anoniem: 33810 schreef op maandag 28 januari 2008 @ 23:52:
[...]

Sorry hoor, ik weet niet precies wat voor beeld jij hebt van het HBO, of op welke school jij HBO-I hebt gedaan, maar ik ben nu bezig op de Fontys en ben op software engineering en database gebied best tevreden tot nu toe (helft 1e jaar).

Sorry hoor, maar als halverwege-eerstejaars kun jij ook wel op je klompen aanvoelen dat je een minder compleet beeld hebt van hoe die opleiding jou oplevert dan de mensen hier die de opleiding wel al af hebben of collega's hebben die dat hebben gedaan of werving&selectie moeten doen tussen die mensen.

[BikkelZ]

Anoniem: 33810 schreef op maandag 28 januari 2008 @ 23:52:
[...]

Sorry hoor, ik weet niet precies wat voor beeld jij hebt van het HBO, of op welke school jij HBO-I hebt gedaan, maar ik ben nu bezig op de Fontys en ben op software engineering en database gebied best tevreden tot nu toe (helft 1e jaar).

Fontys (Eindhoven)

Maar het ligt niet zo zeer aan het niveau van de boeken of wat er door de (soms behoorlijk goede!) leraren verteld en uitgelegd wordt, maar wat je uiteindelijk hoeft te kunnen en weten om het te halen.

Dit is uiteindelijk ook gewoon de uitholling van het Nederlandse onderwijs door de regering natuurlijk, want die dwingen HBO's anders te gaan denken dan in kwaliteit.

[Voutloos]

Anoniem: 26306 schreef op maandag 28 januari 2008 @ 23:26:
[...]

Ik niet. Het is vrijwel altijd met een goede user interface op te lossen dat je ook een iets complexere tabelstructuur handig kunt onderhouden. Dát is namelijk wat er volgens mij meestal aan schort.

Dat, en omdat het gewoon te makkelijk voor luie peppies is om dergelijke tabellen te designen. Je stelt (als prutser) de tabel voor die je in je applicatie wil zien, en vervolgens ga je naar <jouw>sql-admin en klop je dat 1 op 1 in. Als je vervolgens die kolommen ook nog Eigenschap1 t/m Eigenschap50 noemt krijg je extra bonuspunten.

offtopic:
En zonder er een opleiding topic van te maken: Van genoeg HBO'ers krijg ik de indruk (als in: soms zeggen ze het, vaak trek ik zelf die conclusie) dat ze 'trucjes leren'. Op de universiteit krijg je meer wiskunde/logica eromheen en wordt doorgaans meer over het waarom geouwehoerd, wat in eerste instantie niet echt enerverend is, maar uiteindelijk kan je je tenminste zelfstandig redden in de nieuwe situaties welke niet voorgekauwd zijn. [/uiteraard te generaliserend]

[ Voor 26% gewijzigd door Voutloos op 29-01-2008 08:23 ]

[BikkelZ]

Psychokiller schreef op maandag 28 januari 2008 @ 23:07:
We hebben hier op het werk eveneens een tabel waarin statussen niet zijn genormaliseerd, hierbij wisselt het aantal statussen per applicatie af tussen de 25 en de 50. In iedere statuskolom wordt een datetime opgeslagen waarmee we bijhouden wanneer een actie is uitgevoerd. (Bijvoorbeeld: Inschrijving bevestigd, brief verstuurd etc)
Voor de betekenis van de status hebben we een tabel met de kolomnr en de betekenis.

De argumenten om het hier niet te normaliseren zijn vooral opslag en gemak met ophalen:
- 1 kolom met een datetime vs. 1 rij met een statusnr, datetime en evt autoincrement. Ik schat dat 90% van de kolommen uiteindelijk gevuld zal zijn, de andere 10% zullen dus altijd NULL zijn.

- De statussen worden in al onze aplicaties weergegeven als kolommen met vaak het aantal maal dat deze is gevuld. Voor de weergave is het stukken eenvoudiger om 1 rij per persoon/inschrijving met alle statussen te krijgen dan bv 5 rijen per persoon/inschrijving omdat je 5 statussen hebt.

Hoewel we wel de discussie gevoerd hebben dat een tabel met 50 dezelfde velden eigenlijk 'niet kan', kan ik me inmiddels best inleven in de argumenten hiervoor.

Nou vind ik de oplossing als je het al zo beredeneerd hebt boven prutz0r, maar ik zou eigenlijk gelijk voorstellen dat je een koppeltabel handhaaft met persoon_id, status_id en tijd, en dat je in je query bijvoorbeeld een JOIN doet van Persoon (die je sorteert op naam of id) naar Status (gewoon alles op alles!) en daar van uit LEFT JOIN doet vanuit de tabel met statussen (die je ook vast sorteert) naar de koppeltabel. Zo heb je gelijk alle rijen die je ooit terug zou kunnen krijgen qua status.

[frickY]

cocoskoek schreef op maandag 28 januari 2008 @ 22:01:
Ik prefix ook nooit, ik begrijp je punt wel. Maar prefixen met underscores of hoofdletters zal het allicht iets leesbaarder kunnen maken.

Ik prefix in camelCase.
In de tabel `producten`` zijn velden geprefixed met `product`.
Tabelnamen zijn altijd in meervouw, prefixen in enkelfout.
Bij lange tabelnamen, zoals `productcategorieen` kort ik de prefi af; `prodcat`. Het moet wel handig blijven natuurlijk.

Het enige waar ik over struikel is benaming van foreignkeys.
In mijn producten tabel heb ik bijvoorbeeld gewoon een `prodcatID`, de PK van de categorietabel. Maar bijvoorbeeld bij het koppelen van beeld, welke altijd uit een files tabel komt, zou ik 2x een `fileID` kolom hebben. En dan maak ik er al snel `fileID2` of `product_foto2` van,waar ik beide niet gelukkig mee ben

[Janoz]

Prefixen doe ik nooit. Ik vind het eigenlijk onzin. Als ik in tabel product de velden id en categoryid heb dan kan ik die in een gejoinde query immers ook wel keurig benaderen via product.id en product.categoryid. Dan vind ik de punt netter dan de underscore.

[BikkelZ]

Het nadeel is dat item.id en itemcategory.id allebei als id terug komen of de een de ander overschrijft in veel programmeertalen die databases gebruiken. Dus dan kun je niet zeggen SELECT * FROM terwijl je eigenlijk wel alles zou willen hebben uit beide tabellen.

Overigens prefix ik zelf NIET, maar ik twijfel er wel over.

[whoami]

The Eagle schreef op maandag 28 januari 2008 @ 22:08:
Stom toeval wil dat ik de laatste paar weken nogal aan het smartcoden ben
Oftewel: we hebben een lijst met translate waarden, en op basis van een bepaalde criteria moet met die translatewaarden een dowpdownlist gevuld worden. Dat krijg je als je 3 systemen moet concolideren in 1 systeem en de 3 eigenaren willen wel graag hun eigen codes enzo houden

Ik heb ook zoiets.
Hiervoor is een generiek systeem opgesteld die die codes eenvoudig kan ophalen, waar 'translation' mogelijk is tussen verschillende codes, en waarbij we ook comboboxen simpel kunnen vullen met gelijk welk type code.
't Heeft wat moeite gekost, maar het zit dan ook wel goed in elkaar nu. (Recent nog wat aan gerefactored )

[Janoz]

BikkelZ schreef op dinsdag 29 januari 2008 @ 09:39:
Het nadeel is dat item.id en itemcategory.id allebei als id terug komen of de een de ander overschrijft in veel programmeertalen die databases gebruiken. Dus dan kun je niet zeggen SELECT * FROM terwijl je eigenlijk wel alles zou willen hebben uit beide tabellen.

Overigens prefix ik zelf NIET, maar ik twijfel er wel over.

Nou, dat ze overschreven worden ben ik eigenlijk nog niet tegen gekomen. Daarnaast zou je in je code ook nooit select * moeten gebruiken. Dat is een shortcut voor wanneer je met het handje in de sql commandline tool zit. In je code moet je ALTIJD gewoon je velden benoemen.

Bij het benoemen van de velden definieer je de volgorde wat het bij het uitlezen erg makkelijk maakt, daarnaast houd niks je tegen om in het geval van ambiguïteit alsnog een alias voor een kolom te gebruiken.

[BikkelZ]

Janoz schreef op dinsdag 29 januari 2008 @ 10:16:
[...]

Nou, dat ze overschreven worden ben ik eigenlijk nog niet tegen gekomen. Daarnaast zou je in je code ook nooit select * moeten gebruiken. Dat is een shortcut voor wanneer je met het handje in de sql commandline tool zit. In je code moet je ALTIJD gewoon je velden benoemen.

Bij het benoemen van de velden definieer je de volgorde wat het bij het uitlezen erg makkelijk maakt, daarnaast houd niks je tegen om in het geval van ambiguïteit alsnog een alias voor een kolom te gebruiken.

Als je je hoofdtabel JOINt naar een steuntabel, dan wordt in bijvoorbeeld PHP de id van de hoofdtabel overschreven door die van de steuntabel, als je * gebruikt. Je kunt inderdaad ook alle velden intikken terwijl je eigenlijk * bedoelt, maar dat is ietsjes nadelig voor de performance meen ik.

[EfBe]

frickY schreef op dinsdag 29 januari 2008 @ 08:48:
[...]

Ik prefix in camelCase.
In de tabel `producten`` zijn velden geprefixed met `product`.
Tabelnamen zijn altijd in meervouw, prefixen in enkelfout.
Bij lange tabelnamen, zoals `productcategorieen` kort ik de prefi af; `prodcat`. Het moet wel handig blijven natuurlijk.

Nooit doen. Jij denkt dat je handig bezig bent maar het is niet handig. Ten eerste gebruik je namen die JIJ handig vindt, maar die voor een ander wellicht raar over komen. Ten tweede is het steevast inconsequent, en gaat het dus op een zootje lijken na een tijdje en ten derde is het overbodig, omdat het allerlei text toevoegt die semantisch niets toevoegt. Tenzij je met een hobbyprogramma bezig bent zou ik echt kappen met dit soort dingen. Ik krijg bv kromme tenen bij het zien van 'prodcat'. Tenzij je op DB2 zit uit 1979 kan iedere database redelijk lange namen aan, dus is productcategorie de enige juiste naam die je moet geven. Ja dat is even wat meer typewerk, maar het zegt wel wat er in zit, 'prodcat' zegt nl. niets. Het kan ook productiecategory betekenen.

Als je een model zou opstellen in NIAM/ORM bv dan kom je erachter dat wat jij doet eigenlijk onzin is. Ten eerste zijn entities niet meervoud, je hebt Product, en geen Producten. Ten tweede heeft Product een attribute 'Naam' en niet 'ProductNaam', het is nl. de naam van product, niet de naam van klant.

Dus: tabelnamen: enkelvoud en niet afkorten.
veldnamen: NIET prefixen. Het veld Naam in Product is de naam van .... juist, het product. Anders krijg ik Product.ProductNaam, beetje overbodig.

Het enige waar ik over struikel is benaming van foreignkeys.
In mijn producten tabel heb ik bijvoorbeeld gewoon een `prodcatID`, de PK van de categorietabel. Maar bijvoorbeeld bij het koppelen van beeld, welke altijd uit een files tabel komt, zou ik 2x een `fileID` kolom hebben. En dan maak ik er al snel `fileID2` of `product_foto2` van,waar ik beide niet gelukkig mee ben

Waarom ben je zo bang dat je wat characters teveel moet tikken in sommige gevallen? (Terwijl je juist in andere gevallen overbodige text erbij tikt!). In je product tabel heb je een productcategorieID, prima, want dat veld stelt dat ook voor. Als je 2x een column nodig hebt voor hetzelfde is dat dus een fout in je model: je hebt dan een 1:n relatie en moet een nieuwe tabel aanmaken.

Nog even over prefixes van namen. Men is zo bang dat dat dan clashes oplevert bij projections. Tja. Je kunt velden in projections gewoon aliasen, maar veelal heb je die velden met dubbele namen niet allebei nodig want ze zijn bv hetzelfde. Ja de aliases zijn even wat extra typewerk, maar is dat erg? Wat heb je liever: dat iemand jouw code leest en er een uur over doet met giswerk wat het voorstelt, dan de foute conclusie trekt en foute code toevoegt, of jouw code leest en accuut snapt wat er bedoeld wordt?

Over de discussie van denormalisatie: men verwart vaak het fenomeen denormalisatie met een juiste vorm van normalisatie en dat die goed genoeg is en men maakt dan direct de stap om die 'normalisatievorm' direct in te voeren: waarom moeilijk doen als je daar toch eindigt, toch? De grootste fout die je kunt maken.

Les 1 van relationele datamodellen is dat je geen compromissen kunt sluiten mbt je model: je hebt OF een juist model of niet. Dat is je basis. Als na implementatie van dat model blijkt dat er hotspots zijn in het gebruik van het model en door bepaalde (!) tabellen te denormaliseren in een bepaalde vorm de performance kan worden verbeterd, dan kan op dat moment besloten worden om die maatregelen te nemen, maar dat is wat anders dan direct maar op de prutsmethode wat tabellen te gaan samenvoegen. Wanneer je delen van je juiste model gaat denormaliseren kun je bv besluiten om indexed views toe te voegen voor de hotspots, zodat je model in tact blijft. Of de data in gedenormaliseerde vorm op een aparte server te plaatsen omdat de hotspots in bepaalde reports zitten die je 1 keer per week draait.

Als je uitgaat van een juist model, dan kun je documenteren welke delen je hebt gedenormaliseerd en waarom. Waarom is dat belangrijk? Nou, om de domme reden dat wanneer je iets gaat wijzigen aan je model je dat alleen kunt doen in het correcte model, niet in je gedenormaliseerde model! De wijzigingen kunnen nl. een ander model opleveren met ANDERE hotspots en dus dat je ANDERE delen moet denormaliseren.

Echter, deze discussie is net zo oud als de zeikdiscussie over stored procs vs. dyn. sql: een gebed zonder eind.

BikkelZ schreef op dinsdag 29 januari 2008 @ 10:37:
[...]
Als je je hoofdtabel JOINt naar een steuntabel, dan wordt in bijvoorbeeld PHP de id van de hoofdtabel overschreven door die van de steuntabel, als je * gebruikt. Je kunt inderdaad ook alle velden intikken terwijl je eigenlijk * bedoelt, maar dat is ietsjes nadelig voor de performance meen ik.

Dat is dan een bottleneck in PHP, want '*' projections zijn veelal (iewat) trager dan uitgeschreven projections. Net zoals uitgeschreven tabel references MET catalog, schema, user sneller zijn dan alleen tabelnaam. Neemt niet weg dat correctheid bovenalles gaat. IEDEREEN die hoekjes afsnijdt krijgt het vroeg of laat weer als een boomerang op hem terug: hetzij dat je het later zelf moet beheren en jezelf dan vervloekt, hetzij dat je de zak krijgt wegens afleveren van prutswerk, hetzij dat het niet in dank wordt afgenomen door je collegas die jouw code moeten beheren. Wees een professional, gehobby doet men niet op het werk.

[ Voor 10% gewijzigd door EfBe op 29-01-2008 10:41 ]

[PromWarMachine]

Stel dat je een voorraad hebt per magazijnlocatie. Op meerdere locaties kunnen dus hetzelfde artikel liggen (meerdere pallets). Bij het invoeren van een order wil je weten wat je totale voorraad is. Wij hebben er voor gekozen om die totale voorraad in de artikeltabel op te nemen.

Netter is om het gewoon telkens uit te rekenen, maar omdat we die vooraad op zoveel verschillende plekken nodig hebben, hebben we hier niet voor gekozen.

_{Overigens hebben we het hier niet over een SQL-database (want dan zou je er een view van kunnen maken met dat enum-veld), maar over een Providex-database. Niemand kent die taal, maar het gaat om het normalisatie-voorbeeld.}

[Voutloos]

BikkelZ schreef op dinsdag 29 januari 2008 @ 10:37:
Je kunt inderdaad ook alle velden intikken terwijl je eigenlijk * bedoelt, maar dat is ietsjes nadelig voor de performance meen ik.

En dat is dus niet waar of zeker niet significant. Echter kan het wel weer goed voor de performance zijn om expliciet te zijn, namelijk in het geval dat er later veel kolommen aan die tabel toegevoegd worden en de * query alsnog onnodige kolommen zou gaan ophalen.

[Meekoh]

curry684 schreef op maandag 28 januari 2008 @ 22:49:
[...]

Daarom maak je ook onderscheid tussen OLTP databases (sterk genormaliseerd) en OLAP databases (sterk gedenormaliseerd en geconcentreerd in stermodellen). De bedoeling is dat je je feitelijke werk doet op de OLTP voor performance en integriteit, en vervolgens bijv. eenmaal per dag of uur data update naar de read-only OLAP waar je je cubes en rapportages tegen bouwt.

Nofi maar met een uitspraak als "Eigenlijk durf ik zelfs te zeggen dat voor Datawarehousing (Business Intelligence) gewone relationele databases totaal niet geschikt zijn" doe je mij in twijfel trekken of jij wel geschikt bent voor je vak

Daar wil ik best even op ingaan. Het ging alleen om het voorbeeld dat normaliseren niet altijd een must is en dat het in bijv. BI niet gewenst is.
Daarnaast weet ik echt wel waar ik over praat en zit ik al een tijdje in dit vak. Het punt bij datawarehouses is dat je alles in een beperkte aantal tabellen hebt zitten die (het liefst tbv performance) minder dan 1 join van elkaar zitten. De voordelen die een relationele (transactie gerichte) database biedt gebruik je bijna nooit in Datawarehousing. De traditionele Relationele Database met bijbehorend DBMS is heel transactie gericht. Echter bij BI gebruik je dit niet en is het alleen maar een performance vreter.

Je hebt het over OLAP echter dit is een soort verzamelwoordje voor verschillende vormen van Online Analytical Processing, maar meestal bedoelt men er MOLAP mee
Zo heb je bijvoorbeeld:
- MOLAP (Multidimensionale Database)
- ROLAP (Relationele Database)

Met andere woorden wat ik probeerde duidelijk te maken met mijn verhaal was dat ROLAP in veel gevallen niet gewenst is en eigenlijk ook niet geschikt is voor datawarehousing (je krijgt Grote performance hits wanneer je DB groeit).

Als je meer over het verschil wil weten dan zeg je het maar

Edit:
Maargoed dit topic ging niet over datawarehousing, maar over normalisatie. Back on topic

[curry684]

BikkelZ schreef op dinsdag 29 januari 2008 @ 09:39:
Het nadeel is dat item.id en itemcategory.id allebei als id terug komen of de een de ander overschrijft in veel programmeertalen die databases gebruiken. Dus dan kun je niet zeggen SELECT * FROM terwijl je eigenlijk wel alles zou willen hebben uit beide tabellen.

Daarom:
• Moet je nooit * selecten, en
• Kun je aliassen gebruiken als er anderszins conflicten zouden neigen.

SQL:

SELECT i.id AS ItemId, p.id AS ProductId
FROM Item i
JOIN Product p ON p.itemId = i.id

* curry684 prefixt nooit maar named wel verbose. En een PK is bij mij wel <table>Id voor de volledigheid, ik word gek van databasemodellen waarin iets dat in iedere tabel uniek is de minst unieke benaming heeft.

@Moshe hierboven: wees gerust, je hoeft mij weinig uit te leggen hoor Je originele uitspraken misten stomweg de plank nogal, dank voor de correctie

[ Voor 15% gewijzigd door curry684 op 29-01-2008 11:04 ]

[BikkelZ]

Voutloos schreef op dinsdag 29 januari 2008 @ 10:43:
[...]
En dat is dus niet waar of zeker niet significant. Echter kan het wel weer goed voor de performance zijn om expliciet te zijn, namelijk in het geval dat er later veel kolommen aan die tabel toegevoegd worden en de * query alsnog onnodige kolommen zou gaan ophalen.

Mjeuoah true true. Maar goed, aangezien ik niet met prefixes werk ontkom ik in de praktijk dus ook niet aan het ontwijken van het gebruik van *

[Voutloos]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:03:
[...]
Mjeuoah true true. Maar goed, aangezien ik niet met prefixes werk ontkom ik in de praktijk dus ook niet aan het ontwijken van het gebruik van *

Dat is dan wel het goed argument tegen prefixes dus.

[Janoz]

BikkelZ schreef op dinsdag 29 januari 2008 @ 10:37:
[...]


Als je je hoofdtabel JOINt naar een steuntabel, dan wordt in bijvoorbeeld PHP de id van de hoofdtabel overschreven door die van de steuntabel, als je * gebruikt. Je kunt inderdaad ook alle velden intikken terwijl je eigenlijk * bedoelt, maar dat is ietsjes nadelig voor de performance meen ik.

tja php. Het wordt trouwens niet overschreven. Wanneer je je velden benadert middels de index krijg je gewoon alles eruit. Ikzelf gebruik trouwens sowieso fetch_row.

Het is trouwens eerder * dat nadelig is voor de performance. Niet dat dat überhaupt uit maakt. Als het al verschilt dan is dat zo marginaal. Dat weegt niet op tegen de slecht leesbare code die je met die sterren aan het schrijven bent. Verder kun je met het benoemen van de velden precies aangeven wat je wel en niet nodig hebt. In jou geval bij je bij een join sowieso de gekoppelde id dubbel aan het ophalen.

[BikkelZ]

Janoz schreef op dinsdag 29 januari 2008 @ 11:05:
[...]
tja php. Het wordt trouwens niet overschreven. Wanneer je je velden benadert middels de index krijg je gewoon alles eruit. Ikzelf gebruik trouwens sowieso fetch_row.

Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

Voutloos schreef op dinsdag 29 januari 2008 @ 11:04:
[...]
Dat is dan wel het goed argument tegen prefixes dus.

Gnehehehe

[ Voor 19% gewijzigd door BikkelZ op 29-01-2008 11:13 ]

[Janoz]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:12:
[...]


Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

Nee, ik loop niet te kutten met cijfertjes. Ja, ik fetch met cijfertjes, maar op de regels erboven staat precies een opsomming van de velden incl hun volgorde die vervolgens vlak daar onder middels de setters in het value object worden gezet.

[curry684]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:12:
[...]


Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

Waarom niet? De query schrijft al voor in welke volgorde je je velden select, dan maakt het in theorie weinig uit of je vervolgens by name of index eraan refereert. De code moet je toch meeveranderen als je de query wijzigt, dus waarom daar geen strakke relatie tussen leggen?

Ik prefereer zelf ook named retrieval via fetch_object, maar dat wil niet zeggen dat het by index minder goed is of zo.

[EfBe]

BikkelZ schreef op dinsdag 29 januari 2008 @ 11:12:
[...]


Errr.......eerst netjes al je veldnamen in gaan kloppen in je SQL en vervolgens gaan loppen kutten met nummertjes in je code?

list of field names -> projection list of query
en direct ook list of ordinals (middels index) voor field retrieval. Dan 1 row per keer ophalen in array, en middels field - index pairs individuele values ophalen uit array en stoppen in field met naam uit pair. Klaar. Als je maar begint met de lijst met velden voor de fetch, daarna kun je die meteen gebruiken voor value indexing in je row data. Dat is sneller, want je db api hoeft niet telkens naam-> ordinal op te zoeken

[curry684]

EfBe schreef op dinsdag 29 januari 2008 @ 11:25:
[...]

Dat is sneller, want je db api hoeft niet telkens naam-> ordinal op te zoeken

In de praktijk natuurlijk een non-optimalisatie, de gemiddelde computer heeft niet zoveel moeite met string lookups voor een stuk of 10 fields dat het feitelijk enigszins boeit.

[BikkelZ]

Janoz schreef op dinsdag 29 januari 2008 @ 11:16:
[...]

Nee, ik loop niet te kutten met cijfertjes. Ja, ik fetch met cijfertjes, maar op de regels erboven staat precies een opsomming van de velden incl hun volgorde die vervolgens vlak daar onder middels de setters in het value object worden gezet.

Nou ja ik gebruik heel vaak SP's en ik zie gewoon liever direct wat een variabele inhoudt. Dus zelfs als het dan in comments er boven staat geef ik nog de voorkeur aan named.

Maar we dwalen af.....

[Janoz]

Het staat niet in de comments erboven, maar in de query erboven.

[daniëlpunt]

BikkelZ schreef op dinsdag 29 januari 2008 @ 09:39:
Het nadeel is dat item.id en itemcategory.id allebei als id terug komen of de een de ander overschrijft in veel programmeertalen die databases gebruiken. Dus dan kun je niet zeggen SELECT * FROM terwijl je eigenlijk wel alles zou willen hebben uit beide tabellen.

Overigens prefix ik zelf NIET, maar ik twijfel er wel over.

Dit kan toch ook?
SELECT a.*, b.* FROM a, b

[BikkelZ]

super-muffin schreef op dinsdag 29 januari 2008 @ 17:39:
[...]

Dit kan toch ook?
SELECT a.*, b.* FROM a, b

Ja, waarbij in een fetch_assoc a.id overschreven wordt door b.id, terwijl het id van a belangrijk is en niet die van b, want die heb je al in a.b_id.

[curry684]

BikkelZ schreef op dinsdag 29 januari 2008 @ 18:53:
[...]


Ja, waarbij in een fetch_assoc a.id overschreven wordt door b.id, terwijl het id van a belangrijk is en niet die van b, want die heb je al in a.b_id.

Slechts een van de paar honderd redenen waarom ik de schurft heb aan 'id' als wederkerende naam voor PK in iedere tabel van een schema

[EfBe]

curry684 schreef op dinsdag 29 januari 2008 @ 22:22:
[...]

Slechts een van de paar honderd redenen waarom ik de schurft heb aan 'id' als wederkerende naam voor PK in iedere tabel van een schema

Waarom? 'Name' zal ook overal voorkomen, dus je moet dan gaan prefixen met de naam van de tabel, wat ook weer problemen of rariteiten veroorzaakt.

Alleen omdat je meerdere keren 'id' in de projection kunt hebben is het raar? Als je SELECT a.*, b.* FROM ... doet en daar zit 2 keer 'id' tussen en PHP levert dezelfde waarde wanneer je met de string "id" de waarde uit de resultset probeert te halen, ja DUH dat het dan fout gaat... Je moet dan gewoon aliasen, maar dat is met elke dubbele naam zo, niet alleen met 'id'.

[Anoniem: 84120]

BikkelZ schreef op maandag 28 januari 2008 @ 15:39:
...
Ik wil aan de ene kant de achterliggende reden weten waarom duurbetaalde en getrainde professionals tóch voor die - in mijn ogen - inferieure oplossing kiezen, en aan de andere kant kan dit topic misschien ook nog wel als een soort van coming out topic werken
...

Ik heb wel ooit een gedrocht afgeleverd (Toen: Informatica/Universiteit, einde eerste jaar, en ja toen had ik databasnormalisatie en dergelijke al ooit gehad). Toen moest ik een soort van administratiesysteem maken die producten en klanten kon opslaan en die 'uitbreidbaar' is (als in: er zijn data-elementen aan toe te voegen, zoals nieuwe producten, nieuwe producteigenschappen per product), en deze uitbreidbaarheid ZONDER enige vorm van werk (in database, of in code of waar dan ook, gewoon via een pas-de-datastructuur voor dit product-aan-wizard).

Redenen waarom het een niet-genormaliseerd gedrocht was:
- Tijdgebrek
- Voor de verkregen tijd vrij irritante eisen
- Midden in het project toevoegen van nieuwe eisen (zoals: het verwijderen van complete producten en producteigenschappen).
- Ik zou worden bijgestaan door een afgestudeerde professional die mijn ideeen zou bijsturen waar nodig, maar deze vond alles goed en heeft nooit moeite genomen om 'bij te sturen'. Mede omdat de code (PHP) die ik had altijd heel netjes was (Ja ik programmeer wel altijd heel overzichtelijk en net).
- Fixatie op user interface: Ze wouden qua planning vooral snel milestones qua GUI zien, en die direct compleet werkend. Verder gingen ze er van uit dat als ik een werkende GUI had (voor demonstratie) dat ik die dan ook direct compleet werkend kon hebben met achterliggende systemen (dus server-side opslag en zo).

En ik vond het toen al een gedrocht/mislukt ding.

En dat was weer voldoende coming out voor vandaag

[ Voor 11% gewijzigd door Anoniem: 84120 op 30-01-2008 10:58 ]

[BikkelZ]

Je wordt pas geacht rond het vierde leerjaar minder van dit soort leermomenten te hebben.

Maar lucht het op, nu je er eindelijk voor uit bent gekomen?

[EfBe]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:15:
Je wordt pas geacht rond het vierde leerjaar minder van dit soort leermomenten te hebben.

Maar lucht het op, nu je er eindelijk voor uit bent gekomen?

Even alle gekheid op een stokje, jij gaat hier beweren dat het uitnormaliseren van constante waardes een must is? Zodoende kun je ieder attribute wel een aparte tabel gaan geven, maar dat is niet het punt: een m:1 / 1:1 relatie tussen entity E1 en entity E2, waarbij E2 alleen zn identifying attribute A heeft zou je kunnen transformeren naar een situatie waarbij A een attribute van E1 wordt. Dit kan, omdat het lood om oud ijzer is: een FK in E1 voor het identificeren van welk E2 instance bij de E1 instance hoort is gelijk aan het hebben in E1 van het enige attribute van E2 dat er toe doet. Let wel, dit kan omdat A het identifying attribute is van E2 en dus constant.

[Anoniem: 84120]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:15:
Je wordt pas geacht rond het vierde leerjaar minder van dit soort leermomenten te hebben.

Maar lucht het op, nu je er eindelijk voor uit bent gekomen?

Ik hoef me niet op te lucten hoor, ik schaam me er ook niet voor. En verder: Heb daarvoor zat dingen gemaakt die gewoon netjes waren ontworpen en uitgewerkt. Maar goed, voor jezelf werken is toch altijd anders dan werken als loonslaaf. Voor jezelf kan je gerust een maand gaan hypotheseren over minime details.

[BikkelZ]

EfBe schreef op woensdag 30 januari 2008 @ 11:39:
[...]

Even alle gekheid op een stokje, jij gaat hier beweren dat het uitnormaliseren van constante waardes een must is? Zodoende kun je ieder attribute wel een aparte tabel gaan geven, maar dat is niet het punt: een m:1 / 1:1 relatie tussen entity E1 en entity E2, waarbij E2 alleen zn identifying attribute A heeft zou je kunnen transformeren naar een situatie waarbij A een attribute van E1 wordt. Dit kan, omdat het lood om oud ijzer is: een FK in E1 voor het identificeren van welk E2 instance bij de E1 instance hoort is gelijk aan het hebben in E1 van het enige attribute van E2 dat er toe doet. Let wel, dit kan omdat A het identifying attribute is van E2 en dus constant.

Maar waar leg je dan de verantwoordelijkheid welke waarde er aan A toegekend wordt? Met een constraint tussen E1.A en E2.A zorg je er voor dat er nooit een waarde van A bestaat dan jij hebt gedefinieerd in E2. Als dat pertinent zeker nooit een zorg zal zijn, omdat een nog niet bestaande waarde van A in E1 niet erg is omdat die dan gewoon toegevoegd mag worden, hoef je die constraint ook niet te leggen.

Om het voorbeeld aan te halen: er mogen geen andere statussen bestaan dan de statussen die we van te voren bepaald hebben. Niemand mag ter plekke bedenken dat er ook nog een status 'doe ik na mijn vakantie' mag komen.

[BikkelZ]

Anoniem: 84120 schreef op woensdag 30 januari 2008 @ 11:45:
[...]


Ik hoef me niet op te lucten hoor, ik schaam me er ook niet voor. En verder: Heb daarvoor zat dingen gemaakt die gewoon netjes waren ontworpen en uitgewerkt. Maar goed, voor jezelf werken is toch altijd anders dan werken als loonslaaf. Voor jezelf kan je gerust een maand gaan hypotheseren over minime details.

Ik ga nooit echt nadenken over minimale details, ik normaliseer alles gewoon zonder dat ik ga nadenken over waar ik de kantjes er misschien af kan lopen.

[Voutloos]

Anoniem: 84120 schreef op woensdag 30 januari 2008 @ 11:45:
Voor jezelf kan je gerust een maand gaan hypotheseren over minime details.

Als je dat regelmatig doet, heb je of weinig kosten, of vind je het eten van leger des heils lekker.

[EfBe]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:50:
[...]


Maar waar leg je dan de verantwoordelijkheid welke waarde er aan A toegekend wordt? Met een constraint tussen E1.A en E2.A zorg je er voor dat er nooit een waarde van A bestaat dan jij hebt gedefinieerd in E2. Als dat pertinent zeker nooit een zorg zal zijn, omdat een nog niet bestaande waarde van A in E1 niet erg is omdat die dan gewoon toegevoegd mag worden, hoef je die constraint ook niet te leggen.

Om het voorbeeld aan te halen: er mogen geen andere statussen bestaan dan de statussen die we van te voren bepaald hebben. Niemand mag ter plekke bedenken dat er ook nog een status 'doe ik na mijn vakantie' mag komen.

Op zich een logisch punt, maar een model an sich definieert dat niet. Immers: niets houdt mij tegen om nieuwe E2 instances toe te voegen en zo het arsenaal values voor A uit te breiden. Dus of A nu in E1 of E2 zit, dat doet per saldo niet ter zake. Dat neemt niet weg dat je punt correct is, er moet ergens verantwoordelijkheid liggen welke values voor A legitiem zijn, maar dat ligt buiten het model.

[BikkelZ]

EfBe schreef op woensdag 30 januari 2008 @ 12:55:
[...]

Op zich een logisch punt, maar een model an sich definieert dat niet. Immers: niets houdt mij tegen om nieuwe E2 instances toe te voegen en zo het arsenaal values voor A uit te breiden. Dus of A nu in E1 of E2 zit, dat doet per saldo niet ter zake. Dat neemt niet weg dat je punt correct is, er moet ergens verantwoordelijkheid liggen welke values voor A legitiem zijn, maar dat ligt buiten het model.

Klopt, maar het updaten van E2 zou dan natuurlijk niet mogelijk zijn vanuit de stored procedure die het voor de applicatie regelt. Kijk ik denk wel vanuit het principe dat de database zo veel mogelijk zichzelf moet bedruipen, en niet dat de bovenliggende code alles hopelijk een beetje clean houdt. Mensen mogen daar een andere mening over hebben zonder dat ik meteen zeg dat ze het fout doen, zolang er maar een solide gedachtengang achter ligt die uiteindelijk resulteert in kwaliteit (waar ik onderhoudbaarheid ook onder versta).

[ZanomiX]

Sommige mensen normaliseren niet om de kosten gewoonweg te drukken. Als jij een aplicatie moet schrijven voor enkele mensen en je weet van tevoren dat er maximaal 5 records worden ingegeven is het dom om alles tot in de puntjes uit te werken..

[Orphix]

Mijn ervaring is dat bij zeer stabiele waardes, zoals statuscodes, dat het handiger is dit te denormaliseren. Het voordeel is dat alle externe partijen direct naar de status kunnen referen, ipv eerst een lookup doen om vervolgens een numerieke ID mee te geven. Met externe partijen doel ik dan op bv website front-ends (drop-down listjes), webservices, import/export vanuit meerdere databases.

Een statuscode is namelijk globaal uniek voor jouw applicatie, waar een interne ID dat niet is. Het continu vertalen hiertussen neemt complexiteit met zich mee.

[EfBe]

BikkelZ schreef op woensdag 30 januari 2008 @ 13:11:
[...]
Klopt, maar het updaten van E2 zou dan natuurlijk niet mogelijk zijn vanuit de stored procedure die het voor de applicatie regelt.

Wat heeft die stored proc ermee te maken? Ik log in via een query tool en update de table. Geen hond die er naar kraait, zeker jouw proc niet.

Kijk ik denk wel vanuit het principe dat de database zo veel mogelijk zichzelf moet bedruipen, en niet dat de bovenliggende code alles hopelijk een beetje clean houdt. Mensen mogen daar een andere mening over hebben zonder dat ik meteen zeg dat ze het fout doen, zolang er maar een solide gedachtengang achter ligt die uiteindelijk resulteert in kwaliteit (waar ik onderhoudbaarheid ook onder versta).

Het punt is dat het model correct moet zijn. HOE het gebruikt wordt, met procs, met vba-string based crap, met php, met een fancy o/r mapper, het boeit niet. Zoals aangegeven: als je de verantwoordelijkheid ergens neerlegt, dus of in een stored proc die ik omzeil, of in een validator in de entity mapped op E2 die je omzeilt met de query tool, het boeit niet, zolang er maar een validator op ligt.

De enige remedie die helpt is de table readonly te maken.

[Anoniem: 84120]

BikkelZ schreef op woensdag 30 januari 2008 @ 11:51:
[...]
Ik ga nooit echt nadenken over minimale details, ik normaliseer alles gewoon zonder dat ik ga nadenken over waar ik de kantjes er misschien af kan lopen.

Ja minimale details is niet alleen database model, maar in het algemeen als ik 'iets' aan het bouwen ben voor mezelf.

Voutloos schreef op woensdag 30 januari 2008 @ 11:51:
[...]
Als je dat regelmatig doet, heb je of weinig kosten, of vind je het eten van leger des heils lekker.

Er is een verschil tussen projectjes die ik voor mezelf doe, en dingen die ik als werk doe .

[BikkelZ]

EfBe schreef op woensdag 30 januari 2008 @ 14:22:
[...]

Wat heeft die stored proc ermee te maken? Ik log in via een query tool en update de table. Geen hond die er naar kraait, zeker jouw proc niet.

Het punt is dat het model correct moet zijn. HOE het gebruikt wordt, met procs, met vba-string based crap, met php, met een fancy o/r mapper, het boeit niet. Zoals aangegeven: als je de verantwoordelijkheid ergens neerlegt, dus of in een stored proc die ik omzeil, of in een validator in de entity mapped op E2 die je omzeilt met de query tool, het boeit niet, zolang er maar een validator op ligt.

De enige remedie die helpt is de table readonly te maken.

Inderdaad, dus je geeft je VBA / PHP / PrutsCode 2.23 appje geen root rechten op de database maar alleen indirecte via bijvoorbeeld views en stored procedures. Er is natuurlijk helemaal NIETS wat bestand is tegen de combinatie prutser en root rechten!

Normaliter wil ik al mijn data zowel al correct hebben op applicatieniveau als op databaseniveau, gewoon double safe. Anders krijg je sowieso steeds database errors.

[ Voor 7% gewijzigd door BikkelZ op 31-01-2008 09:32 ]

[Kwistnix]

Ik normaliseer zelf eigenlijk zelden tot nooit meer, omdat ik bijna uitsluitend met ORM oplossingen werk (in mijn geval Hibernate). Hierbij heb je absolute controle over wat er in de database terecht komt, maar fijnmazige controle over hoe het object model naar een relationeel model wordt omgezet heb je minder.
Eigenlijk wil ik helemaal niets van de database / het relationele model afweten, of in ieder geval ik wil er geen omkijken naar hebben.

[BikkelZ]

FallenAngel666 schreef op donderdag 31 januari 2008 @ 10:06:
Ik normaliseer zelf eigenlijk zelden tot nooit meer, omdat ik bijna uitsluitend met ORM oplossingen werk (in mijn geval Hibernate). Hierbij heb je absolute controle over wat er in de database terecht komt, maar fijnmazige controle over hoe het object model naar een relationeel model wordt omgezet heb je minder.
Eigenlijk wil ik helemaal niets van de database / het relationele model afweten, of in ieder geval ik wil er geen omkijken naar hebben.

ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

[Kwistnix]

BikkelZ schreef op donderdag 31 januari 2008 @ 10:25:
[...]


ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

Met Hibernate is dat niet echt een probleem, want je kan in de mapping meta-data expliciet aangeven dat een bepaalde associatie via een join table gemapped moet worden.
Het is wel zo dat je voornamelijk entiteit tabellen krijgt die min of meer 1:1 mappen op de objecten uit het OO model, maar op zich vind ik dat niet echt een nadeel.

[ Voor 11% gewijzigd door Kwistnix op 31-01-2008 10:51 ]

[EfBe]

BikkelZ schreef op donderdag 31 januari 2008 @ 09:30:
[...]
Inderdaad, dus je geeft je VBA / PHP / PrutsCode 2.23 appje geen root rechten op de database maar alleen indirecte via bijvoorbeeld views en stored procedures. Er is natuurlijk helemaal NIETS wat bestand is tegen de combinatie prutser en root rechten!

Dus, jij maakt een proc aan pr_DeleteCustomer, en ik run een app die die proc gebruikt. Ik log in middels een query tool op de DB en aangezien ik pr_DeleteCustomer kan aanroepen, kan ik iedere customer eruit flikkeren die ik wil. Dus procs geven niet MEER security. Je kunt wat jij wilt ook bereiken met roles en rechten per role per table.

Normaliter wil ik al mijn data zowel al correct hebben op applicatieniveau als op databaseniveau, gewoon double safe. Anders krijg je sowieso steeds database errors.

Lijkt me lastig, want er is altijd een tijdstip T te vinden waarbij jouw data inconsistent is in memory.

BikkelZ schreef op donderdag 31 januari 2008 @ 10:25:
[...]
ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

Wat is een 'bijna' 1:1 structuur ? Volgens mij snap jij overigens niet veel van de werken van sets van entities. Ik HOEF helemaal niet de lookup entities op te halen wanneer ik de fk side ophaal, immers dat is puur voor de UI, dat ik lookup tables nodig heb. Die haal je apart op.

[ Voor 25% gewijzigd door EfBe op 31-01-2008 13:23 ]

[BikkelZ]

EfBe schreef op donderdag 31 januari 2008 @ 13:21:
[...]

Dus, jij maakt een proc aan pr_DeleteCustomer, en ik run een app die die proc gebruikt. Ik log in middels een query tool op de DB en aangezien ik pr_DeleteCustomer kan aanroepen, kan ik iedere customer eruit flikkeren die ik wil. Dus procs geven niet MEER security. Je kunt wat jij wilt ook bereiken met roles en rechten per role per table.

Ik vind het prima dat jij mijn klanten weggooit. Wordt de database niet minder consistent van, wel een stuk sneller! Er wordt eerst aangehaald dat je met root rechten direct op de database de consistentie onderuit kan halen, dan moet je natuurlijk niet met dit - geheel losstaande - voorbeeld komen.

EfBe schreef op donderdag 31 januari 2008 @ 13:21:
[...]
Lijkt me lastig, want er is altijd een tijdstip T te vinden waarbij jouw data inconsistent is in memory.

En daarom doe je dus maar helemaal niks?

EfBe schreef op donderdag 31 januari 2008 @ 13:21:
[...]Wat is een 'bijna' 1:1 structuur ? Volgens mij snap jij overigens niet veel van de werken van sets van entities. Ik HOEF helemaal niet de lookup entities op te halen wanneer ik de fk side ophaal, immers dat is puur voor de UI, dat ik lookup tables nodig heb. Die haal je apart op.

Van mij mag je voor jouw GUI best een databaseje volpoepen met wat je maar wil en welke manier je maar wil, zolang ik later maar niks meer te maken krijg met wat je daar in uitvreet en de feitelijke data gewoon netjes genormaliseerd opgeslagen is. Maar waar wil je nou eigenlijk heen met je verhaal, behalve door door op kleine vergezochte puntjes te scoren een 'overwinning' behalen?

[EfBe]

BikkelZ schreef op donderdag 31 januari 2008 @ 13:49:
[...]
Ik vind het prima dat jij mijn klanten weggooit. Wordt de database niet minder consistent van, wel een stuk sneller! Er wordt eerst aangehaald dat je met root rechten direct op de database de consistentie onderuit kan halen, dan moet je natuurlijk niet met dit - geheel losstaande - voorbeeld komen.

Jouw stored procedure voorbeeld heeft ook niets met consistentie te maken. Die beheer je nl. met constraints, niet met DML

[...]
En daarom doe je dus maar helemaal niks?

Dat zeg ik niet, volgens mij... Jij beweert dat je daarnaar streeft. Dat lijkt me wat lastig, dat geef ik alleen aan. Maar goed... whatever.

[...]
Van mij mag je voor jouw GUI best een databaseje volpoepen met wat je maar wil en welke manier je maar wil, zolang ik later maar niks meer te maken krijg met wat je daar in uitvreet en de feitelijke data gewoon netjes genormaliseerd opgeslagen is. Maar waar wil je nou eigenlijk heen met je verhaal, behalve door door op kleine vergezochte puntjes te scoren een 'overwinning' behalen?

Erm... moet ik het voor je spellen of kun je het zelf ook verzinnen hoe het werkt?. Waar ik heen wil met mijn verhaal? Ik reageer alleen op de iewat kortzichtigheid uit jouw hoek.

Triviaal voorbeeld
Een Order entity die een fk heeft naar OrderStatus, dat een lookup is. Een Order entity heeft OrderStatus in-memory niet nodig om valide te zijn, immers je kunt de FK ook vullen met de ID van de OrderStatus.

Als je een order wilt editen, dan haal je de orderstatus entities op, die zet je in een combo box. Dan heb je de Order en de FK OrderStatusID van Order is verbonden met de ID van de selected OrderStatus in de combobox. Met een controller of wat databinding is dat in nauwelijks code voor elkaar te krijgen.

Wat is het probleem dan met O/R mapping, Bikkelz ? Oh, je bedoelde dat je geen graphs kunt fetchen met O/R mappers? Dacht het toch wel. Sterker, efficienter dan jij met je stored procedures:
Haal orders op met filter F + de gerelateerde OrderStatus entities. Dat zijn 2 queries. In stored procs lukt dit niet, want je moet F passen naar de proc voor OrderStatus om alleen de orderstatus entities te fetchen die je nodig hebt voor de orders die je hebt. Aangezien F vanalles kan zijn (joins, filters, etc.) is dit niet generiek op te lossen met procs. (ja je kunt elke graph en elke filter situatie uitschrijven in SQL in een proc. Maar dat wordt wat veel in een grote applicatie)

Ik zou eigenlijk willen zeggen, met O/R mapping heb je juist meer mogelijkheden met deze situatie dan zonder. Ik sneed dit overigens niet aan, dat deed jij. Als jij dan dingen beweert die niet kloppen, mag ik die rechtzetten. Ga dan niet lopen piepen over vergezochte puntjes en overwinningen halen, ik reageer alleen op jouw posts.

[BikkelZ]

EfBe schreef op donderdag 31 januari 2008 @ 16:20:
[...]

Jouw stored procedure voorbeeld heeft ook niets met consistentie te maken. Die beheer je nl. met constraints, niet met DML

Ja, trek het nog ff verder uit verband. Het ging om een vrij bewerkbaar VARCHAR veld. En het heet nog steeds een foreign key constraint.

EfBe schreef op donderdag 31 januari 2008 @ 16:20:
[...]
Triviaal voorbeeld
Een Order entity die een fk heeft naar OrderStatus, dat een lookup is. Een Order entity heeft OrderStatus in-memory niet nodig om valide te zijn, immers je kunt de FK ook vullen met de ID van de OrderStatus.

Yep. Maar een ID is ook zo nietszeggend als je vervolgens weer wilt weten wat die ID inhoudt.

EfBe schreef op donderdag 31 januari 2008 @ 16:20:
[...]

Als je een order wilt editen, dan haal je de orderstatus entities op, die zet je in een combo box. Dan heb je de Order en de FK OrderStatusID van Order is verbonden met de ID van de selected OrderStatus in de combobox. Met een controller of wat databinding is dat in nauwelijks code voor elkaar te krijgen.Wat is het probleem dan met O/R mapping, Bikkelz ? Oh, je bedoelde dat je geen graphs kunt fetchen met O/R mappers? Dacht het toch wel. Sterker, efficienter dan jij met je stored procedures:
Haal orders op met filter F + de gerelateerde OrderStatus entities. Dat zijn 2 queries. In stored procs lukt dit niet, want je moet F passen naar de proc voor OrderStatus om alleen de orderstatus entities te fetchen die je nodig hebt voor de orders die je hebt. Aangezien F vanalles kan zijn (joins, filters, etc.) is dit niet generiek op te lossen met procs. (ja je kunt elke graph en elke filter situatie uitschrijven in SQL in een proc. Maar dat wordt wat veel in een grote applicatie)

Ik zou eigenlijk willen zeggen, met O/R mapping heb je juist meer mogelijkheden met deze situatie dan zonder. Ik sneed dit overigens niet aan, dat deed jij. Als jij dan dingen beweert die niet kloppen, mag ik die rechtzetten. Ga dan niet lopen piepen over vergezochte puntjes en overwinningen halen, ik reageer alleen op jouw posts.

Ik heb nooit gezegd dat SQL de heilige do all fix all oplossing is, maar iedere keer als ik niet gedetailleerd en desalniettemin alsnog uitzondering a vs product b dan toch alles en omgekeerd tot in iedere uitzondering specificeer in mijn betoog kom jij met een hele lap tekst aan waarmee je mij dan de vloer aan wilt vegen, waarin je vervolgens ook de rest van de discussie hier zo veel mogelijk probeert te negeren om ongehinderd exact op die ene fout in te kunnen gaan.

[ Voor 5% gewijzigd door een moderator op 31-01-2008 19:28 ]

[Creepy]

Eeh, doen we het ff rustig aan? Genoeg op de man gespeeld nu dacht ik zo. Onderbouw met argumenten en laat aub de rest achterwege.

[JaQ]

BikkelZ schreef op donderdag 31 januari 2008 @ 10:25:
[...]
ORM en hulptabellen gaan niet lekker samen nee. Een fout in ORM of de databases naar mijn mening, databases zijn niet in staat om coherente informatie als een simpele strook aan te bieden naar de bovenliggende software. Daardoor blijf van die bijna 1:1 object / table structuren houden bij ORM.

Wellicht omdat een objectmodel nou eenmaal geen relationeel model is? Precies de reden waarom ik 90% van de java applicaties die ik tegen kom ronduit kut vind qua RDBMS gebruik. Logica wordt veelal in de applicatie gelegd, terwijl uiteindelijk de data consistent hoort te zijn (en dat doe je dus middels constraints. Of je vervolgens hier stored procedures bovenop legt zal me een zorg zijn, degene die die stored procedure schrijft mag dat ook in een ORM of simpele DML vastleggen.... ).

Uiteraard is mijn mening enorm getekend, ik werk als Oracle DBA

[vorlox]

Kent niemand de term ontnormaliseren, een database guru shiet me misschien af maar m.b.t performance en het uit elkaar kunnen halen van databases. Kun je er SOMS voor kiezen om iets te ontnormaliseren...
Ook kun je denken aan portabiliteit, als je altijd maar met 1 database werkt kun je optimaal gebruik maken van de door de database ondersteunde datatypes (enum, small int enz)
Echter wanneer je een schema maakt voor meerdere databases (Word je hondsdol van) dan moet je zoeken naar de zwakste schakel in de databases die je moet ondersteunen en alles daarop aanpassen. Als je met oracle werkt merkt je dat je b.v. maar max 30 posities voor je tabelnamen / veldlenghtes index lengtes e.d. mag gebruiken. Ook als je dus een enum wilt ondersteunen zul je dus in b.v. oracle gewoon een varchar moeten gebruiken e.d.

Maar goed om idd op je vraag terug te komen, ik ben ook iemand die altijd alles tot op het bot normaliseert. (NOT). Soms is het gewoon goedkoper om het ..smerig te doen vooral als iets een maand ofzo moet werken. Echter bij belangrijke data (Orders, Bestellingen , Artikelen is het raadzaam om het goed op te zetten inclusief constraints)

[ Voor 7% gewijzigd door vorlox op 16-02-2008 00:22 ]

[flowerp]

curry684 schreef op dinsdag 29 januari 2008 @ 11:18:
[...]
Waarom niet? De query schrijft al voor in welke volgorde je je velden select, dan maakt het in theorie weinig uit of je vervolgens by name of index eraan refereert. De code moet je toch meeveranderen als je de query wijzigt, dus waarom daar geen strakke relatie tussen leggen?

Maar de query kan natuurlijk in een apart .sql bestand staan, zodat je in de source code alleen een referentie naar dat bestand ziet, en een JDBC call later een resultset hebt. In dat geval is named lookup natuurlijk erg veel duidelijker.

De query kan daarnaast ook in meerdere plekken in de code gebruikt worden. Als je met indexed lookup werkt, kun je bij veranderingen aan de query moeilijk columns weghalen en zul je voornamelijk columns aan het einde van de lijst toe moeten voegen, wil je niet alle bestaande code breken.

Ik vergelijk het een beetje met classes. Als je iets hebt als:

Java:

public class Record {
  public String foo;
  public String bar;
}

Dan is het duidelijk als je in code record.foo en record.bar gebruikt. Natuurlijk kun je dezelfde data ook modelleren als:

Java:

String[] record = new String[2];

En dan naar de fields verwijzen via record[0] en record[1]. Het -kan-, maar of het ook handig is?

(en natuurlijk is een relationele tabel niet hetzelfde als een Class (anders hadden we geen ORM nodig ), maar het bovenstaande dus even als analogie)

[mphilipp]

momania schreef op maandag 28 januari 2008 @ 16:06:
Klinkt gewoon als: "legacy"

Ehhh...normalisatie is niet iets van de laatste jaren hoor... Dat bestond 20 jaar geleden ook al. Meneer Codd heeft die regels opgesteld terwijl hij de relationele database bedacht.

Het is gewoon luiheid/onbenulligheid. Ik heb de afgelopen 20 jaar zoveel eikels meegemaakt die klakkeloos maken wat een of andere knurft heeft bedacht. Ook al klopt dat van geen meter. Ik doe zoiets niet. Nooit gedaan ook. Ook niet als junior. Als ik ergens mijn vraagtekens bij heb, zeg ik dat en wijs ze op de mogelijke nadelen. Als het écht iets vreselijks is, zorg ik dat het ergens op papier komt oid want naderhand heb ik het natuurlijk gedaan.

Punt is dat iedereen die dergelijke dingen (bewust) fout doet, denkt dat het geen kwaad kan. Dat is dan een gebrek aan visie denk ik. Zo iemand kan zich niet voorstellen dat een systeem waarschijnlijk nog wat jaartjes mee moet. Of ze geloven werkelijk dat de klant precies weet wat ie ooit gaat willen. Want vaak is dat ook het probleem: men roept dat iets tijdelijk is of dat men nooit aan de functionele eisen van het systeem zal gaan tornen. En binnen 6 maanden is het meestal toch zover. En dan zitten ze met een datamodel dat een bepaalde structuur niet meer toestaat zonder een ingewikkelde conversie.

Een van de redenen waarom ik (nu dan eindelijk succesvol) uit het ontwikkelwerk ben gestapt. Kostte wat tijd, maar het is dan gelukt. Baalde ervan om aan krakkemikkige systemen te werken op projecten die gedoemd zijn...

[PainkillA]

is het niet vaak dat tijdgebrek waardoor vele systemen maar wat in elkaar geflasnt worden en zo slech onderhoudbaar/wijzigbaar als maar kan? Als ik ergens een hekel aan heb is het wel een te krappe tijd voor toch soms wel complexe systemen waardoor je het maar op de "snel af maar bagger" manier meot doen.

[flowerp]

PainkillA schreef op zondag 17 februari 2008 @ 16:32:
is het niet vaak dat tijdgebrek waardoor vele systemen maar wat in elkaar geflasnt worden en zo slech onderhoudbaar/wijzigbaar als maar kan?

Het is ook dikwijls onkunde van het personeel. Jongetjes van 18 die PHP/MySQL op hun CV zetten en die door een baas worden ingehuurd die het verschil niet snapt tussen de kunde van een scriptkiddie en iemand die minstens 4 jaar studie achter de keuzen heeft en enkele jaren ervaring.

Natuurlijk hebben deze jochies de ballen verstand niet van normalisatie en correcte naamgevingen. Logisch, want in de regel kopiëren ze slechts scriptjes van PHPFreakz. "Naamgeving? Waarom zou ik daar over nadenken, in scripts staan toch al namen??? :?"

Op de een of andere manier blijven dergelijke 'ontwerpen' toch langer in gebruik en mag jij als iemand die wel een beetje weet hoe dingen werken er later uitbreidingen op maken.

[LauPro]

Dat alles valt weer terug te voeren op budget. ICT is voor de meeste bedrijven al duur genoeg (zeker in MKB), dus geen wonder dat men aan alle kanten wil besparen. Natuurlijk kan je voor 150 euro de uur iemand met 10 jaar ervaring neerzetten op een project, maar misschien bereik je wel evenveel met iemand die maar 25 euro per uur kost en die er dan 4 keer langer over doet.

Daarnaast richten de bedrijven die echt de kennis in huis hebben zich meestal niet op die bedrijven. Hoe dan ook, vroeg of laat zal de kennis van een expert nodig zijn dus ik zie het niet als een gevaar voor de sector.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 99% gewijzigd door Ruudjah op 02-12-2009 00:23 ]

[LauPro]

Ruudjah schreef op zondag 17 februari 2008 @ 23:38:
Ja, precies. Het is alleen jammer dat ze niet inzien dat een developer van 150 in het uur wel een systeem kan bouwen wat efficient, onderhoudbaar, duidelijk, goed ontworpen etc etc etc is. Die iemand van 25 euro in het uur krijgt misschien ook wel een systeem af, maar kwa kwaliteit veel minder.

Het staat nog niet vast of iemand met 10 jaar ervaring per definitie een betere kwaliteit kan leveren. Doorgaans zal dat zeker zijn maar er zijn ook mensen bij die in een totaal eigen wereld leven en techniek van 10 jaar geleden toepassen.

Het punt is dat bedrijven niet inzien dat goedkoop duurkoop is.

Voor een simpel signupformulier is een uitgebreide analyse helemaal niet nodig. Daarnaast wil en kan men aan het begin van een traject niet altijd de hoofdprijs betalen.

Ontopic: Ik denk dat opleidingen veel te weinig aandacht besteden aan documenteren, specificeren en benamen van entiteiten, klassen en dergelijke. Hongaarse notatie?

Het probleem zit hem niet in de opleidingen maar in de industrie die razendsnel verandert. Ook qua documentatiemethodes, alles. Je moet als moderne developer eigenlijk in een metataal kunnen schrijven, terwijl je vroeger gewoon echt enkel en alleen COBOL zou doen. En dingen als Hongaarse notatie: veel mensen beschouwen dat als een aftandse legacy van C, daar zijn ook modernere varianten voor (of bijvoorbeeld een editor die dmv colorcoding variabletypes weergeeft).

[EfBe]

(en natuurlijk is een relationele tabel niet hetzelfde als een Class (anders hadden we geen ORM nodig ), maar het bovenstaande dus even als analogie)

Een class definitie 'Customer' en een tabeldefinitie 'Customer' representeren wel degelijk hetzelfde. Als ze dat niet doen, dan zit je in je applicatie met 2 verschillende abstracte entity definities te werken. Lijkt me het begin van het einde.

PainkillA schreef op zondag 17 februari 2008 @ 16:32:
is het niet vaak dat tijdgebrek waardoor vele systemen maar wat in elkaar geflasnt worden en zo slech onderhoudbaar/wijzigbaar als maar kan? Als ik ergens een hekel aan heb is het wel een te krappe tijd voor toch soms wel complexe systemen waardoor je het maar op de "snel af maar bagger" manier meot doen.

Nee, de meeste mensen die werken aan software zijn gewoon niet goed genoeg voor hun vak. Iemand die hello world kan schrijven in C# is nog geen software engineer die weet van de basisbegrippen van de informatica... Net zoals iemand die geprogrammeerd heeft op zn afstudeeropdracht voor werktuigbouw geen software engineer is bv. Die mensen op een project zetten waar basisbegrippen essentieel zijn (en dat is vrijwel altijd zo) dan heb je een probleem, of als je geluk hebt gaat het net goed.

Het is niet alleen de kunde (of beter: het gebrek eraan) van veel mensen overigens hoor. Veelal gaat het project mis door politieke spelletjes van managers, geld en daardoor brakke planningen.

LauPro schreef op zondag 17 februari 2008 @ 23:48:
[...]
Het staat nog niet vast of iemand met 10 jaar ervaring per definitie een betere kwaliteit kan leveren. Doorgaans zal dat zeker zijn maar er zijn ook mensen bij die in een totaal eigen wereld leven en techniek van 10 jaar geleden toepassen.

Als jij denkt dat techniek belangrijk is voor goede software snap je niets van informatica. Iets wat 10 jaar geleden waar was in computer science, is dat tegenwoordig nog steeds. Talen/tools veranderen wellicht, basisbegrippen en daarop gefundeerde solide wijsheden niet.

Het punt is juist dat mensen die 10-15 jaar ervaring hebben niet meer software bouwen. Die worden projectleider of manager. Het werk wordt gedaan door mensen die erg weinig ervaring hebben en omdat er in nederland maar een handjevol informatici per jaar afstudeert, is het gros van wat code zit te tikken self-made specialist.

[...]
Het probleem zit hem niet in de opleidingen maar in de industrie die razendsnel verandert. Ook qua documentatiemethodes, alles. Je moet als moderne developer eigenlijk in een metataal kunnen schrijven, terwijl je vroeger gewoon echt enkel en alleen COBOL zou doen. En dingen als Hongaarse notatie: veel mensen beschouwen dat als een aftandse legacy van C, daar zijn ook modernere varianten voor (of bijvoorbeeld een editor die dmv colorcoding variabletypes weergeeft).

hungarian notation heeft niets met informatica te maken en is daarom irrelevant. Het is wellicht een leuk voorbeeld voor de wat softere vakken tijdens een studie om aan te geven dat goed samen kunnen werken essentieel is voor het eindresultaat in een team, maar voor de rest voegt kennis daarvan niets toe.

Ik snap verder jouw opmerking over dat de industrie razendsnel verandert niet. Basisbegrippen uit de informatica zijn dingen die veranderen niet doordat MS een nieuwe versie van .NET uitbrengt of dat we nu, doordat een marketeer dat roept, met zn allen silverlight of flash/flex/whatever dingen moeten gaan bouwen.

Basisbegrippen aanleren tijdens een studie, zodat je niet gedwongen wordt hoeken af te snijden ivm deadlines/projectgrenzen, is essentieel. DAARNA doe je dat nl. niet meer. Het nadeel is echter dat je WEL die basisbegrippen nodig hebt voor je verdere werk.

Ik vind het bv tenenkrommend dat veel mensen die met hun handen aan databases zitten helemaal niet snappen wat een 'entity' eigenlijk inhoudt, wat NIAM is etc. Als je vanuit de hobbysfeer bezig bent met databases en denkt in tabellen... soit. Maar als professional vind ik het, sorry, een doodzonde als men niet dat soort basisbegrippen snapt. Ik verwacht van een professional dat hij/zij zn vak verstaat. Dat verwacht men nl. van mij ook, dus waarom kan ik dat niet van mede-vakgenoten verlangen? Of bestaat er zoiets als een semi-professional in ons vakgebied, die wel het volle pond vraagt en krijgt, maar het werk aflevert van een amateur met 2 weken ms access ervaring?

[ Voor 106% gewijzigd door EfBe op 18-02-2008 09:37 ]