[SQL] En waarom normaliseer jij niet?

[BikkelZ]

Ruudjah schreef op zondag 17 februari 2008 @ 23:38:Ontopic: Ik denk dat opleidingen veel te weinig aandacht besteden aan documenteren, specificeren en benamen van entiteiten, klassen en dergelijke. Hongaarse notatie? 95% die uit een HBO informatica opleiding komt heeft geen idee waar je het over hebt. Normaliseren? Wel geleerd, maar half weggezakt. Correct OO design? Toch gewoon alle tabellen als klassen implementeren? Als opleidingen erop zouden hameren dat naamgeving, OO ontwerp, normaliseren en documenteren de belangrijkste dingen zijn die je moet kunnen dromen, die erin gestampt moeten zitten, die je bij wijze van spreken direct als je wakker word moet kunnen opdreunen, dan zouden dit soort dingen VT zijn. Je haalt het dan niet meer in je hoofd om ff een variabele 'temp' te noemen. Of hongaarse notatie toepassen op .NET code. Of toch stiekum eventjes die enumeratie als string normaliseren. Of weigeren OO principes toe te passen.

Ondanks dat ik enorm op het Fontys afgegeven heb, is dit wel een regelmatig terugkomend onderdeel geweest van mijn studie. Dat doen ze ook wel. En Hongaarse notatie: waarom moet er legacy onderwezen worden?

[LauPro]

EfBe schreef op maandag 18 februari 2008 @ 09:14:
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.

Ben met je eens dat dat het geval zou moeten zijn, in de praktijk zullen echter veel systemen zijn waar dit niet het geval is. Genoeg kansen dus nog .

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.

Techniek gedoel ik generiek zowel qua organisatie alswel implementatie. Om maar een voorbeeld te nemen aan Agile development, een nog jonge methode die de afgelopen 10 jaar zich zeker heeft bewezen. Door de verandering van techniek veranderen ook basisbegrippen. Vroeger hadden we de gecentraliseerde execution domains, dat is daarna uitgesplitst naar de fat clients. De laatste tijd zie je een omdraaid effect dat bedrijven weer gaan standaardiseren op gecentraliseerde execution domains. Dit heeft ook veel impact op de gebruikte software en technieken, daar waar software op de fat client wordt geoptimaliseerd voor single user worden gecentraliseerde systemen (weer) multiuser met alle implicaties van dien.

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.

Er zijn ook echt wel mensen die 10-15 jaar ervaring hebben en geen manager zijn, dit bedoel ik niet negatief maar er lopen natuurlijk niet alleen maar managers rond. En nogmaals vind ik dat je hier de vraag moet stellen of je altijd een afgestudeerd iemand moet hebben voor de job. Vergelijk het met het schildersdiplomap. Er zijn zat mensen die hun huis zelf verfen zonder diploma, dat kan voor waardevermindering zorgen. Moet je dan maar verplichten dat je dat altijd aan een gediplomeerd schilder over moet laten?

Het is een vrije markt, zowel particulieren alswel bedrijven kunnen zelf kiezen waar ze hun werk uitbesteden.

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.

Dit vind ik een beetje overtrokken, je moet gewoon verstand van zaken hebben en kunnen leren uit de lessen uit het verleden. De HN is wat dat betreft een mooi voorbeeld van een eigenschap van decentralised working. Het principe achter deze stelregel gaat nog steeds op, de implementatie is echter verouderd.

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.

De meeste HBO opleidingen zijn vooral gericht op de praktijk. Dus in zoverre hebben veranderingen in de industrie wel direct impact op de recentheid van deze opleidingen. Bij WO opleidingen heb je op zich gelijk als je zegt dat er meer op een abstracter niveau wordt gekeken, maar ook dan kan iemand volledig verdwalen als hij wel de kaders weet maar de taal spreekwoordelijk niet spreekt.

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.

Dit ligt natuurlijk geheel aan je positie en verantwoordelijkheden. Vanaf een software developer gezien moet je die eigenschappen hebben, al hoewel veel bedrijven hier een leerproces acceptabel vinden. Het is voor die bedrijven ook niet altijd in te schatten wat marktconform is en waar de top ligt.

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?

Ja, die bestaan. Ik heb het helaas zelf meegemaakt pas. Maar er zijn ook nog gerenommeerde bedrijven die voor applicaties Access gebruiken. En als je daar opmerkingen over gaat maken krijg je een recalcitrante projectleider over je heen die zijn kindje gaat verdedigen wat uiteindelijk je eigen reputatie alleen maar schaadt.

Ik zou zelf nooit geld durven vragen voor werkzaamheden aan een Access database. En mocht ik ooit voor die keuze komen te staan dan zou ik toch proberen om zo'n opdracht om te vormen in een migratieproject. Er zijn echter zat mensen die niet zo principieel zijn en (hun goed recht) gewoon werkzaamheden uitvoeren als de klant daarvoor wil betalen. Hoe zwartmakend en derigerend dat ook kan zijn.

[flowerp]

EfBe schreef op maandag 18 februari 2008 @ 09:14:
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.

Inderdaad, natuurlijk -representeren- ze het zelfde in dat geval

Technisch gezien zijn een class en een tabel definitie wel verschillend (anders zou een class dus gewoon 1:1 in de DB gestopt kunnen worden zonder enige vorm van mapping). De opmerking was echter niet zo diepgravend bedoeld. Gewoon om me zelf een beetje in te dekken daar ik verwachte dat er wel weer reacties zouden komen in de trend van: "Hey, das appels met peren vergelijken, een class is niet hetzelfde als een tabel dus je vergelijking slaat nergens op".

Nee, de meeste mensen die werken aan software zijn gewoon niet goed genoeg voor hun vak.

Amen!

Als dat nu eens algemeen geaccepteerd zou gaan worden. In de advocatuur heb je toch ook duidelijk top advocaten en gewone advocaten. In b.v. de sporters wereld geldt dat nog sterker. Ontwikkelaars moeten echter altijd maar allemaal gelijk zijn aan elkaar. Hooguit wordt iemand senior genoemd op basis van hoe lang die persoon bij een bedrijf in dienst is (wat onzin is, maar de meeste bedrijven die ik ken hebben gewoon amper maatstaven om te meten hoe goed iemand nu is of niet).

[ Voor 25% gewijzigd door flowerp op 18-02-2008 20:39 ]

[EfBe]

flowerp schreef op maandag 18 februari 2008 @ 20:34:
[...]
Amen!
Als dat nu eens algemeen geaccepteerd zou gaan worden. In de advocatuur heb je toch ook duidelijk top advocaten en gewone advocaten. In b.v. de sporters wereld geldt dat nog sterker. Ontwikkelaars moeten echter altijd maar allemaal gelijk zijn aan elkaar. Hooguit wordt iemand senior genoemd op basis van hoe lang die persoon bij een bedrijf in dienst is (wat onzin is, maar de meeste bedrijven die ik ken hebben gewoon amper maatstaven om te meten hoe goed iemand nu is of niet).

Het is gewoon een geldkwestie, veelal worden trainees 'weggezet' bij klanten voor een vol tarief, worden mensen met 2 jaar knutselervaring in office VBA als senior software engineers naar klanten gestuurd, puur omdat die titels meer geld opbrengen.

Het stoort mij ook mateloos. Maar er is weinig tegen te doen ben ik bang: er zijn gewoon veel te weinig mensen met voldoende kennis. En dus worden de mensen die wat cursussen hebben gevolgd al gauw voor specialist aangezien, omdat er niemand anders is en de problemen bij 'de klant' moeten wel worden opgelost.

Een aantal jaren al is er een exponent bijgekomen: de architect. 10 jaar geleden was de oppermufti van de software jongens van een bedrijf de 'senior', nu is dat de 'architect'. Het vervelende is dat veel architecten niet zelf software bouwen, en wel allerlei leuke dingen bedenken, maar de haalbaarheid ervan niet snappen noch kunnen inzien.

Helaas wordt het alleen maar erger. In NL studeren dacht ik zo'n 150 mensen per jaar af in computer science en op het HBO is dat ook ong zoveel (kan de cijfers mis hebben, maar het is schrikbarend laag). Daarmee kom je er bij lange na niet. In de komende jaren krijgen we dus te maken met een sterke vraag naar mensen die een muis van een keyboard kunnen onderscheiden, om maar de vacatures te vullen. Ik zie de sollicitatierondes in auto-showrooms al weer voor me (wat een beschamende vertonen was dat, zeg). Tja... er is niet iets aan te doen, er een beschermd vak van maken is niet echt nuttig: de groep die die erkenning niet haalt is veel groter.

[BikkelZ]

Zo weinig maar? Waarom verdienen de paarse broeken en HEAO types dan toch meer?

[EfBe]

BikkelZ schreef op dinsdag 19 februari 2008 @ 10:05:
Zo weinig maar? Waarom verdienen de paarse broeken en HEAO types dan toch meer?

Tja, geen idee. Een manager verdient meer dan iemand die de software daadwerkelijk bouwt, en dat komt mogelijkerwijs omdat de manager wellicht ouder is, vroeger de programmeur was etc. en de bouwer 2 jaar ervaring heeft en net 25 is.

Als je als persoon met hart voor het vak je werk echt goed wilt doen dan is daar niet echt veel waardering voor bij management, wanneer dat meer tijd kost. Er is een of andere blindheid geslopen in het gros van de managers die het onmogelijk voor hen maakt om in te zien dat kwaliteit op den duur loont. Op de langere termijn hebben wij als maatschappij er alleen maar baat bij. Maar hoe het nu gaat, vrees ik het ergste, temeer omdat we steeds meer afhankelijk worden van software maar de niet-nerds niet inzien dat die afhankelijkheid wel een nadeel heeft: zonder nerds gaat alles fout.

het is echt heel weinig wat van de universiteiten en hbo's afkomt. Dat is al een tijdje zo trouwens. In 1994, toen ik van de HIO enschede afkwam, waren we met zn 40en die afstudeerden. In datzelfde jaar begonnen er 38 nieuwe studenten als ik het goed heb. Aangezien er nogal wat mensen afvallen gedurende de studie kun je wel uitrekenen hoe weinig er afkwamen in 1998-99.

Overigens ben ik van mening dat de echte specialisten wel degelijk veel geld krijgen betaalt. Het is alleen zo dat je als specialist niet voor uurtjefactuurtje excelprutjes moet gaan zitten krassen bij CMG, maar bij een softwarehuis de hoofdontwikkelaar moet worden. Iemand die echt goed is verdient zn/haar geld echt wel terug: het werk komt af, van hoge kwaliteit, onderhoudbaar etc. maar men is daar heel vaak niet in geinteresseerd: als de klant maar tevreden is (ookal weet de klant niet wat beter was geweest) of erger: als de klant de rekening maar betaalt. Ik bedoel: de belastingdienst jaagt er per jaar 400 miljoen euro (!) doorheen met 4200 (!) IT medewerkers.Daar werken vele externen. Elk jaar gaat het slechter met de software daar. Totdat iemand echt paal en perk gaat stellen aan dat soort zaken (die overal spelen, niet alleen bij de belanstingdienst), is het echt heel lastig dat nog op te lossen, temeer daar over 10 jaar de hoeveelheid software die onderhouden moet worden veel groter is dan nu, maar de hoeveelheid mensen die dat kan niet echt veel groter.

[Hydra]

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).

Ik heb een jaar of 8 geleden een meisje dat aan de Fontys studeerde moeten helpen met haar Java opdrachten omdat de docenten er zelf ook niet uitkwamen, dus breek me de bek niet open over de Fontys. Ik heb zelf HBO-I gedaan aan Saxion Enschede (toen nog HIO), en die opleiding zijn ze ook compleet aan het uithollen. We hebben hier een kerel gehad die na mij begonnen is, en er worden steeds meer vakken uitgehold om toch aan hun streefcijfers wat betreft het aantal studenten dat afstudeert te komen.

EfBe schreef op dinsdag 19 februari 2008 @ 09:42:
Helaas wordt het alleen maar erger. In NL studeren dacht ik zo'n 150 mensen per jaar af in computer science en op het HBO is dat ook ong zoveel (kan de cijfers mis hebben, maar het is schrikbarend laag). Daarmee kom je er bij lange na niet. In de komende jaren krijgen we dus te maken met een sterke vraag naar mensen die een muis van een keyboard kunnen onderscheiden, om maar de vacatures te vullen. Ik zie de sollicitatierondes in auto-showrooms al weer voor me (wat een beschamende vertonen was dat, zeg). Tja... er is niet iets aan te doen, er een beschermd vak van maken is niet echt nuttig: de groep die die erkenning niet haalt is veel groter.

Oh, Nederland gaat een groot probleem krijgen als het om capabele ITers gaat. Ik ben onlangs naar Saxion geweest om weer eens een praatje te maken en te informeren over hoe we nu aan stagairs moeten komen, en dat gaat een groot probleem worden. Voor elke HBO-I-er zijn er 10 opdrachten, en de instroom wordt alleen maar lager terwijl de uitval ongeveer gelijk blijft. Dit hebben we allemaal aan onze overheid te danken, we zien nu de gevolgen van het falende beleid m.b.t. onderwijs.

BikkelZ schreef op dinsdag 19 februari 2008 @ 10:05:
Zo weinig maar? Waarom verdienen de paarse broeken en HEAO types dan toch meer?

Omdat mensen nog niet doorhebben hoe schaars goeie developers aan het worden zijn. Moet je eens kijken wat je in de VS kunt verdienen t.o.v. hier.

[BikkelZ]

Hydra schreef op dinsdag 19 februari 2008 @ 13:31:
[...]
Ik heb een jaar of 8 geleden een meisje dat aan de Fontys studeerde moeten helpen met haar Java opdrachten omdat de docenten er zelf ook niet uitkwamen, dus breek me de bek niet open over de Fontys. Ik heb zelf HBO-I gedaan aan Saxion Enschede (toen nog HIO), en die opleiding zijn ze ook compleet aan het uithollen. We hebben hier een kerel gehad die na mij begonnen is, en er worden steeds meer vakken uitgehold om toch aan hun streefcijfers wat betreft het aantal studenten dat afstudeert te komen.

Je hebt natuurlijk Fontys, Fontys, Fontys en Fontys hè. Maar ik moet zeggen dat het me inderdaad wel opviel hoe je gematst wordt om toch je diploma te halen. Op zich op een enkeling na heb ik niet echt docenten meegemaakt die beter wat anders konden gaan doen.

[LauPro]

EfBe schreef op dinsdag 19 februari 2008 @ 09:42:
Helaas wordt het alleen maar erger. In NL studeren dacht ik zo'n 150 mensen per jaar af in computer science en op het HBO is dat ook ong zoveel (kan de cijfers mis hebben, maar het is schrikbarend laag). Daarmee kom je er bij lange na niet. In de komende jaren krijgen we dus te maken met een sterke vraag naar mensen die een muis van een keyboard kunnen onderscheiden, om maar de vacatures te vullen. Ik zie de sollicitatierondes in auto-showrooms al weer voor me (wat een beschamende vertonen was dat, zeg). Tja... er is niet iets aan te doen, er een beschermd vak van maken is niet echt nuttig: de groep die die erkenning niet haalt is veel groter.

Wil dat niet gewoon zeggen dat je als automatiseerder gewoon flexibeler op moet gaan stellen? Het is bijna altijd lonender en uitdagender om bij grote projecten veel zelf te ontwikkelen. Bedrijven kijken gewoon heel simpel hoeveel productie iemand kan behalen en wat hij daarbij op kan leveren. Daar worden echt geen grotere verhalen omheen gehangen dan jij nu doet voordoen.

Bovendien ontgaat me de insteek van het 'maatschappelijk nut' een beetje. Als je wil dat de kwaliteit van het onderwijs beter gaat worden had men toch echt 20 jaar geleden al moeten beginnen. Nu is het gewoon te laat, einde verhaal. Zeker wel belangrijk om voor de toekomst er weer in te investeren maar verwacht op korte termijn geen resultaat.

Hydra schreef op dinsdag 19 februari 2008 @ 13:31:
Omdat mensen nog niet doorhebben hoe schaars goeie developers aan het worden zijn. Moet je eens kijken wat je in de VS kunt verdienen t.o.v. hier.

Dit is gewoon BS, onvergelijkbaar en totaal offtopic. Het complete arbeidsklimaat is in de VS anders.

[Anoniem: 140111]

We hebben hier een kerel gehad die na mij begonnen is, en er worden steeds meer vakken uitgehold om toch aan hun streefcijfers wat betreft het aantal studenten dat afstudeert te komen.

Dat is een ontwikkeling die, spijtig genoeg, niet alleen tot informatica beperkt blijft. Scholen passen het niveau aan naar het niveau van de studenten. Dus, de eisen gaan omlaag, het niveau gaat omlaag, zodat de cijfers een beetje gehandhaaft blijven.

Concreet voorbeeld: ik zit nu in mijn afstuderen, maar omdat er bepaalde vakken weg zijn gevallen hebben ze als vulling de vakken SOTA en ABV09 in het leven geroepen, de eerste is op zich nog redelijk interessant, namelijk het bijwonen van lezingen die op school gegeven worden, maar de tweede houdt in dat we een zelfstandig ondernemer moeten gaan interviewen

Wat bereiken ze er mee: het aantal ECTS wat een student nodig heeft voor zijn diploma. Je kan me niet wijsmaken dat dergelijke nonsense ook maar iets aan praktisch nut heeft.

Theoretische diepgang hebben ze uberhaupt nog nooit van gehoord, de Java vakken in het eerste jaar Volgens het curriculum kwam object oriëntatie pas aan bod aan het eind van jaar 1. Dat is op zich niet zo erg, mits er goede lessen worden gegeven over het hoe en wat van algoritmiek e.d., maar dat was natuurlijk niet het geval, veel verder dan een array of system.out.println() zijn we niet gekomen. En nóg vallen er mensen af met als gevolg dat de stof nóg minder diepgang krijgt, zodat er minder mensen afvallen.

Ander voorbeeld, wiskunde, de bedoeling: complexe getallen, integralen, partiële integralen, differentiëren en lineaire algebra
Uitwerking: basis goniometrie. (SOS-CAS-TOA ), met hier en daar een inverse en 3de graads polynoom. Daarnaast nog een vak lineaire algebra.
Reden? Teveel moeite met wiskunde, dus curriculum aangepast op het niveau van de studenten, met als gevolg dat meer mensen het halen, met als gevolg dat het diploma weer een stukje minder waard is geworden.

Minor project, 30ECTS, woensdagmiddag terugkoppeling. Bedoeling: bedenk, ontwerp en implementeer een 3dgame in een geschikte taal. Bewijs dat je een X-aantal competenties hebt. Prima, maar je zou verwachten dat je tijdens een minor software engineering vakken krijgt over het onderwerp. Neen. Een docent waarvan ik de kunde twijfelachtig zou willen noemen en een andere die niet eens kán programmeren

Afstuderen, 5 dagen in de week? Nee, we hebben verzonnen dat we die laatste dag gaan verpakken in het zogenaamde 'leerwerkbedrijf', daar haal je 6 ECTS mee, dus hoef je nog maar 4 dagen in de week af te studeren. Kun je nog lekker op school ABV vakken gaan zitten, tijdens je afstuderen. PRIMA regeling, logisch ook, afstuderen is nog niet druk genoeg, natuurlijk.

^{Hmmmm, enigszins off-topic gal spuwen}

[kamerplant]

Hydra schreef op dinsdag 19 februari 2008 @ 13:31:
[...]


Oh, Nederland gaat een groot probleem krijgen als het om capabele ITers gaat. Ik ben onlangs naar Saxion geweest om weer eens een praatje te maken en te informeren over hoe we nu aan stagairs moeten komen, en dat gaat een groot probleem worden. Voor elke HBO-I-er zijn er 10 opdrachten, en de instroom wordt alleen maar lager terwijl de uitval ongeveer gelijk blijft. Dit hebben we allemaal aan onze overheid te danken, we zien nu de gevolgen van het falende beleid m.b.t. onderwijs.

Kun je het concreter maken? Wat zou de overheid moeten doen om de kwaliteit van afgestudeerde studenten te verhogen?

Als ik even naar mijn eigen opleiding kijk (HBO-BI), dan zie ik dat de opleiding prima is. Wat ik ook zie is dat een grote groep studenten net voldoende motivatie heeft om alles met een 6je af te ronden. Toetsen worden nauwelijks geleerd zodat na 3 kansen het eindelijk eens wordt gehaald omdat een toets uitlekt. Er zijn ook genoeg studenten die hier niet aan meedoen en zodoende wel genoeg opsteken van de opleiding. (true, ik breng het een beetje zwart-wit)
Om nu zomaar de schuld heel gemakkelijk bij "de overheid" te leggen, mwahh. Studenten zelf hebben ook een behoorlijk verantwoordelijkheid voor hun eigen leerproces. Neem normaliseren, dat wordt écht wel in een HBO-I opleiding gegeven hoor

[Gé Brander]

Ja, en die 6je studenten weten net aan hoe je het moet schrijven (normaliseren) en weten dat het iets met database structuren te maken heeft.

[curry684]

Datafeest schreef op dinsdag 15 juli 2008 @ 10:55:
[...]


Kun je het concreter maken? Wat zou de overheid moeten doen om de kwaliteit van afgestudeerde studenten te verhogen?

Weinig, dat zit idd bij de studenten zelf. Het trieste niveau van de gemiddelde Nederlandse (of eender welk land) ICT'er zit 'm meer in dat er zo weinig mensen met een programmeerafwijking geboren worden en dat het een van de takken van sport is die je iemand die het echt niet kan ook niet geleerd krijgt.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 123% gewijzigd door Ruudjah op 02-12-2009 00:24 ]

[frickY]

offtopic:
Ah, had het topic uit het oog verlogen. Even een paar maanden terug..

EfBe schreef op dinsdag 29 januari 2008 @ 10:38:
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.

Ik denk dat ik liever een query zie met p.productNaam dan product.naam AS productNaam
Helemaal omdat een collega in een toekomstige wijziging in een nieuwe query misschien wel besluit te aliassen naar produktNaam. Dan kun je de noodzaak daarvan dan toch maar beter voorkomen?

Voorbeeld. Het selecteren van een artikel uit een subcategorie binnen een categorie, zonder prefixen.

SQL:

SELECT
  artikel.naam
  subcategorie.naam,
  categorie.naam,
FROM artikel
INNER JOIN categorie AS subcategorie ON subcategorie.id = artikel.categorieId
INNER JOIN categorie ON categorie.id = subcategorie.parentId

Als je deze resultset terug laat geven als array of object, heeft deze maar 1 waarde; naam.
Dan zou je in dit geval alle 3 de kolommen moeten aliassen

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!)

Dat heeft niets met tikken te maken, maar met overzicht.
In mijn database-verkenner heb ik ~300px ruimte voor tabelnamen, en de rest van mijn resolutie voor de kolommen. Dan zie ik liever alles in één oogopslag dan dat ik moet gaan scrollen.
In een database achter een webwinkel is het voor iedereen denk ik makkelijk gokken wat er in een tabel "prodcats" met de kolommen "productID" en "categorieID" wordt opgeslagen?

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.

En dan set je de value "naam" uit de kolom "product" in een property "productNaam", en het value uit "naam" uit de tabel "categorie" in "categorieNaam" Wat is hierdan het voordeel van boven wel prefixen en gewoon named fetchen, en dus die hele mapping overslaan?

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?

Omdat je 100 regels verder niet meer weet welke index naar welke kolom refereert, of omdat je gedwongen wordt nieuwe kolommen aan het eind van de SELECT toe te voegen omdat je anders al je indexen opnieuw kan gaan lopen nummeren?

Tenzij je je SELECT opbouwt met een array en diezelfde array vervolgens ook weer gebruikt om de numerieken indexen te mappen naar named elementen... maar dan kies ik toch liever voor het prefixen van die kolommen en in een keer mijn result named op te halen.
Maar grappig dat je je PK wél prefixed, terwijl de andere kolommen net zo goed uniek zijn voor die entitiet (een kolom 'naam' in een tabel 'product' is heel wat anders dan een veld 'naam' in een tabel 'gebruikers').

Jammer dat hier na pagina 1 niet verder op door is gegaan, maar misschien bij deze alsnog

[Cousin Boneless]

En hij heeft een prachtig verhaal geschreven: Maybe normalizing isnt normal.

Wat een waanzinnig slecht voorbeeld.. je moet a) hier je database structuur gaan wijzigen als een gebruiker meer dan 2 screen_names, meer dan 3 work_histories of meer dan 3 afiliations heeft.
En b) als je hierover een query gaat loslaten ('geef mij alle screen_names') moet je naar verschillende velden kijken. Voel een ontzettende spagetti code opkomen, zowel in sql als in de business objecten.

Er zijn best redenen te vinden om bepaalde zaken niet te normaliseren, maar de reden dat je 6 joins lelijk vindt, hoort daar nou net niet bij. Dat is toch netjes weggewerkt in de business layer als het goed is, en als die laag ontbreekt, is er hooguit één plek waar je al deze informatie tegelijk toont: de detailview van de user. En op die plek heb je geen database performance nodig.

This works -- queries are now blindingly simple (select * from users), and probably blindingly fast, as well. But you'll have a bunch of gaping blank holes in your data, along with a slew of awkwardly named field arrays. And all those pesky data integrity problems the database used to enforce for you? Those are all your job now. Congratulations on your demotion!

Edit: Ow.. was ook bedoeld als slecht voorbeeld

[ Voor 24% gewijzigd door Cousin Boneless op 15-07-2008 23:05 ]

[remco_k]

Normalisatie: Ik durf te zeggen dat ik, als ik een database ontwerp maak of aanpas, altijd normaliseer. Maar soms (of eigenlijk bij 90% van mijn opdrachten) heb ik te maken met derden die de database hebben ontworpen en ook een reeks applicaties daaromheen en daar mag ik dan op inhaken met een reeks applicaties van mij en ook een aantal aanpassingen aan de database doen.

... En van dat laatste heb ik momenteel last.
Ben bezig met een bron database van de klant, die heeft de database en een applicatie laten ontwikkelen, jaren geleden bij iemand anders. Kijkend naar die database heeft er iemand een keer heel goed over nagedacht. Duidelijke naamgeving, voor zo'n beetje elke manier van data verkeer is een stored procedure aangemaakt, en bijna alle mogelijke constraints om curruptie te voorkomen zitten erin... Bijna alle... En helaas op 1 of 2 plekken geen normalisatie. Dat vergeef ik de ontwikkelaar nog, want de database is huge qua opzet.
Nu heb ik de eer om rondom die database een aantal uitbreidingen op te doen, dmv synchronisatie van en naar een andere database met een compleet ander datamodel wat wij ook niet hebben ontwikkeld.
En daar begint de pret: die andere database is grotendeels niet genormaliseerd. En in de bron database zijn heel veel records in bepaalde tabellen die door een probleem in de applicatie nergens aan gejoint kunnen worden. Zijn zeg maar zwevende records. (heeft dat een naam eigenlijk?).
Bijkomend probleem in de doel database: iemand vond het kennelijk geil om in text velden in XML formaat lijsten met selectie opties voor pulldown comboboxen te zetten... Nu is dat misschien een leuk spielerijtje en handig voor 5 items maar niet als er 70000 in moeten. Trrrraaaaaaggggg... Had het dan gewoon comma seperated erin gezet, denk ik dan. (hoewel het dan nog niet genormaliseerd is).
En daar komt normalisatie ook om de hoe kijken, grote gedeeltes van die lijsten moeten dubbel die database in... Dat valt dus niet te normaliseren...
Gevolg: 15x ruim 70000 keuze opties in XML formaat de database in. Triest, maar waar.

Los het maar op, is mijn opdracht. Mag ik effe janken?
Uiteraard al het één en ander geprobeerd om in beweging te brengen maar de leveranciers van de databases en applicaties waar wij op in moeten gaan haken geven niet thuis. Zijn niet van plan om de hele wereld rondom ons aan te passen.
Dat word dus om andersmans nukken heen werken. Wish me luck en een paar weken werk.
(er staat dan wel een maar die is gewoon bedoeld voor de database ontwikkelaar die zo nat word van XML. Het is wel een mooi project waar ik nu aan werk, maar dit soort geneuzel hoef ik echt niet bij elk project te hebben. Dan kan je me over een paar jaar in een gesticht stoppen.)

[ Voor 11% gewijzigd door remco_k op 15-07-2008 23:43 ]

[BikkelZ]

Ruudjah schreef op dinsdag 15 juli 2008 @ 20:59:
Om weer ontopic te gaan (discussie ging lichtelijk richting offtopic). Na dit topic weggeklikt te hebben (mijn dagelijkse GoT-tine) natuurlijk even de dagelijkse Atwood-tine. En hij heeft een prachtig verhaal geschreven: Maybe normalizing isnt normal.
Met name deze uitspraak is gepeperd en het waard om over te discusiieren:

[...]

Wat je hier ziet is een gevalletje premature optimalisatie. Als jouw social networking site 100.000 users heeft dan heb je het niet meer over een probleem, maar over een succes, ook al moet je bepaalde aanpassingen gaan doen in je database om eventuele performanceproblemen op te lossen. Als je dat allemaal van te voren gaat doen en een suboptimale bug gevoeligere opzet gaat doen van je database kom je misschien niet eens aan de 100.000 users in de eerste plaats, omdat de boel te vaak plat ligt of kuren heeft.

Overigens zijn goede joins helemaal niet zo duur, zeker niet in goed geschreven geprecompileerde stored procedures.

remco_k schreef op dinsdag 15 juli 2008 @ 23:37:Zijn zeg maar zwevende records. (heeft dat een naam eigenlijk?).

Ja.

Zwevende records.

Overigens bestaan 80% van de kosten die gemaakt worden in dat soort projecten in het oplossen van problemen die uit scenario's voort komen die volgens de oorspronkelijke ontwikkelaar 'toch nooit zouden voorkomen'.

[ Voor 7% gewijzigd door BikkelZ op 16-07-2008 14:08 ]

[remco_k]

BikkelZ schreef op woensdag 16 juli 2008 @ 14:06:
[...]
Ja.

Zwevende records.

Ow, haha... Zo zie je maar...

Overigens bestaan 80% van de kosten die gemaakt worden in dat soort projecten in het oplossen van problemen die uit scenario's voort komen die volgens de oorspronkelijke ontwikkelaar 'toch nooit zouden voorkomen'.

Dat is precies wat hier nu aan de hand is; ik ben al ver over de geoffereerde tijd heen, alleen maar bezig geweest met uitdokteren hoe ik om andermans problemen heen kan draaien. Zojuist een begin gemaakt aan het eindproduct...

[D-Raven]

Zo. ik was het hele topic alweer vergeten. Zie nu pas wat voor een reacties ik tussen EfBe en BikkelZ heb losgemaakt

Normaliseren. Ik doe het bijna eigenlijk altijd. Of beter gezegd, ik kom vaak op een genormaliseerd model uit. Beginnend bij een conceptueel model wordt er gekeken welke gegevens we willen opslaan, en wat we daarmee willen doen. Daar komt dan vanzelf een database model uit. Vaak leid dit tot een, niet helemaal uit genormaliseerde, representatie van de 2de NV.

Wat betreft het prefixen van kolommen. Sorry BikkelZ ik heb nog steeds geen argumenten gehoord welke er mij toe bewegen om het wel te gaan doen. . Alle technische voor en nadelen terzijde, uiteindelijk komt het aan op leesbaarheid en onderhoudbaarheid. Welke soms natuurlijk ook weer onderhevig is aan persoonlijke voorkeuren.

Ik werk dagelijks met grote database waarbij er ook 1 bijzit die dus wel prefixing gebruikt in combinatie met rare afkortingen. Tabel PSH_ProductStatusHistorie met kolom PSH_ID bijvoorbeeld. Als je dan een koppeltabel hebt ofzow, dan krijg je dus bijvoorbeeld RKT_RelatieKoppelTabel met kolom RKT_PSH_ID.... . Echt daar gaan mijn nekharen van overeind staan. Leesbaar? Begrijpbaar?

Kijk ik kan me voorstellen dat je in bovengenoemde voorbeeld in het geval van een foreign key zoiets heb van, ProductStatusHistorieId is mij te lang, ik noem dat ding ProductStatusId, of zoiets dergelijks. Afhankelijk van de situatie kan ik me daar nog enigszins in vinden. Maar kolom prefixing? bleeh :shivers:

[BikkelZ]

D-Raven schreef op woensdag 16 juli 2008 @ 16:35:
Ik werk dagelijks met grote database waarbij er ook 1 bijzit die dus wel prefixing gebruikt in combinatie met rare afkortingen. Tabel PSH_ProductStatusHistorie met kolom PSH_ID bijvoorbeeld. Als je dan een koppeltabel hebt ofzow, dan krijg je dus bijvoorbeeld RKT_RelatieKoppelTabel met kolom RKT_PSH_ID.... . Echt daar gaan mijn nekharen van overeind staan. Leesbaar? Begrijpbaar?

RKT_ProductStatusHistorieID zou ik in dat geval gebruiken. Ik kort nooit of te nimmer een variabelenaam af. Ik geloof dat ik zonder pardon variabele- of functienamen van 40 tot 60 karakters in zet (ik moet het eens natellen) als dat er voor zorgt dat de functie ondubbelzinnig en onafgekort omschreven is.

Overigens ben ik heel blij met jou als je een netjes genormaliseerde database gemaakt hebt zonder prefixing, uiteindelijk is zo'n prefix maar een detail.

[BikkelZ]

remco_k schreef op woensdag 16 juli 2008 @ 16:24:
[...]

Ow, haha... Zo zie je maar...

Volgens mij zijn het officieel 'orphaned records', bedacht ik me net.

remco_k schreef op woensdag 16 juli 2008 @ 16:24:
[...]

Dat is precies wat hier nu aan de hand is; ik ben al ver over de geoffereerde tijd heen, alleen maar bezig geweest met uitdokteren hoe ik om andermans problemen heen kan draaien. Zojuist een begin gemaakt aan het eindproduct...

Maar had je die database al gezien toen je die offerte opstelde?

[remco_k]

BikkelZ schreef op donderdag 17 juli 2008 @ 11:21:
[...]
Maar had je die database al gezien toen je die offerte opstelde?

Nee; dat niet.
Ook maak ik de offertes nooit (ik ben developer) maar doet de sales manager dat, nadat hij mij om advies heeft gevraagd met de nodige info. Ik maak dan een staatje met daarin o.a. een schatting van het aantal arbeidsuren.
Maar dat info inwinnen van de developer, in dit geval bij mij, is heel erg incompleet gegaan.
Die 2 databases waren toen niet voorhanden en ik heb daar ook m'n zorg over uitgesproken. 'Maar dat zal toch wel goed komen?'... Ja hoor, de vraag is alleen hoeveel tijd dat kost.
En zie hier... Een volledig in de soep gelopen offerte.
*Gelukkig* komt dit vrijwel nooit voor bij ons, want echt lekker werkt dit ook niet. Sterker nog, ik schijn behoorlijk nauwkeurig vooraf arbeidsuren te kunnen inschatten. Voor de kleinere projecten (1 tot 3 werkdagen) lukt het me soms zelfs op het uur af.

[Janoz]

Modbreak:

Ik heb even een deel van de discussie afgesplitst naar Beloning developers en hun leidinggevenden

[berendhaan]

Soms ik normaliseren gewoon niet praktisch. Vooral als je kleine databasesjes hebt met maar 4 tabellen ofzo.

Meestal als ik een database opzet zo uit het niets is het meestal al genormaliseerd zonder dat ik er erg in heb.

[Creepy]

Soms is normaliseren niet praktisch omdat het maar om een paar tabellen gaat? Kan je dat eens verder uitleggen want ik kan me er niks bij voorstellen. Een DB groeit vaak en normaliseren is altijd praktisch omdat het je een hoop gezeik met queries en vaak ook performance scheelt

[BikkelZ]

Er is natuurlijk ook nog de nuance dat sommige mensen het leggen van foreign key constraints niet onder normaliseren verstaan. Met name uit de MySQL hoek werd dit van oudsher niet gedaan (omdat dat lang ook niet mogelijk was).

[Johnny]

Ik heb onlangs nog een database ontworpen voor een interactieve website bestaande uit 23 tabellen en heb op diverse plaatsen gezondigd.

De eerste overtreding van het normalisatie is een extra kolom met daarin een foreign key in een tabel die waarschijnlijk heel snel heel groot zal groeien. De foreign key is ook te achterhalen is via een andere tabel, maar dat bespaart dan weer een extra join in enkele tientallen verschillende queries.

Iets anders wat in de praktijk goed blijkt te werken is het gebruik van meerdere tags (sleutelwoorden) in een enkel tekstveld. In een goed genormaliseerde database zouden die doormiddel van een koppeltabel worden gelinkt aan de content op waar ze van toepassing zijn. In de praktijk is het veel makkelijker om een FULLTEXT index de tags en op de tags, titel, en content te zetten om zo makkelijk te kunnen zoeken in de tags of de hele tabel.

Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Een andere plaats waar niet helemaal genormaliseerd is, is bij facturen en betalingsinformatie. Per factuur worden alle gegevens zoals die op dat moment zijn opgeslagen omdat die niet achteraf mogen worden aangepast. In een perfect genormaliseerde database zou je een extra tabel hebben met klantenadressen en wijzigingsdatums die je dan koppelt aan facturen, maar dat maakt het naar mijn inzien alleen maar onnodig complex.

Ook geldbedragen worden op diverse plaatsen dubbel opgeslagen. Het zou genoeg zijn om het subtotaal en het BTW-tarief op te slaan om zo het totaal te berekenen, maar doordat je die op verschillende manieren kan afronden is het in de slim om de uitkomst ook op te slaan in de database zodat daar in de toekomst geen verwarring over kan onstaan.

Ook zijn er enkele tabellen die gevuld worden door externe processen die informatie dubbel hebben en zelfs serialized data bevatten zodat er in de toekomst wellicht meer informatie aan kan worden onttrokken. Ook is het handig om een kopie te hebben van de exacte gegevens die werden toegestuurd mocht er ooit iets mis gaan met de verwerking daarvan, bij het debuggen is het ook handig.

[BikkelZ]

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Ik heb onlangs nog een database ontworpen voor een interactieve website bestaande uit 23 tabellen en heb op diverse plaatsen gezondigd.

De eerste overtreding van het normalisatie is een extra kolom met daarin een foreign key in een tabel die waarschijnlijk heel snel heel groot zal groeien. De foreign key is ook te achterhalen is via een andere tabel, maar dat bespaart dan weer een extra join in enkele tientallen verschillende queries.

Heb je dat ook daadwerkelijk getest of is dit een aanname? (Het is me overigens niet helemaal duidelijk wat je bedoelt)

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Iets anders wat in de praktijk goed blijkt te werken is het gebruik van meerdere tags (sleutelwoorden) in een enkel tekstveld. In een goed genormaliseerde database zouden die doormiddel van een koppeltabel worden gelinkt aan de content op waar ze van toepassing zijn. In de praktijk is het veel makkelijker om een FULLTEXT index de tags en op de tags, titel, en content te zetten om zo makkelijk te kunnen zoeken in de tags of de hele tabel.

Wat zei ik net nou nog over MySQL developers?

Ik geloof niet dat er veel databases zijn die MySQL kunnen kloppen wat FULLTEXT betreft. En FULLTEXT zelf is al een soort van geindexeerd als ik me niet vergis.

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Maar zijn die queries doordat ze 'simpeler' zijn nu ook beter te onderhouden? Volgens mij moet je meer regels documentatie toevoegen dan je van het aantal regels in een query afscheert.

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Een andere plaats waar niet helemaal genormaliseerd is, is bij facturen en betalingsinformatie. Per factuur worden alle gegevens zoals die op dat moment zijn opgeslagen omdat die niet achteraf mogen worden aangepast. In een perfect genormaliseerde database zou je een extra tabel hebben met klantenadressen en wijzigingsdatums die je dan koppelt aan facturen, maar dat maakt het naar mijn inzien alleen maar onnodig complex.

Ook geldbedragen worden op diverse plaatsen dubbel opgeslagen. Het zou genoeg zijn om het subtotaal en het BTW-tarief op te slaan om zo het totaal te berekenen, maar doordat je die op verschillende manieren kan afronden is het in de slim om de uitkomst ook op te slaan in de database zodat daar in de toekomst geen verwarring over kan onstaan.

Dit werd op de HvU dan ook aangedragen als hét voorbeeld van wanneer blind normaliseren niet gewenst was. Een instinkertje voor het tentamen! Je maakt een factuurregel aan, die gekoppeld is aan een productregel en eigenlijk alle informatie dupliceert.

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
Ook zijn er enkele tabellen die gevuld worden door externe processen die informatie dubbel hebben en zelfs serialized data bevatten zodat er in de toekomst wellicht meer informatie aan kan worden onttrokken. Ook is het handig om een kopie te hebben van de exacte gegevens die werden toegestuurd mocht er ooit iets mis gaan met de verwerking daarvan, bij het debuggen is het ook handig.

Ja maar die informatie gebruik je niet actief in je 'informatiesysteem' als ik het zo mag uitdrukken, dat is toch gewoon een soort logfile?

[Johnny]

BikkelZ schreef op vrijdag 18 juli 2008 @ 09:40:

Heb je dat ook daadwerkelijk getest of is dit een aanname? (Het is me overigens niet helemaal duidelijk wat je bedoelt)

Het komt er op neer dat je in plaats van 2 joins nu maar 1 join nodig hebt in bepaalde gevallen. En het is makkelijk bij het bekijken van de tabel zelf omdat je meteen kan zien welk record waar bij hoort. Het maakt weinig verschil in performance, en de keys in kwestie zullen toch niet veranderen, ze worden enkel aangemaakt of verwijderd.

Wat zei ik net nou nog over MySQL developers?

Ik geloof niet dat er veel databases zijn die MySQL kunnen kloppen wat FULLTEXT betreft. En FULLTEXT zelf is al een soort van geindexeerd als ik me niet vergis.

FULLTEXT is inderdaad een speciaal soort index. In het verleden heb ik deze aanpak, net zoals een wel genormaliseerde variant ook gebruikt. De genormaliseerde manier vereist dat gebruikte tags ook in je tabel met beschikbare tags staan terwijl je dat in de praktijk niet altijd wil, daarnaat heb je enorme hoeveelheden code nodig om geavanceerde selecties te maken van bepaalde tags terwijl je met FULLTEXT de database het allemaal kan laten afhandelen omdat die boolean operators ondersteunt bij het zoeken.

Maar zijn die queries doordat ze 'simpeler' zijn nu ook beter te onderhouden? Volgens mij moet je meer regels documentatie toevoegen dan je van het aantal regels in een query afscheert.

De data in kwestie worden enkel gebruikt in een datamodel dat wordt samengesteld uit 4 verschillende tabellen, er is een enkele klasse die de data uit de database of file-cache haalt en omzet naar het datamodel. Het aanpassen van de booleans vereist dus enkel het toevoegen van een property aan de functie die de booleans vertaalt naar properties en andersom, de queries hoeven daarvoor niet te worden gewijzigd.

Dit werd op de HvU dan ook aangedragen als hét voorbeeld van wanneer blind normaliseren niet gewenst was. Een instinkertje voor het tentamen! Je maakt een factuurregel aan, die gekoppeld is aan een productregel en eigenlijk alle informatie dupliceert.

[...]

Ja maar die informatie gebruik je niet actief in je 'informatiesysteem' als ik het zo mag uitdrukken, dat is toch gewoon een soort logfile?

Het is inderdaad een soort logfile, maar daar is toch niks mis mee? Beheerders kunnen via het CMS de gegevens inzien om te controleren wat er is binnengekomen, en de data kan ook gebruikt worden om andere data opnieuw te genereren. Allerlei logfiles gaan doorspitten is een stuk lastiger omdat je die niet zo makkelijk kan sorteren en filteren.

[Anoniem: 140111]

Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Een dergelijke 'overtreding' is men hier ook begaan.
Ik kan er 1 ding over zeggen: DOE HET NIET.

Dit pakket draait nu al een flinke poos en is in de loop der jaren door VELE mensen onderhouden en er valt gewoon niet meer vanaf te komen. Begrijpelijk is het al helemaal niet. En de reden die jij aanvoert om het te rechtvaardigen voor jezelf is al helemaal geen goede, pure gemakzucht ten koste van je overzichtelijkheid en onderhoudbaarheid.

[ Voor 27% gewijzigd door Anoniem: 140111 op 18-07-2008 14:52 ]

[Anoniem: 49627]

ik kan het alleen maar eens zijn met wat worteltaart al gezegd heeft. Daarnaast snap ik de keuze voor een TINYINT al helemaal niet. Het argument is 'makkelijk uitbreidbaar' maar de keuze dan juist een beperking. Wat is er dan mis met een 32bits getal, dan heb je tenminste nog de ruimte...

[BikkelZ]

Wat is eigenlijk het probleem met JOINs? Mensen lijken er een soort natuurlijk afkeer van te hebben vaak die ik niet zo goed kan plaatsen.

Johnny schreef op vrijdag 18 juli 2008 @ 12:51:
[...]

De data in kwestie worden enkel gebruikt in een datamodel dat wordt samengesteld uit 4 verschillende tabellen, er is een enkele klasse die de data uit de database of file-cache haalt en omzet naar het datamodel. Het aanpassen van de booleans vereist dus enkel het toevoegen van een property aan de functie die de booleans vertaalt naar properties en andersom, de queries hoeven daarvoor niet te worden gewijzigd.

Ja maar dan zit er dus bullshit-data in je database die je niet kunt verklaren zonder de applicatie er boven. Komt er een tweede applicatie die daar gebruik van gaat maken moet die dat zelfde stuk code gaan bevatten. En wijzig je iets in applicatie 1 gaat applicatie 2 natuurlijk niet vanzelf mee.

Daarom moet je de database verantwoordelijk maken voor dat soort zaken (en maakte ik ook niet zo'n probleem over het FULLTEXT verhaal, want dan blijft het wel bij de database). Zo'n Unix-security bits achtige oplossing is vooral geeky en totaal niet nuttig.

Of moet de database ook op een 5 1/4" diskette passen?

Johnny schreef op vrijdag 18 juli 2008 @ 12:51:
[...]

Het is inderdaad een soort logfile, maar daar is toch niks mis mee? Beheerders kunnen via het CMS de gegevens inzien om te controleren wat er is binnengekomen, en de data kan ook gebruikt worden om andere data opnieuw te genereren. Allerlei logfiles gaan doorspitten is een stuk lastiger omdat je die niet zo makkelijk kan sorteren en filteren.

Nee exact maar dan zijn het gegevens die toevallig ook in een database staan, en hoort het niet bij je daadwerkelijke gegevensmodel.

Gebruik je wel foreign keys en dat soort constraints om integriteit ook af te dwingen in het deel wat daar wel bij hoort? Met InnoDB ging dat wel prima eigenlijk.

[LauPro]

BikkelZ schreef op vrijdag 18 juli 2008 @ 16:20:
Daarom moet je de database verantwoordelijk maken voor dat soort zaken (en maakte ik ook niet zo'n probleem over het FULLTEXT verhaal, want dan blijft het wel bij de database). Zo'n Unix-security bits achtige oplossing is vooral geeky en totaal niet nuttig.

Er bestaat zo'n mooi lijstje van 'a database is not a calculator' etc. Allemaal stuk voor stuk nuttige tips die je zeker moet toepassen.

Toch typeren veel projecten zich als een lekkende kraan. Dat is prettig omdat het werk genereert. In mijn ogen is dan ook het leveren van een superieure oplossing de doodsteek voor elk softwarehuis.

De keuze tussen wel/niet normaliseren is gewoon een geldkwestie. Een opdrachtgever zal nooit vragen om te normaliseren, het is iets wat je als developer zelf moet inschatten en moet kunnen verantwoorden. En wat dat betreft is uitgaande van een ongenormaliseerde situatie normaliseren duur:
- structurele aanpassing (informeren DBA etc);
- terugwaardse compatibiliteit met back-up gaat verloren;
- er moet worden geconverteerd;
- aanpassingen in software (DBL).

Neemt niet weg dat de performance en consistentie van een ongenormaliseerde database op een gegeven moment dermate rampzalig kan zijn waardoor de situatie onwerkbaar wordt.

[remco_k]

LauPro schreef op zaterdag 19 juli 2008 @ 01:03:
[...]
Er bestaat zo'n mooi lijstje van 'a database is not a calculator' etc. Allemaal stuk voor stuk nuttige tips die je zeker moet toepassen.

Toch typeren veel projecten zich als een lekkende kraan. Dat is prettig omdat het werk genereert. In mijn ogen is dan ook het leveren van een superieure oplossing de doodsteek voor elk softwarehuis.

De keuze tussen wel/niet normaliseren is gewoon een geldkwestie. Een opdrachtgever zal nooit vragen om te normaliseren, het is iets wat je als developer zelf moet inschatten en moet kunnen verantwoorden. En wat dat betreft is uitgaande van een ongenormaliseerde situatie normaliseren duur:
- structurele aanpassing (informeren DBA etc);
- terugwaardse compatibiliteit met back-up gaat verloren;
- er moet worden geconverteerd;
- aanpassingen in software (DBL).

Neemt niet weg dat de performance en consistentie van een ongenormaliseerde database op een gegeven moment dermate rampzalig (kan) zijn waardoor de situatie onwerkbaar wordt.

Hier kan ik het volledig mee eens zijn. Het feit dat de opdracht gever nooit om normaliseren op zich vraagt, komt denk ik eerder omdat ze niet eens weten dat het bestaat. Wel komt de opdrachtgever met de 'wil je dit optimaliseren' vraag en daar heeft hij dan 2 doelen bij:
1. Snelheid
2. De grootte van de database beperken, wat an sich ook weer snelheidswinst kan opleveren.
Wat mij betreft is normaliseren dan één van de dingen die moet gebeuren, maar het is wel de meest ingrijpende verandering.

Als je een database niet (goed) normaliseerd, dan is het vaak te laat om dat wel te doen op het moment dat je merkt dat de performance, consistentie of schijfruimte problemen op gaat leveren.
1 van de projecten waar ik regelmatig mee in aanraking kom betreft een database met een filesize van >35 GB (ja, met de G en nee er zitten geen blobs en grote textvelden in, alleen 'pure data' van ints en chars[255] en een enkele van >255). *Gelukkig* is daar alles genormaliseerd, anders zou deze database wellicht 2x zo groot zijn. Ik ben als trotse 'vader' bij de geboorte van die database geweest.
Dat wil niet zeggen dat alles perfect is aan die database overigens.

[Ruudjah]

Voor versiebeheer heb ik ook gezondigd. Maar de vraag is of dat zondigen is; ik ben er nog niet echt over uit. Wat er gebeurd is dat we data op in een XML bestand opslaan. Bij een wijziging van die data wordt er simpelweg een nieuw bestand opgeslagen met hierin alle data gekopieerd (behalve natuurlijk de wijzigingen). Omdat in de definitie van het XML bestand ook data staat die read-only is en dus nooit gewijzigd wordt, is bij elke save van de gebruiker die data redundant gepersisteerd. In principe is dat een overtreding van normaliseren: nooit data dubbel opslaan als dit niet nodig is. Maar het model is simpel en makkelijk om mee te ontwikkelen. Verder hebben we nu als voordeel dat als, om wat voor reden dan ook de oudere versies niet meer aanwezig zijn, de (redundante read-only) data nog wel beschikbaar is.
Ik vind het een pragmatische oplossing die voor ons werkt. Ook al overtreedt ik dan de normalisatieregels met voeten.

En Hongaarse notatie: waarom moet er legacy onderwezen worden?

Ik heb ook geen idee wat de hongaarse notatie precies inhoudt. Het gaat mij erom dat in ieder geval een notatie bekend is voor de studenten. Dat is er vaak nog niet eens. Of je nu de Hongaarse, Zwitserse, West-Australische of Noord-Japanse pakt interreseert me niet zoveel.

[ Voor 15% gewijzigd door Ruudjah op 20-07-2008 19:40 ]

[whoami]

Ruudjah schreef op zondag 20 juli 2008 @ 19:37:
Voor versiebeheer heb ik ook gezondigd. Maar de vraag is of dat zondigen is; ik ben er nog niet echt over uit. Wat er gebeurd is dat we data op in een XML bestand opslaan. Bij een wijziging van die data wordt er simpelweg een nieuw bestand opgeslagen met hierin alle data gekopieerd (behalve natuurlijk de wijzigingen). Omdat in de definitie van het XML bestand ook data staat die read-only is en dus nooit gewijzigd wordt, is bij elke save van de gebruiker die data redundant gepersisteerd. In principe is dat een overtreding van normaliseren: nooit data dubbel opslaan als dit niet nodig is. Maar het model is simpel en makkelijk om mee te ontwikkelen. Verder hebben we nu als voordeel dat als, om wat voor reden dan ook de oudere versies niet meer aanwezig zijn, de (redundante read-only) data nog wel beschikbaar is.
Ik vind het een pragmatische oplossing die voor ons werkt. Ook al overtreedt ik dan de normalisatieregels met voeten.

Jij noemt een XML bestand een databank ?

Ruudjah schreef op dinsdag 15 juli 2008 @ 20:59:
Om weer ontopic te gaan (discussie ging lichtelijk richting offtopic). Na dit topic weggeklikt te hebben (mijn dagelijkse GoT-tine) natuurlijk even de dagelijkse Atwood-tine. En hij heeft een prachtig verhaal geschreven: Maybe normalizing isnt normal.
Met name deze uitspraak is gepeperd en het waard om over te discusiieren:

[...]

Hmm .... Een datamodel waar over nagedacht is, en dat genormaliseerd is, en later gedenormaliseerd waar nodig, zorgt voor een goede, solide basis. Een basis die je garanties kan bieden over de correctheid van de data, en die voor een goede basis performance kan zorgen.

Ik heb ook geen idee wat de hongaarse notatie precies inhoudt. Het gaat mij erom dat in ieder geval een notatie bekend is voor de studenten. Dat is er vaak nog niet eens. Of je nu de Hongaarse, Zwitserse, West-Australische of Noord-Japanse pakt interreseert me niet zoveel.

Als programmeur moet de term 'hongaarse notatie' toch wel een belletje doen rinkelen. Je moet toch min of meer weten wat hiermee bedoeld wordt; echter, dat betekent niet dat je 't moet gebruiken. Ik heb er zelf een hekel aan.
klik

D-Raven schreef op woensdag 16 juli 2008 @ 16:35:

Wat betreft het prefixen van kolommen. Sorry BikkelZ ik heb nog steeds geen argumenten gehoord welke er mij toe bewegen om het wel te gaan doen. . Alle technische voor en nadelen terzijde, uiteindelijk komt het aan op leesbaarheid en onderhoudbaarheid. Welke soms natuurlijk ook weer onderhevig is aan persoonlijke voorkeuren.

Tja, naming guidelines zijn subjectief. Iedereen heeft daar zijn eigen 'best practices', en iedereen vind dan weer iets anders lekkerder werken.
Mijn boodschap is: werk je voor een bedrijf, en ze hebben daar guidelines, dan volg je die.
Werk je aan hobby projectjes, etc... of werk je voor een bedrijf waar ze geen guidelines hebben, stel dan je eigen guidelines samen en volg die, en wees consequent.

berendhaan schreef op donderdag 17 juli 2008 @ 20:38:
Soms ik normaliseren gewoon niet praktisch. Vooral als je kleine databasesjes hebt met maar 4 tabellen ofzo.

Meestal als ik een database opzet zo uit het niets is het meestal al genormaliseerd zonder dat ik er erg in heb.

Geef hier eens wat meer uitleg over ? Waarom zou het in dat geval niet nodig zijn om te normaliseren ? Waarom zou je in dergelijke gevallen wel gedupliceerde data toelaten bv ?

Trouwens, meestal ga je eerst normaliseren en ga nadien pas zien hoeveel tabellen je zult hebben
(Al is het natuurlijk wel zo dat je bij kleine projecten meestal wel al zo op het zicht kunt zien welke en hoeveel tabellen je zult hebben).

Johnny schreef op donderdag 17 juli 2008 @ 21:31:
De eerste overtreding van het normalisatie is een extra kolom met daarin een foreign key in een tabel die waarschijnlijk heel snel heel groot zal groeien. De foreign key is ook te achterhalen is via een andere tabel, maar dat bespaart dan weer een extra join in enkele tientallen verschillende queries.

Alsof een JOIN zo duur is .... Nuja, meer kan ik er natuurlijk niet over zeggen want ik zie de situatie niet voor me.

Iets anders wat in de praktijk goed blijkt te werken is het gebruik van meerdere tags (sleutelwoorden) in een enkel tekstveld. In een goed genormaliseerde database zouden die doormiddel van een koppeltabel worden gelinkt aan de content op waar ze van toepassing zijn. In de praktijk is het veel makkelijker om een FULLTEXT index de tags en op de tags, titel, en content te zetten om zo makkelijk te kunnen zoeken in de tags of de hele tabel.

En wat als je een tag wilt verwijderen ? Of wat als je een tag een andere naam wilt geven, en die tag wordt door meerdere teksten gebruikt ?
Kan je mij eens uitleggen wat het voordeel is van een dergelijke, ranzige shortcut tov het gewoon te doen zoals het zou moeten ?

Een andere overtreding is het misbruiken van een TINYINT om tot op 8 booleans op te slaan die niet hoeven te worden doorzocht. Het is niet heel erg overzichtelijk en levert ook weinig snelheidswinst op maar het is wel makkelijk omdat je simpelere queries hebt en makkelijk meerdere waardes kan toevoegen zonder steeds extra kolommen toe te voegen.

Waarom heb je die bools nodig als ze niet hoeven doorzocht te worden ?
Nu is het misschien makkelijk, maar wat na 4 jaar bv ? Zal jij nog weten wat die tinyint juist is, en wat de betekenis is van iedere bool op iedere positie ?
Of, wat als iemand anders die DB in z'n pollen geschoven krijgt om 'm verder te onderhouden, te ontwikkelen ?
Ik heb onlangs op m'n werk ook een legacy DB herbouwd die ook dergelijke truken gebruikte; wel, ik kan je zeggen. Er was niemand die nog precies wist hoe die legacy DB in elkaar zat.

Een andere plaats waar niet helemaal genormaliseerd is, is bij facturen en betalingsinformatie. Per factuur worden alle gegevens zoals die op dat moment zijn opgeslagen omdat die niet achteraf mogen worden aangepast. In een perfect genormaliseerde database zou je een extra tabel hebben met klantenadressen en wijzigingsdatums die je dan koppelt aan facturen, maar dat maakt het naar mijn inzien alleen maar onnodig complex.

Hier ben ik het met je eens.

Kijk, een 'stielman' moet zich, bij het uitoefenen van z'n beroep houden aan 'de regels van de kunst', en er wordt ook van hem verwacht dat hij die regels kent en toepast. Als hij bv een huis bouwt, en de bouwheer / klant heeft een probleem, en de oorzaak van dat probleem heeft te maken met het werk dat die stielman heeft uitgevoerd, wel, dan heeft die beste man een probleem als blijkt dat zijn werk niet 'volgens de regels van de kunst' is uitgevoerd.
Wel, als ik dergelijke dingen hier lees, dan ben ik een zeer zwaar voorstander om dergelijke 'regels' ook op te leggen aan software-ontwikkelaars.

/reply-combo.

[ Voor 70% gewijzigd door whoami op 20-07-2008 20:05 ]

[Ruudjah]

Jij noemt een XML bestand een databank?

Ja, natuurlijk. Ook een XML structuur moet je in den beginne normaliseren. Een XML definitie is ook gewoon een datamodel, net als een datamodel op een database server.

[whoami]

Ruudjah schreef op zondag 20 juli 2008 @ 19:57:
[...]

Ja, natuurlijk. Ook een XML structuur moet je in den beginne normaliseren. Een XML definitie is ook gewoon een datamodel, net als een datamodel op een database server.

Nee, natuurlijk niet.
Een XML bestand bevat niet noodzakelijk 'gestructureerde informatie'.
Met een XML bestand kan je niet garanderen dat je operaties (opslaan / wijzigen) atomair zijn
etc...

om dan nog maar over de performance te zwijgen.

[Ruudjah]

Met een XML bestand kan je niet garanderen dat je operaties (opslaan / wijzigen) atomair zijn
etc...

om dan nog maar over de performance te zwijgen.

Dan nog blijft het een datamodel. Ik zie niet in hoe de door jouw genoemde punten het opeens géén datamodel meer is?

[whoami]

Ik heb niet gezegd 'een datamodel', ik heb gezegd 'een databank', want dat is wat je nu toch doet ?
Je misbruikt een xml bestand om het te gebruiken als databank.

[Ruudjah]

Databank, datamodel. mjah. Een XML definitie vind ik wel degelijk een datamodel. Afhankelijk van je definitie is [zijn de instanties van de XML definitie] het ook een databank.
Overigens misbruik ik helemaal niets.

[ Voor 9% gewijzigd door Ruudjah op 20-07-2008 21:23 ]

[Johnny]

whoami schreef op zondag 20 juli 2008 @ 19:46:
[...]
Alsof een JOIN zo duur is .... Nuja, meer kan ik er natuurlijk niet over zeggen want ik zie de situatie niet voor me.

Alsof een extra kolom zo duur is... Hij is technisch gesproken dubbelop, maar deze foreign key is ook meteen een unique identifier die overal zichbaar, en daardoor ook herkenbaar is. Het is meteen duidelijk voor iedereen waar een bepaald record bij hoort.

En wat als je een tag wilt verwijderen ? Of wat als je een tag een andere naam wilt geven, en die tag wordt door meerdere teksten gebruikt ?
Kan je mij eens uitleggen wat het voordeel is van een dergelijke, ranzige shortcut tov het gewoon te doen zoals het zou moeten ?

Zoals ik al eerder heb uitgelegd kan je op deze manier gebruikmaken van FULLTEXT zoekmogelijkheden waardoor het voor de gebruiker heel makkelijk is om gevavanceerde selecties te maken bestaande uit meerdere tags, inclusief operators zoals AND, OR en NOT zonder dat je daar veel extra code voor nodig hebt.

Een tag een andere naam geven komt in de praktijk vrijwel nooit voor, ik gebruik deze methode al 2 jaar voor diverse websites en heb in die tijd één keer een tag moeten vervangen omdat die verkeerd bleek te zijn ingevoerd, en dat kan met een simpele REPLACE query.

Een tag verwijderen is ook niet problematisch, je kan er dan voor kiezen om hem uit de tabel van beschikbare tags te gooien en dan verschijnt hij niet meer op de pagina's waar de beschikbare tags staan en kan hij niet meer worden toegevoegd. Meestal kan hij wel gewoon bij bestaande content blijven staan, en zelfs al is dat niet geval dan is het ook weer met een eenmalige query op te lossen.

De genormaliseerde manier gebruikte ik voordat ik met deze methode begon, en nog steeds in oudere systemen en die is minder flexibel en vereist veel meer code en heeft alsnog minder mogelijkheden.

Het is voor mij de ideale manier om content te voorzien van tags omdat je mensen laat kiezen uit een aantal vooraf bepaalde woorden zodat ze geen rare dingen zelf gaan verzinnen maar tegelijkertijd flexibel genoeg bent om toch nog andere tags kan voegen en gebruik kan maken van de faciliteiten van de database.

Waarom heb je die bools nodig als ze niet hoeven doorzocht te worden ?
Nu is het misschien makkelijk, maar wat na 4 jaar bv ? Zal jij nog weten wat die tinyint juist is, en wat de betekenis is van iedere bool op iedere positie ?
Of, wat als iemand anders die DB in z'n pollen geschoven krijgt om 'm verder te onderhouden, te ontwikkelen ?
Ik heb onlangs op m'n werk ook een legacy DB herbouwd die ook dergelijke truken gebruikte; wel, ik kan je zeggen. Er was niemand die nog precies wist hoe die legacy DB in elkaar zat.

Het gaat hier om een aantal booleans die de manier waarop invoervelden worden weergegeven bepalen, niet een criterium waar je zou willen zoeken (wat overginds wel mogelijk is met een bitmask), zelf als ze niet aanwezig zijn blijft het systeem werken, maar dan met de standaardweergave. De betekenis zou je ook simpel kunnen vastleggen als comment bij de kolomnaam.

Desondanks heb ik de TINYINT nu vervangen door een aantal losse BIT(1) kolommen wat ook een redelijk efficiente manier is om meerdere booleans op te slaan.

[Anoniem: 141965]

Heel vaak kom ik tegen dat men, het lijkt bijna een gemeengoed te zijn, een surrogate key tooevoegd om een rij in de tabel uniek te maken binnen de tabel. Veel mensen doen dit standaard, ook wanneer er gewoon een primary key is zoals het klantnummer in een klanttabel (even ervan uitgaande dat de klantnummers van ex-klanten niet opnieuw uitgegeven worden). Hoe staan jullie hier tegen over?

Wanneer er dan geen unieke key op basis van een kolom is te vinden dan kun je vaak nog wel een samengestelde key vinden zoals het factuurnummer + factuurregelnummer. In een factuurdetail tabel. Kiezen jullie in deze gevallen dan liever voor een surrogate key?

[whoami]

Anoniem: 141965 schreef op dinsdag 19 augustus 2008 @ 15:41:
Heel vaak kom ik tegen dat men, het lijkt bijna een gemeengoed te zijn, een surrogate key tooevoegd om een rij in de tabel uniek te maken binnen de tabel. Veel mensen doen dit standaard, ook wanneer er gewoon een primary key is zoals het klantnummer in een klanttabel (even ervan uitgaande dat de klantnummers van ex-klanten niet opnieuw uitgegeven worden). Hoe staan jullie hier tegen over?

Ik ben voor surrogate keys.
Waarom :
- gegarandeerd uniek
- gegarandeerd onveranderlijk, het stelt nl. geen 'business gegeven' voor dat per definitie zou kunnen wijzigen.
- primary keys zullen dan ook nooit composite keys zijn, waardoor je foreign keys ook simpel blijven
- het maakt het leven makkelijker als je een O/R mapper al NHibernate gebruikt.

Wanneer er dan geen unieke key op basis van een kolom is te vinden dan kun je vaak nog wel een samengestelde key vinden zoals het factuurnummer + factuurregelnummer. In een factuurdetail tabel. Kiezen jullie in deze gevallen dan liever voor een surrogate key?

Ja dus.

Wat is het doel van een primary key ? Gewoon een stukje 'administratie' voor het DBMS om een rij uniek te kunnen identificeren.
Laat ik de vraag eens omdraaien: waarom zou je voor een natural key kiezen ?

[joppybt]

whoami schreef op dinsdag 19 augustus 2008 @ 15:48:
Laat ik de vraag eens omdraaien: waarom zou je voor een natural key kiezen ?

• Je hebt geen extra kolom nodig
• Je hebt geen extra index nodig
• (Oracle) je hebt geen extra sequence nodig
• (Oracle) je hebt geen extra trigger nodig om die sequence in de primary key te zetten

Ofwel: je haalt je met surrogate keys wel wat overhead op de hals. Je zult moeten afwegen of dat tegen de voordelen opweegt.

[mOrPhie]

Ik denk dat die overhead wel meevalt. Ik herken de surrogate key of de identity-column van MS SQL Server niet als performance-bottleneck eigenlijk. Nog nooit heb ik iemand horen zeggen: "die identity-columns zijn met toch een doorn in het oog zeg, wat zijn die traag".

Ik vind het gevaarlijk om datalogica af te laten hangen van iets wat businesslogica zou kunnen zijn. Iemand zou zomaar de business-rules kunnen wijzigen. Een klantnummer kan nu bijvoorbeeld heel goed numeric zijn, maar als je opdrachtgever morgen bedenkt dat het klantnummer wordt aangevuld met een letter, dan hang je. En dan kun je op je kop gaan staan, die letter komt er toch wel, maar jouw gehele applicatie staat vol met selecties op tabellen waarbij uit wordt gegaan van integers.

Nog een voorbeeld: stel dat die klantnummers (in dit geval, zou ook een andere unieke waarde kunnen zijn) worden gezien als belangrijke persoonsgegevens die niet zomaar publiek mag worden, maar je moet wel een soort extranet-site maken waarin sommige informatie te zien is. Waarop ga je op dat moment je selectie baseren? De unieke waarde is geen onderdeel van de publieke informatie en mag dus niet in de URL staan, of als POST informatie over de lijn heen gaan. Het is wat cryptisch, maar een dergelijk scenario heb ik zelf meegemaakt.

De enige keren dat ik niet voor een extra kolom zou kiezen is bij koppeltabellen. Maar zelfs daar vind ik het administratief gezien geen overdaad om een extra identiteit aan de tabel te hangen.

[Anoniem: 140111]

De enige keren dat ik niet voor een extra kolom zou kiezen is bij koppeltabellen. Maar zelfs daar vind ik het administratief gezien geen overdaad om een extra identiteit aan de tabel te hangen.

Ik ben het eens met je mening en gebruik zelf ook altijd een primary key die totaal niets met de business logica te maken heeft, maar waarom zou je in koppeltabellen nog een extra key toevoegen?

[Orphix]

Anoniem: 140111 schreef op dinsdag 19 augustus 2008 @ 18:10:
Ik ben het eens met je mening en gebruik zelf ook altijd een primary key die totaal niets met de business logica te maken heeft, maar waarom zou je in koppeltabellen nog een extra key toevoegen?

Omdat het werken met primary keys over meerdere velden (zoals bij keys) in je programmatuur lastiger is. Het is gewoon eenvoudiger om consistent overal een Id aan te hangen en dat je altijd op id==localId kunt zoeken, filteren, etc. Ipv altijd where veld1=.. && veld2=.. Tuurlijk, het is geen harde noodzaak maar het brengt in mijn ervaring wel veel gemak met zich mee.

[mOrPhie]

Anoniem: 140111 schreef op dinsdag 19 augustus 2008 @ 18:10:
[...]

Ik ben het eens met je mening en gebruik zelf ook altijd een primary key die totaal niets met de business logica te maken heeft, maar waarom zou je in koppeltabellen nog een extra key toevoegen?

Soms heb je een view vanuit de koppeling. Bijvoorbeeld een zakelijke relatie (linkedin oid, ik noem maar wat). Je hebt twee partijen (bedrijven of mensen), maar ook bijvoorbeeld hoe de relatie tot stand kwam, wanneer, opmerkingen, enz. Het is nog altijd een koppeltabel, maar je bekijkt het vannuit de koppeling zelf. In dergelijke gevallen kan het gewenst zijn de koppeling met een enkel id te selecteren.

[Janoz]

Het voorbeeld van MorPhie lijkt exotisch en is misschien daarom lastig voor te stellen:

mOrPhie schreef op dinsdag 19 augustus 2008 @ 16:50:
Ik vind het gevaarlijk om datalogica af te laten hangen van iets wat businesslogica zou kunnen zijn. Iemand zou zomaar de business-rules kunnen wijzigen. Een klantnummer kan nu bijvoorbeeld heel goed numeric zijn, maar als je opdrachtgever morgen bedenkt dat het klantnummer wordt aangevuld met een letter, dan hang je. En dan kun je op je kop gaan staan, die letter komt er toch wel, maar jouw gehele applicatie staat vol met selecties op tabellen waarbij uit wordt gegaan van integers.

Maar denk bijvoorbeeld eens aan fusies? De klanten administratie systemen van Casema, Multikabel en @Home die nu allemaal gemerged moeten worden. @Home had uberhaupt al moeite om hun tv kabel klanten bestand te kunnen koppelen aan het internet klanten bestand.

[Voutloos]

De mensen uit het 'surrogate keys zijn nergens voor nodig'-kamp hechten gewoon veel te veel waarde aan de letterlijke inhoud van een primary key. Maar of die synthetische key 42 of 1337 is moet nergens boeien, en extern hoeft het uberhaupt niet zichtbaar te zijn of waarde te hebben.

[Anoniem: 141965]

Voutloos schreef op woensdag 20 augustus 2008 @ 14:44:
De mensen uit het 'surrogate keys zijn nergens voor nodig'-kamp hechten gewoon veel te veel waarde aan de letterlijke inhoud van een primary key. Maar of die synthetische key 42 of 1337 is moet nergens boeien, en extern hoeft het uberhaupt niet zichtbaar te zijn of waarde te hebben.

Ik vind het ook wel gewoon lekker makkelijk hoor om een surrogate key te gebruiken maar de overweging ja/nee blijf altijd wel door mijn hoofd spelen. En als ik dan kies voor ja dan pas ik dit toe in het hele model om zo geen verwarring te scheppen. Ook al zal die niet zo snel ontstaan omdat ik de enige ben die er mee werkt.
Ik ben het alleen niet eens met dat mensen te veel waarde aan hechten volgens jou. Het zijn juist informatie elementen die om die reden apart zijn. Stel je maakt een applicatie met 200 tabellen voor een grote organisatie en je moet het spul overdragen. De natuurlijk primary keys leggen zich zelf uit en dat doen ze niet meer wanneer je ze ongedaan maakt door er eigen keys te maken.

Klantnummers zullen bij een fusie niet zo voor problemen zorgen denk ik. Bij zo een providerfusie zullen zaken als verschillende productcatalogi structuren die samengevoegd moeten worden tot meer kopzorgen leiden.

[whoami]

De natuurlijk primary keys leggen zich zelf uit

Kan je hier eens wat over uitwijden ?
Hoezo, ze leggen zichzelf uit ? Wat bedoel je hiermee ? Je kan toch evengoed een unique constraint leggen op die column (of columns) waar je anders de PK zou op leggen ?

Klantnummers zullen bij een fusie niet zo voor problemen zorgen denk ik.

Aannames zijn fataal ...
Waarom zou dat niet voor problemen kunnen zorgen ? Stel bedrijf A neemt bedrijf B over en daarmee alle klanten. Bedrijf A stelt dan dat alle klanten van bedrijf B een nieuw klantennummer moet krijgen die voldoet aan het formaat van het klantnr dat ze al jaren hanteren.

Of, andere situatie, Bedrijf A neemt alle klanten van bedrijf B over, maar, nu zitten ze met klantnr's die elkaar overlappen ... Ojee.

[Janoz]

Anoniem: 141965 schreef op woensdag 20 augustus 2008 @ 15:02:
[...]


Ik vind het ook wel gewoon lekker makkelijk hoor om een surrogate key te gebruiken maar de overweging ja/nee blijf altijd wel door mijn hoofd spelen. En als ik dan kies voor ja dan pas ik dit toe in het hele model om zo geen verwarring te scheppen. Ook al zal die niet zo snel ontstaan omdat ik de enige ben die er mee werkt.
Ik ben het alleen niet eens met dat mensen te veel waarde aan hechten volgens jou. Het zijn juist informatie elementen die om die reden apart zijn. Stel je maakt een applicatie met 200 tabellen voor een grote organisatie en je moet het spul overdragen. De natuurlijk primary keys leggen zich zelf uit en dat doen ze niet meer wanneer je ze ongedaan maakt door er eigen keys te maken.

Een primary key zonder verdere betekenis hoef je helemaal niet verder uit te leggen want er valt helemaal niks over uit te leggen. Hij heeft namelijk helemaal geen betekenins zodra je buiten de database komt.

Klantnummers zullen bij een fusie niet zo voor problemen zorgen denk ik. Bij zo een providerfusie zullen zaken als verschillende productcatalogi structuren die samengevoegd moeten worden tot meer kopzorgen leiden.

whoami heeft het al aangegeven, maar ik blijf toch erg benieuwd waarom jij denkt dat het niet voor problemen gaat zorgen. Hoe zou jij het aanpakken dan?

[jos707]

De afkeer tegen 'surrogate keys' snap ik eigenlijk helemaal niet. Het gebruik van een surrogate key is de enige manier waar je 100% van kan uitgaan dat dit future proof is. Waarom een natural key gebruiken om dan het risico te lopen dat je vroeg of laat tegen een probleem aanloopt dat je records niet meer op een unieke manier benaderd kunnen worden?