[SQL] ERD Ontwerp, wat voor indexes?

[Steephh]

Op school zijn we voor een project bezig met een ERD ontwerp voor database die gebruikt gaat worden bij een 'chatapplicatie'. Bovenstaande afbeelding is het ontwerp tot nu toe. Ik ben het echter (in tegenstelling tot enkele groepsleden en de expert databases (docent)) niet met deze ERD eens. Ik begin nu aan mezelf te twijfelen of mijn denkwijzes wel goed zijn. De docent wil het er nu niet meer met mij over hebben omdat ik volgens hem een verkeerd beeld heb en wat ik denk niet klopt.. Vandaar mijn post hier.

Allereerst zou ik zelf voor een extra kolom met een uniek id kiezen in elke tabel. Dit in combinatie met autonummering. Mijn groepsleden begrijpen niet waarom ik voor een id kies en zien dat als overbodig. De docent zelf is fel tegen het gebruik van autonummering omdat dat voor kan zorgen dat er dubbele spookusernames kunnen worden gecreeerd.

Hier ben ik het niet mee eens omdat je in de indexes kan afdwingen dat een bepaalde kolom uniek moet zijn. De docent zegt hierop: waarom heb je dan een id als primary key? De keuze daarvoor is simpel.. Stel, ik wil een username aanpassen, dan hoef ik dit niet in de tabel 'usergroup' en 'userroom' aan te passen, maar enkel in de tabel 'user'. Alleen zegt hij dat dit ook door middel van een trigger kan... Klopt, maar is dit wel effectief?

Opzich is het natuurlijk wel overzichtelijker wanneer je in de database zelf kijkt, immers een loginname en roomname is natuurlijk een stuk duidelijker dan een tabel met alleen id's. Maar is dit van belang? Wanneer ik een inner join uitvoer krijg ik namelijk toch de informatie die ik moet hebben. De docent zegt echter dat ik door het gebruik van id's en autonummering het principe van een database fundamenteel ondermijn..

Toch ben ik op dit moment van mening dat mijn oplossing ervoor zorgt dat gegevens niet dubbel en overbodig worden opgeslagen en ook een heel stuk sneller is. (waarop mijn docent zei: je moet niet vanuit het systeem denken)

Wat is nu beter?

[ Voor 5% gewijzigd door Steephh op 13-10-2009 16:44 ]

[Grijze Vos]

Dit is typisch een van die holy wars op het gebied van databases. Natural keys vs Surrogate Keys.
Ik vind het een stuk praktischer om altijd een surrogate key te gebruiken, om de redenen die je zelf al gepost hebt. Vanuit een didactisch standpunt is een natural key natuurlijk afdoende.

Mijn tip, doe gewoon vrolijk met ze mee, en gebruik wat je weet als je eenmaal in de praktijk bezig bent, of als je een project kan doen met mensen die je wel snappen.

[Woy]

Het simpelste argument tegen natural keys is dat je nooit wilt dat de primary key van een record veranderd. Het mag dan nu in jullie systeem zo zijn dat een username niet kan veranderen, maar vaak komen er later alsnog wensen bij. En dus kan het zomaar voorkomen dat een username later nog geweizigd gaat worden.

Door met surrogate keys te werken voorkom je dat je die key later nog wilt wijzigen, want de key zelf heeft immers geen betekenis.

Verder met Grijze Vos:

Mijn tip, doe gewoon vrolijk met ze mee, en gebruik wat je weet als je eenmaal in de praktijk bezig bent, of als je een project kan doen met mensen die je wel snappen.

Je hebt immers al je bezwaren aangegeven, maar vaak is het zo dat een leraar niet eenvoudig van zijn "ongelijk" te overtuigen is. Hij is immers de persoon die het zogenaamd het beste weet. Neemt niet weg dat je er altijd over kunt discussiëren, maar uiteindelijk is dat wel de persoon die je beoordeelt, en dus zal je af en toe ook tegen je zin in moeten toegeven aan zijn wil.

[ Voor 22% gewijzigd door Woy op 13-10-2009 16:46 ]

[whoami]

Zoals Grijze vos al zegt, is dit een 'holy war'. Echter, ik begrijp de docent niet dat hij 'het er niet meer over wil hebben met jou'. WTF. Ik denk dat die docent gewoon geen zicht heeft op wat er in de praktijk daadwerkelijk gebeurd.

Anyway, in theorie is het idd niet nodig om bij iedere tabel een extra 'Id' te gaan voorzien. Maar, dat is dus theorie. Bij deze methode komen er imho een heleboel dingen naar voor die gewoon niet praktisch zijn.
Als je primary key bv een samengestelde key moet zijn, dan moet je in een foreign table ook meerdere velden gaan opnemen om die relatie te leggen , bv.
Een ander voorbeeld haalde je zelf al aan: username veranderen met surrogate keys is een simpele update operatie op één tabel.
Username veranderen als je gebruikt maakt van natural keys impliceert al dat je al je foreign keys ook moet gaan aanpassen. In principe kan dit makkelijk als je een 'ON UPDATE CASCADE' kunt definieren op je foreign key, maar ik weet niet of ieder DBMS dit ondersteund. Daarnaast betekent dit ook nog eens dat je dus meerdere tabellen moet aanpassen, en dat er hoogstwaarschijnlijk meerdere indexen moeten aangepast worden. (Ik mag veronderstellen dat er op een foreign key column meestal een index ligt).
Trouwens, ik ga er altijd van uit dat een primary key nooit veranderd. En dat hoeft ook niet. Een primary key hoeft geen enkele betekenis te hebben binnen het 'business domain'.

docent zegt echter dat ik door het gebruik van id's en autonummering het principe van een database fundamenteel ondermijn..

Kan hij ook zeggen waarom je het op die manier zou ondermijnen ?
Je ondermijnt het helemaal niet; het is gewoon een andere manier om de relatie te leggen. Je gaat hier niet onnodig gegevens gaan dupliceren ofzo.

Ik ga zelf altijd ook voor een surrogate key (dus een extra kolom die een record uniek identificeert).
Deze primary key heeft geen enkele waarde in het 'business domain', en is er enkel en alleen omwille van administratieve redenen voor de DB.

Het verhaal van de dubbele usernames kan simpelweg ontkracht worden, omdat het gewoon mogelijk is om een unique constraint op dat veld te definieren.

[ Voor 4% gewijzigd door whoami op 13-10-2009 16:52 ]

[Glashelder]

Dat is typisch zo'n leraar die nog redeneert vanuit ouderwetse standpunten, toen de resources nog schaars waren. Van zo'n figuur heb ik ook ERD's leren maken op INHolland. Hij is inmiddels met pensioen, en terecht

Of jij hebt nu les van die leraar Had exact dezelfde discussie

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:37 ]

[.oisyn]

Steephh schreef op dinsdag 13 oktober 2009 @ 15:51:
Allereerst zou ik zelf voor een extra kolom met een uniek id kiezen in elke tabel.

Elke tabel? Wat hebben koppeltabellen zoals usergroup en userroom in jouw geval aan eigen id's? Het is niet alsof je naar de relatie wilt kunnen wijzen oid. In die gevallen zou ik dus gewoon een primary key over de twee foreign keys definieren.

[Janoz]

Maar dan zullen in die koppeltabelen wel de id's van de betreffende tabellen opgenomen worden, en niet de leterlijke group, room en username

[/stating the obvious]


Verder denk ik dat we hier te maken hebben met een docent van het slag 'Those who can, do. Those who can't teach'. Leuk die theorie, maar in 'het echt' wordt je vierkant uitgelachen wanneer je met een dergelijk ERD aan komt zetten. Een 'holy war' zou ik het dan ook niet willen noemen. Die oorlog is al lang gestreden..

[RobIII]

Tip: Print dit topic en zeg (en toon) hem dat "those who know and are reporting from the trenches" 't volledig met je eens zijn en dat hij er fa-li-kant langs zit. * RobIII ook een achter je gaat staan.

[ Voor 17% gewijzigd door RobIII op 13-10-2009 19:13 ]

[MMUilwijk]

Het gebruik van surrogate keys in de vorm van auto increment fields is tegenwoordig toch geen "holy war" meer? Eerder een best practice. Je wilt zoals gezegd je primary key van een record echt niet gaan wijzigen i.v.m. relationele integriteit.

Volgens mij zegt zelfs de goede oude database guru mr. Date dat dit slim is om te doen. Ben wel benieuwd welke school nog zulke principes aanhangt, INHolland kan het toch niet zijn (uit eigen ervaring).

[Steephh]

Wow, bedankt voor jullie feedback!

Ik heb zelf ook al gekozen om niet verder in discussie te gaan, ook omdat hij volgens mij echt niet te overtuigen is en hij uiteindelijk wel mijn cijfer bepaald. Ik zei op het eind van onze 'discussie' ook: 'bedankt voor de feedback' en heb gezegd dat ik het niet met hem eens ben, maar het toch op zijn manier zal doen omdat hij heeft gezegd dat het zo moet. Hij zei volgens mij nog letterlijk zoiets als 'dan ben JIJ toch echt fout bezig'. Ik heb er maar voor gekozen om met hem niet verder in discussie te gaan.

Surrogate keys in een koppeltabel zijn inderdaad lichtelijk overbodig, maar dat deed ik in eerste instantie wel, maar ben ik mee gestopt.

Voor de geinteresseerden: het betreft de opleiding Technische Informatica te Breda, 2e jaar..

_{Die meer op een ouderwetse opleiding informatica met wat mbo niveau 1 elementen lijkt, aangezien we dit jaar (2e jaar van de opleiding, 1e kwartaal) een vak computerarchitectuur hadden waarbij we om inzicht te krijgen in de werking van een pc het volgende moesten doen: 'stel een high end gamepc en een game pda samen voor een budget van 1500 euro.. Ik had persoonlijk meer gehoopt op instructie over het ontwerp van een CPU, instructieset, adresseermodes, en geheugentechnieken '}

[ Voor 12% gewijzigd door Steephh op 13-10-2009 19:58 ]

[MTWZZ]

Steephh schreef op dinsdag 13 oktober 2009 @ 19:55:
Wow, bedankt voor jullie feedback!

Ik heb zelf ook al gekozen om niet verder in discussie te gaan, ook omdat hij volgens mij echt niet te overtuigen is en hij uiteindelijk wel mijn cijfer bepaald. Ik zei op het eind van onze 'discussie' ook: 'bedankt voor de feedback' en heb gezegd dat ik het niet met hem eens ben, maar het toch op zijn manier zal doen omdat hij heeft gezegd dat het zo moet. Hij zei volgens mij nog letterlijk zoiets als 'dan ben JIJ toch echt fout bezig'. Ik heb er maar voor gekozen om met hem niet verder in discussie te gaan.

Surrogate keys in een koppeltabel zijn inderdaad lichtelijk overbodig, maar dat deed ik in eerste instantie wel, maar ben ik mee gestopt.

Voor de geinteresseerden: het betreft de opleiding Technische Informatica te Breda, 2e jaar..

_{Die meer op een ouderwetse opleiding informatica met wat mbo niveau 1 elementen lijkt, aangezien we dit jaar (2e jaar van de opleiding, 1e kwartaal) een vak computerarchitectuur hadden waarbij we om inzicht te krijgen in de werking van een pc het volgende moesten doen: 'stel een high end gamepc en een game pda samen voor een budget van 1500 euro.. Ik had persoonlijk meer gehoopt op instructie over het ontwerp van een CPU, instructieset, adresseermodes, en geheugentechnieken '}

Als dit echt de stand van zaken is zou ik toch eens met een opleidingsmanager gaan praten want hoe leuk ze het ook bedacht hebben dit sluit totaal niet aan op de werkelijkheid. Al besef ik me terdege dat dit niet altijd even makkelijk is.

Edit:
offtopic even weggehaald aangezien dit toch wel redelijk on-topic is.

[Creepy]

Het is zeker ontopic ja. @Steeephh: al de punten die je aandraagt zijn zeker terecht. Je wil geen PK's lopen updaten omdat er een user/group/room-name veranderd, ook niet met triggers e.d. Het feit dat de leraar maar gewoon roept het er niet meer met je over te hebben geeft wat mij betreft ook al aan dat hij stiekum wel doorheeft dat je gewoon terechte punten aandraagt.

[Steephh]

Een en ander wordt al aangepast binnen de studie. Echter, dit geldt niet voor ons en het huidige 1e jaar is een soort van proefkonijn. Hier val ik dus buiten.. Eigenlijk heb ik e.e.a. ook aan mezelf te wijten.

Schooljaar 2007-2008: Technische Informatica op de Avans te Den Bosch, gestopt omdat ik niets meer in de studie zag, wilde op dat moment niets meer met computers doen.. Voortijdig gestopt en ik heb een negatief bindend studieadvies gekregen (terwijl ik nog kans had om mijn propedeuse in één jaar te halen).
Schooljaar 2008-2009, 1e halfjaar: Bioinformatica: Leek me erg leuk vanwege biologie + programmeren.. Voldoet niet aan mijn verwachtingen.. Biologie bleek vooral op DNA en eiwit niveau te zijn en het programmeren kan men beter scripten noemen.
Schooljaar 2008-2009, 2e halfjaar Technische Informatica op de Avans te Breda: Mijn interesse bleek toch echt bij Technische Informatica te liggen. Ik kon niet meer terug naar Den Bosch vanwege een negatief bindend studieadvies (eigen schuld dus). Ik ben daarom ingestroomt halverwege het 1e jaar bij TI bij Avans Breda aan de hand van mijn behaalde competenties. Heb mijn propedeuse behaald.
Schooljaar 2009 - * Dit schooljaar. Omdat ik het totaal niet eens ben met de gang van zaken heb ik tot tweemaal toe geprobeerd om terug te gaan naar TI op de Avans te Den Bosch. Ik heb een goed inzicht in welke vakken die je daar kijkt omdat een oud-klasgenoot daar ook zit. Ook al heb ik inmiddels mijn propedeuse, het negatief bindend studieadvies blijft staan en ik zal nog 2,5 jaar moeten wachten voordat ik daar weer opnieuw kan beginnen/instromen. Het lijkt me dus niet de moeite waard om hierop nog te gaan wachten.. Dus ik zit in principe hieraan vast.

De reden dat ik liever naar Den Bosch ga is omdat ik dáár de vakken krijg waar ik verwacht later iets aan te hebben in het bedrijfsleven.. Vakken als VHDL krijg je daar.. en er wordt daar ook veel meer aandacht aan UML besteed.. Iets wat hier in Breda heel veel mensen nog aan hun laars lappen... Like: eerst het programma maken, aan het eind van het project nog even snel een klassendiagram maken (want ja, dat moet voor je cijfer)...

[Alain]

Het afkappen van de discussie is natuurlijk not done, maar ik snap wel dat de werkwijze gehanteerd wordt in het onderwijs. Je bent niet bezig met een product maken, maar je bent bezig met leren wat een database kan en vooral, wat jij ermee kunt doen. Als je deze basiskennis hebt kun je dit ontwikkelen in het bedrijfsleven en uitbreiden met praktische kennis.

Bij de open universiteit hanteren ze ook het principe dat je geen extra id aanmaakt, maar ze geven wel de opmerking dat het vaak praktischer kan zijn om het wel te doen. Als je leraar dat gewoon had gezegd was de hele discussie imho overbodig.

[RobIII]

AlainS schreef op dinsdag 13 oktober 2009 @ 21:29:
Het afkappen van de discussie is natuurlijk not done, maar ik snap wel dat de werkwijze gehanteerd wordt in het onderwijs. Je bent niet bezig met een product maken, maar je bent bezig met leren wat een database kan en vooral, wat jij ermee kunt doen. Als je deze basiskennis hebt kun je dit ontwikkelen in het bedrijfsleven en uitbreiden met praktische kennis.

Wat mij betreft leer je 't mensen dan gewoon verkeerd aan. En iets wat eenmaal aangeleerd is sla je er maar lastig weer uit. Feit is: Het is niet écht verkeerd, maar het is wel érg niet zoals het "in the real world" gebruikt wordt. En ik meen toch echt dat een school je daar voor hoort klaar te stomen; of dat concept is veranderd de laatste jaren

[Glashelder]

en er wordt daar ook veel meer aandacht aan UML besteed.. Iets wat hier in Breda heel veel mensen nog aan hun laars lappen... Like: eerst het programma maken, aan het eind van het project nog even snel een klassendiagram maken (want ja, dat moet voor je cijfer)..

Het zou hogescholen sieren als ze eens fatsoenlijk zouden benadrukken waarom dit nou zo belangrijk is. Toevallig krijgen wij nu ook UML maar pas aan het eind van een blok wordt het belang van iets als UML en RUP duidelijk. Dat moet toch echt beter kunnen.

Dat is namelijk precies de reden dat studenten het aan hun laars lappen, het ontbreekt ze aan inzicht. Studenten (zeker informatica) zijn eigenwijs en willen graag het waarom weten, en het liefst vóór het hoe, anders doen ze gewoon niks. En daarna is het te laat.

[pedorus]

Even afgezien van de keys, zou ik zeggen dat een docent die tabelnamen als "group" en "user" aanraadt bijscholing nodig heeft. Allereerst is het logisch om tabelnamen meervoud te maken, en daarnaast zijn ze verboden als tabelnaam door de standaard en ook in (bijna) iedere database engine een reserved word...

[RobIII]

pedorus schreef op woensdag 14 oktober 2009 @ 01:23:
Even afgezien van de keys, zou ik zeggen dat een docent die tabelnamen als "group" en "user" aanraadt bijscholing nodig heeft. Allereerst is het logisch om tabelnamen meervoud te maken, en daarnaast zijn ze verboden als tabelnaam door de standaard en ook in (bijna) iedere database engine een reserved word...

Even afgezien dat ik me never-ever-nooit laat tegenhouden door reserved words (noem 't beestje bij z'n naam, ga "users" geen "members" of whatever noemen omdat 't een gereserveerd woord zou zijn; en wie zegt me dat in de volgende versie van DBMS X het woord "members" niet reserved zal zijn?) valt er nog te twisten over meervoud/enkelvoud. Het is, in mijn ervaring, toch wel gangbaar enkelvoud te gebruiken. Ik gebruik het zelf ook en 80% van de projecten die ik tegen kom zijn ook enkelvoud (natte vinger werk, maar toch...). Maar deze discussie wordt al decennia gevoerd en beiden kampen hebben goede argumenten. Either way: Pick one and stick with it.

Ik ben 't dan dus ook op beiden punten oneens met je. Puh
Reserved words kun je (lees: moet je/kwestie van) escapen
Enkelvoud/meervoud is smaakkwestie

offtopic:
Onder een aantal DBMS'en, waaronder iig zeker SQL2k5+, kun je synoniemen gebruiken. Dan maak je gewoon enkelvoud tabellen en geef je ze een meervoud synoniem (of andersom) en dan is iedereen happy

En waarom ik voor enkelvoud gekozen heb? Omdat dat handig(er) is als je met ORM werkt; je classes krijgen dan meteen logische namen want 't meervoud gaat dan niet meer op De tabel employee mapped dan naar de class employee (en dus employee.name etc.). Bij meervoud krijg je een class employees die feitelijk maar 1 medewerker representeert en tot overmaat van ramp krijg je dan employees.name

Daarbij queries worden (imho) leesbaarder. Wat zie jij liever?

select employee.name, employee.email from employee ...

of

select employees.name, employees.email from employees ...

[ Voor 41% gewijzigd door RobIII op 14-10-2009 02:19 ]

[B-Man]

RobIII: Dat laatste is natuurlijk een beetje een non-argument, om dat ieder zichzelf respecterend ORM de mogelijkheid heeft om per entity aan te geven wat de tabelnaam moet zijn.

On topic: heel erg herkenbaar verhaal, en een van de (vele) redenen waarom ik zelf jaren (poe hee, 11 alweer) geleden afgehaakt ben op de TU/e. Docenten die stug vasthouden aan technieken die ze kennen, en schijnbaar niet in staat zijn om in te zien dat het best zo zou kunnen zijn dat hun kennis (deels) achterhaald is. Mijn advies: als je met plezier je opleiding wil afronden, doe dan wat ze vragen zonder veel discussie. Weet of wil je meer, vermaak je zelf dan buiten je studie.

[pedorus]

RobIII schreef op woensdag 14 oktober 2009 @ 01:38:
[...]

Even afgezien dat ik me never-ever-nooit laat tegenhouden door reserved words (noem 't beestje bij z'n naam, ga "users" geen "members" of whatever noemen omdat 't een gereserveerd woord zou zijn; en wie zegt me dat in de volgende versie van DBMS X het woord "members" niet reserved zal zijn?) valt er nog te twisten over meervoud/enkelvoud.

Oftewel, we negeren gewoon lekker de standaard en best practices die zeggen dat het niet mag. Best goed om bij het aanleren van SQL de SQL-standaard gewoon te negeren natuurlijk. En escapen is vast de oplossing:

quote: http://drupal.org/node/371#comment-287619

The use of timestamp as a column name has now caused a problem using standard mySQL tools for database recovery. Timestamp is also being inappropriately used as an SQL identifier and as a PHP variable. I feel for those that have db's in the 10mb+ range with this problem.

Overigens is users helemaal niet reserved.

Het is, in mijn ervaring, toch wel gangbaar enkelvoud te gebruiken.

Iets met als iedereen in de sloot springt; kom met een echt argument of een link daarnaartoe. In een tabel staan meestal meerdere tupels, dus is het logisch om meervoud te gebruiken. En ik ben van mening dat je beter iets kan aanleren dat logisch is.

En waarom ik voor enkelvoud gekozen heb? Omdat dat handig(er) is als je met ORM werkt; je classes krijgen dan meteen logische namen want 't meervoud gaat dan niet meer op De tabel employee mapped dan naar de class employee (en dus employee.name etc.).

Hmm, mijn tool zet die s er juist automatisch achter, en dat is standaard...

Daarbij queries worden (imho) leesbaarder. Wat zie jij liever?

SQL:

select employee.name, employee.email from employee

of

SQL:

select employees.name, employees.email from employees

Aliassen. (En geen uitgeschreven queries voor zoiets.)

offtopic:
Overigens vind ik name hier een beroerde naam.

---

Verder kan ik me nog wel een discussie herinneren die afgesloten werd met 'Maar ik bepaal hier de cijfers.'. Tsja, dan ben je gewoon klaar natuurlijk... Als een beslissing eenmaal genomen is mag je gewoon niet verwachten dat iemand er snel op terug gaat komen, maar misschien heeft iemand na jou er nog eens iets aan... Je ziet dat overal terug. Ik verwacht ook niet dat RobIII nu direct gaat replyen met 'Oh stom, ik heb het altijd verkeerd gezien'.

[Woy]

RobIII schreef op woensdag 14 oktober 2009 @ 01:38:

offtopic:
Daarbij queries worden (imho) leesbaarder. Wat zie jij liever?

select employee.name, employee.email from employee ...

of

select employees.name, employees.email from employees ...

offtopic:
Ook een ORM kun je perfect vertellen dat Employees op Employee mapt. Ik zie liever

SELECT employee.name, employee.email FROM Employees AS employee

. Ik heb zelf dus meestal de neiging om naar meervoud te grijpen, maar het is inderdaad meer een smaak. Als je maar consequent overal hetzelfde doet haalt het geen fuck uit.

[whoami]

pedorus schreef op woensdag 14 oktober 2009 @ 08:23:
[...]

Oftewel, we negeren gewoon lekker de standaard en best practices die zeggen dat het niet mag. Best goed om bij het aanleren van SQL de SQL-standaard gewoon te negeren natuurlijk. En escapen is vast de oplossing:

Ik wil wel eens die standaard zien die zegt dat 'dat niet mag' ....
Zoals Rob al aangeeft, kan je die namen gewoon makkelijk escapen. Ik ga ook mijn tabellen een naam geven die het beste aanleunt tegen wat die tabel nu eigenlijk bevat. Is dat toevallig een reserved word, dan is dat jammer. Ik escape toch alles (dat is een best practice. ).

Over enkelvoud / Meervoud: ook daar is er imho geen enkele regel die zegt dat je het zus of zo moet doen. Ik prefereer ook enkelvoud, dat leest gewoon veel gemakkelijker. (Maar dit is een religious war).

Hmm, mijn tool zet die s er juist automatisch achter, en dat is standaard...

Ik hou niet van tooltjes die dat allemaal automatisch doen.

[RobIII]

@pedorus: Het is dat whoami me nu het gras voor de voeten weg maait maar precies wat hij zegt had ik je dus verteld. Tools die voor mij meervoud gaan bepalen (mouse -> mouses? mouse -> mice!) heb ik een hekel aan. Verder kan ik me niet heugen dat de SQL standaard ergens beweert dat enkelvoud/meervoud gebruikt moet worden voor tabelnamen. En inderdaad, wat wél best practice is, (maar soms, idd, wat omslachtig) is gewoon alles per definitie escapen. Tja, ik kan er echt niet meer van maken dan dat whoami precies zegt wat ik wou zeggen.

pedorus schreef op woensdag 14 oktober 2009 @ 08:23:
Overigens is users helemaal niet reserved.

Dat heb je mij ook niet horen zeggen, maar wie zegt dat 't in de volgende versie niet zo is? Vandaar dat 't gewoon verstandig is om bij voorbaat te escapen. Dat "mufflertype(s)" nooit een reserved word zal worden is wiedes, maar daar gaat 't hier niet om.

pedorus schreef op woensdag 14 oktober 2009 @ 08:23:
In een tabel staan meestal meerdere tupels, dus is het logisch om meervoud te gebruiken. En ik ben van mening dat je beter iets kan aanleren dat logisch is.

Ik was vroeger ook van mening dat 't logisch was maar ik ben er jaren geleden op teruggekomen. Shoot me.

pedorus schreef op woensdag 14 oktober 2009 @ 08:23:
Aliassen. (En geen uitgeschreven queries voor zoiets.)

offtopic:
Overigens vind ik name hier een beroerde naam.

Nou loop je te mierenneuken; het ging om 't idee en ik verzon terplekke een (granted, misschien niet al te handig) voorbeeld. Het gaat om het principe.

pedorus schreef op woensdag 14 oktober 2009 @ 08:23:
Ik verwacht ook niet dat RobIII nu direct gaat replyen met 'Oh stom, ik heb het altijd verkeerd gezien'.

Zodra ik van mijn ongelijk overtuigd ben ben ik zéker de eerste die er voor uit zal komen. Ik vind dat zelfs een admirabele en goede eigenschap aan een devver; het is een kunst om je eigen fouten te erkennen, er van te leren en dan "move on".

[whoami]

RobIII schreef op woensdag 14 oktober 2009 @ 10:46:
@pedorus: Het is dat whoami me nu het gras voor de voeten weg maait

Sorry Rob.
Maar, om het goed te maken, mag jij bij mij wel eens het gras komen maaien. Afgesproken ?


(En nadien heb je wel een biertje verdiend).

[ Voor 9% gewijzigd door whoami op 14-10-2009 11:59 ]

[Jrz]

flame: docent moet misschien zelf in de schoolbanken.
Een pk kan niet veranderen en kan niet null zijn.
Je kan dus ook geen username of groupname aanpassen.

[The Eagle]

Even puur vanuit functioneel oogpunt gezien: het gaat hier om een chatroom. In principe wil je niet 2 users met de zelfde naam, en ook niet twee rooms met de zelfde naam. Dus username en roomname moeten sowieso al unieke sleutels zijn, onafhankelijk van de discussie van autonummering.

Verder: vanuit functioneel oogpunt wil je dat een gebruiker als hij geregistreerd is, zijn naam niet veranderd. Desnoods een nieuwe, maar geen wijziging. Zo blijft alles van de geregistreede users netjes behouden, en kun je ook gastusers cateren. Zolang ze niet een bestaande naam pakken zitten ze safe. Bij uitloggen van een gastuser idd een cascade of een trigger en je bent van de hele bende af. Hoef je niet voor gastusers te cateren, dan heb je dit hele probleem niet

Autonummering is tegenwoordig overigens idd een non-discussie; zelfs bij zware ERP-systemen wordt dit inmiddels veelvuldig toegepast voor het maken van unieke sleutels, zelfs al dan niet icm een persistente 2e connectie naar de DB voor extra snelheid )

Kortom: in principe hebben beiden gelijk...maar ik denk dat de docent de bedoeling van de chatapp beter kent, en dat geeft dan de doorslag

Edit: gevleugelde uitspraak die bij een ex-werkgever (ROC) ergens aan de muur hing:

"Zij die het weten, willen het niet leren. Zij die het niet weten, staan voor de klas"

[ Voor 7% gewijzigd door The Eagle op 14-10-2009 12:22 ]

[Twazerty]

Ik hoor hier van mijn collega dat het opbouwen van een index ook niet goed werkt met varchars. Int's als Private Keys is gewoon zoveel praktischer.

[Creepy]

The Eagle schreef op woensdag 14 oktober 2009 @ 12:21:
Even puur vanuit functioneel oogpunt gezien: het gaat hier om een chatroom. In principe wil je niet 2 users met de zelfde naam, en ook niet twee rooms met de zelfde naam. Dus username en roomname moeten sowieso al unieke sleutels zijn, onafhankelijk van de discussie van autonummering.

Ho even. Uniek? Ja. Sleutel? Niet persee. Dat iets uniek moet zijn wil niet volautomatisch maar zeggen dat het dan ook gelijk maar een sleutel moet zijn.

Verder: vanuit functioneel oogpunt wil je dat een gebruiker als hij geregistreerd is, zijn naam niet veranderd. Desnoods een nieuwe, maar geen wijziging. Zo blijft alles van de geregistreede users netjes behouden, en kun je ook gastusers cateren. Zolang ze niet een bestaande naam pakken zitten ze safe. Bij uitloggen van een gastuser idd een cascade of een trigger en je bent van de hele bende af. Hoef je niet voor gastusers te cateren, dan heb je dit hele probleem niet

Dus hier op het forum zouden dan ook geen nick's aangepast moeten kunnen worden? Juist omdat je geen nieuwe nick mag nemen maar je nick gewoon kan wijzgen blijft je hele history intact.

Autonummering is tegenwoordig overigens idd een non-discussie; zelfs bij zware ERP-systemen wordt dit inmiddels veelvuldig toegepast voor het maken van unieke sleutels, zelfs al dan niet icm een persistente 2e connectie naar de DB voor extra snelheid )

Kortom: in principe hebben beiden gelijk...maar ik denk dat de docent de bedoeling van de chatapp beter kent, en dat geeft dan de doorslag

Edit: gevleugelde uitspraak die bij een ex-werkgever (ROC) ergens aan de muur hing:

"Zij die het weten, willen het niet leren. Zij die het niet weten, staan voor de klas"

So true

[Grijze Vos]

Okay, een hoop gepraat in dit topic over natural keys, maar niemand lijkt te weten waar het om gaat. Performance, Geheugenopslag e.d. is helemaal niet het punt. Het is een puur algebraisch punt.

In de oorspronkelijke database theorie wordt een tuple geidentificeerd door de data die in dat tuple staat. Verder is elk tupel in een tabel uniek. Als je dus een surrogate key aanmaakt, dan is het mogelijk de volgende twee tuples in een tabel te hebben:

(1, A, B, C)
(2, A, B, C)

Deze zijn gelijk aan elkaar, want de ID's (1 & 2) hebben geen betekenis. Vanuit een fundamenteel theoretisch oogpunt is dit dus niet goed. Je docent heeft dus in die zin wel gelijk, maar daarvoor hebben we in de praktijk unique constraints uitgevonden die dit alsnog afdwingen. In de praktijk nemen we die afwijking van de theorie voor lief, omwille van de implementatie. Dat een professor databases hierover zal zeuren, ok. Dat een docent op een hogeschool - waar nota bene scholieren worden opgeleid tot professionals, niet tot theoretici - hierover zeurt is redelijk vervelend, en nutteloos.

[Remus]

pedorus schreef op woensdag 14 oktober 2009 @ 08:23:
Iets met als iedereen in de sloot springt; kom met een echt argument of een link daarnaartoe. In een tabel staan meestal meerdere tupels, dus is het logisch om meervoud te gebruiken. En ik ben van mening dat je beter iets kan aanleren dat logisch is.

De relatie of tabel bevat entiteiten en wordt vaak genoemd naar de enkelvoudsvorm van de entiteit omdat de individuele records/tupels een enkele entiteit representeren. Vergelijk het maar met de reden waarom classes ook enkelvoudige namen hebben.

Daarnaast is het met diverse modelleringstechnieken natuurlijker om van enkelvoud uit te gaan (bijvoorbeeld NIAM (Natural language Information Analysis Method), ORM (Object Role Modelling), of noun-phrase analysis).

Het relationele model is gebaseerd op het wiskundige begrip relatie, dat bij mijn weten over het algemeen een enkelvoudige naam heeft.

Maar als je een quote wilt hebben:

We choose singular names for entity types, rather than plural ones, because the entity type name applies to each individual entity belonging to that entity type.

(pagina 63)

The table name and column names are used to help in interpreting the meaning of the values in each row. [..](The table) is called STUDENT because each row represents facts about a particular student entity.

(pagina 196)
Uit: R. Elmasri en S.B. Navathe, Fundamentals of database systems, 3rd edition, Addison Wesley, June 2000
Dit is toch wel een redelijk bekend boek over database systemen (momenteel 5e editie uit, volgend jaar 6e).

Daarnaast gebruikt Codd zelf (de bedenker van het relationele model) in het het artikel A relational model of data for large shared data banks (1970) en in een van zijn boeken The relational model for database management: version 2 (1990) ook enkelvoudsvormen voor relaties / tabelnamen.

Dat gezegd hebbende: het blijft een keuze.

[pedorus]

whoami schreef op woensdag 14 oktober 2009 @ 09:02:
[...]
Ik wil wel eens die standaard zien die zegt dat 'dat niet mag' ....

Helaas is die niet vrij beschikbaar, en het lijkt erop alsof hij ook niet bedoelt is om te lezen. Ik heb wel het volgende voor je:

quote: http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html

Most of the words in the table are forbidden by standard SQL as column or table names (for example, GROUP).

Zoals Rob al aangeeft, kan je die namen gewoon makkelijk escapen.

Enkel dan werken soms bijvoorbeeld de standaard tools bij je database niet meer... En in MySQL zit je dan ook nog met verschillende vormen van escapen; liefst wil je ANSI, maar dat is afhankelijk van sql_mode. (Ik ga even uit van MySQL omdat het plaatje van MySQL Workbench is.)

Remus schreef op woensdag 14 oktober 2009 @ 14:49:
Daarnaast is het met diverse modelleringstechnieken natuurlijker om van enkelvoud uit te gaan (bijvoorbeeld NIAM (Natural language Information Analysis Method), ORM (Object Role Modelling), of noun-phrase analysis).

ORM gaat nu juist uitstekend samen met meervoud. Sterker nog, bij de meeste .NET varianten zul je het expliciet uit moeten zetten. RoR is een ander voorbeeld.

R. Elmasri en S.B. Navathe, Fundamentals of database systems, 3rd edition, Addison Wesley, June 2000
Dit is toch wel een redelijk bekend boek over database systemen (momenteel 5e editie uit, volgend jaar 6e).

Op zich goed uitzoekwerk, maar Entity type != Tabelnaam
Verder is dat andere argument vrij vertaald: De array noemen we student omdat elk element feiten over een bepaalde student bevat. Denk dat dat ook niet om meervoud gaat, maar meer over het gekozen woord. Let er ook op dat een ER-diagram geen tabelnamen bevat, maar entitynamen.

offtopic:
Overigens zeer bekend boek dat steeds dikker en minder bruikbaar wordt.

De 2 argumenten waar reserved words het hoofdargument van was, gaan trouwens hand in hand natuurlijk:

quote: http://it.toolbox.com/blo...table-names-33590#2946092

What finally convinced me, however, was the fact that plural table names avoid SQL reserved word conflicts. So while Bricolage has singular table names, the table for the user class has the unfortunate name "usr" to avoid the reserved word "user". Using the plural, "users", avoids this issue, and is easier to read and remember.

Maar goed, ik ben blijkbaar al tijden gezegend met meervoud, even afgezien van die namen als "t24319".

[whoami]

pedorus schreef op donderdag 15 oktober 2009 @ 12:47:
[...]

Helaas is die niet vrij beschikbaar, en het lijkt erop alsof hij ook niet bedoelt is om te lezen.

Ik heb wel het volgende voor je:

Wat heeft dit te maken met singular / plurar names ?

Enkel dan werken soms bijvoorbeeld de standaard tools bij je database niet meer...

Precies of die standaard tools niet intelligent genoeg zijn om tabelnamen te escapen ?

ORM gaat nu juist uitstekend samen met meervoud. Sterker nog, bij de meeste .NET varianten zul je het expliciet uit moeten zetten. RoR is een ander voorbeeld.

In de ORM die ik gebruik, wordt er helemaal niets automatisch gegenereerd. Ik bepaald dus zelf mijn klasse-namen.

[pedorus]

whoami schreef op donderdag 15 oktober 2009 @ 22:13:

offtopic:
Voor een definitieve versie van de SQL-standaard moet je betalen, en dan nog is het veels te veel pagina's en te uitgebreide definities.

Wat heeft dit te maken met singular / plurar names ?

Waar beweer ik dat? Het ging over user en group als tabelnaam, welke reserved words zijn in SQL.. Geen good practice die je zo gaat aanleren in mijn ogen. Het geval wil overigens dat users en groups dit niet zijn.

Precies of die standaard tools niet intelligent genoeg zijn om tabelnamen te escapen ?

Punt is dat het problemen kan geven om reserved words te gebruiken, zelfs als je ze in je eigen code escaped, en je database ze op die manier accepteert. Waar het exact aan ligt per database lijkt me niet heel relevant, voor MySQL heb ik wat voorbeelden genoemd. Het is natuurlijk grappig als je de schuld kan verschuiven, maar dat lost het probleem niet op.

In een taal als c# kan ik ook prima een keyword als identifier gebruiken, en er zullen vast gevallen zijn waar dat nog het meest voor de hand liggende woord is ook. Toch zal ik het nooit doen als het niet perse nodig is, omdat het ontzettende bad practice is, en zeker niet iets dat je nog als voorbeeld gaat aanleren ook...

[Grijze Vos]

Euhm, als ik een OR/Mapper heb, en die vertaald mijn tabelnamen naar classes, en ik neem een lijst van zulke classes, dan krijg ik dus een List<Users>. Niet echt logisch.

Maar goed, leuk dat de tweede holy war ook in dit topic meteen naar boven komt.

[masq]

pedorus schreef op donderdag 15 oktober 2009 @ 12:47:
[...]

ORM gaat nu juist uitstekend samen met meervoud. Sterker nog, bij de meeste .NET varianten zul je het expliciet uit moeten zetten. RoR is een ander voorbeeld.

Jij hebt het over O/R Mapping, Remus over Object Role Modeling. ORM is fact based, dan is het redelijk logisch dat je enkelvoud gebruikt.

[Remus]

pedorus schreef op donderdag 15 oktober 2009 @ 12:47:
ORM gaat nu juist uitstekend samen met meervoud. Sterker nog, bij de meeste .NET varianten zul je het expliciet uit moeten zetten. RoR is een ander voorbeeld.

Zoals masq al aangaf had ik het niet over object relational mapping, maar over Object Role Modelling.
Bij ObjectRelationMapping is het een keuze van de implementor: Hibernate en JPA gebruiken standaard de classname; dus over het algemeen enkelvoud.

Bij mijn weten gaat de meerderheid van de database-literatuur uit van de enkelvoudsvorm. En dat er een paar reserved words zijn in SQL is nog geen reden om dan maar meervoud te nemen: er zijn relatief weinig reserved words om dat als echt argument te gebruiken IMHO.

Op zich goed uitzoekwerk, maar Entity type != Tabelnaam
Verder is dat andere argument vrij vertaald: De array noemen we student omdat elk element feiten over een bepaalde student bevat. Denk dat dat ook niet om meervoud gaat, maar meer over het gekozen woord. Let er ook op dat een ER-diagram geen tabelnamen bevat, maar entitynamen.

offtopic:
Overigens zeer bekend boek dat steeds dikker en minder bruikbaar wordt.

Over het algemeen is een tabel de representatie van het entiteittype, een zwak entiteittype of een koppeltabel (relationshiptype). Als je in je modellering uitgaat van enkelvoud (wat zoals ik al zei in de meeste modelleringstechnieken natuurlijk volgt), dan ben je wel heel onhandig bezig om bij de vertaling van je model naar tabellen opeens van die enkelvoudsvorm over te stappen naar meervoud.

Die overstap is niet nodig, beperkt de directe koppeling tussen je model en je realisatie en is daardoor duidelijk een argument tegen die keuze.

Maar ok, heilige huisjes enzo