Foreign key als primary key

[com2,1ghz]

Beste Tweakers,

Nou heb ik op mn werk te maken met mensen die denken het beter te weten zonder een onderbouwd argument en graag zou ik van jullie raad willen weten.

Situatie:

Ik heb 3 tabellen bedacht om mijn situatie te verduidelijken:
woning(id, naam, adres,)

flat(woningId, verdieping, lift)

villa(woningId, perceeloppervlakte)

Het gaat er om dat een woning of een flat kan zijn of een villa

De cardinaliteit is als volgt:
Een woning kan of een flat zijn of een villa.
Wanneer deze woning wordt opgeslagen, wordt bij de bijbehorende flat/villa tabel de gegevens meegeschreven. De flat/villa hebben beide hun primary key als foreign key naar woning.

Een flat of villa kan dus niet alleen bestaan.

Nou moeten we even niet nadenken over 1 woning die een flat EN een villa is. Het is altijd 1 of het ander en dat is al afgevangen in de code. Het gaat er om dat ik een woning kan aanmaken zonder dat ik weet wat voor soort het is en achteraf een soort kan koppelen.

Nou beweren mn collegas dat ik dit niet mag doen omdat er overal een ID moet komen met auto_increment.
Ik ben het hiermee niet mee eens omdat ik wil afdwingen dat het nooit mogelijk mag zijn dat 1 woning meerdere keer voorkomt in flat/villa tabel.

Is het nou fout dat ik de primary key van woning gebruik als primary key voor flat/villa tabel?

[Janoz]

Hoewel je collega's niet een duidelijk argument hebben waarom er perse een ID meot zijn, klopt je eigen argumentatie ook niet. Om woningId in flat of villa uniek te houden ben je niet verplicht om daar de primary key van te maken. Een unique constraint is voldoende.

[com2,1ghz]

Janoz schreef op donderdag 19 januari 2012 @ 12:05:
Hoewel je collega's niet een duidelijk argument hebben waarom er perse een ID meot zijn, klopt je eigen argumentatie ook niet. Om woningId in flat of villa uniek te houden ben je niet verplicht om daar de primary key van te maken. Een unique constraint is voldoende.

Een primary key is naar mijn weten altijd uniek dus dan zou ik toch geen unique constraint voor hoeven te maken toch? Een tupel uit flat/villa identificeer ik dmv de primary key wat tevens een foreign key is naar woningId.

Wat zij willen is dat ik in flat/villa tabel een veld id toevoeg met een auto increment op waarmee ik vervolgens een unique constraint op woningId zou moeten doen. Dat lijkt mij dus overbodig.

[NMe]

Zelfs als het overbodig is, wat maakt het uit? Met unique index is het alsnog bloedsnel en hou je alsnog de mogelijkheid open dat er later alsnog huizen kunnen zijn die zowel villa als flat zijn, ook al heb je dat nu niet nodig.

[com2,1ghz]

NMe schreef op donderdag 19 januari 2012 @ 12:28:
Zelfs als het overbodig is, wat maakt het uit? Met unique index is het alsnog bloedsnel en hou je alsnog de mogelijkheid open dat er later alsnog huizen kunnen zijn die zowel villa als flat zijn, ook al heb je dat nu niet nodig.

Overal onnodige auto increments bijhouden is toch onnodig?

Bijvoorbeeld in een tussentabel hou je toch ook geen auto increment bij?

[NMe]

Je moet mij niet overtuigen maar je collega's. Als ze op jouw werk een standaard aanhouden dan heb je je daar maar bij te voegen óf je moet je collega's overtuigen. Er zijn geen echt overwegende argumenten voor elke stelling. Die autoincrement wordt door sommigen als super handig en clean gezien terwijl anderen beweren dat het onnodig en juist niet clean is.

In alle redelijkheid: wat kost het "bijhouden van een autoincrement" jou? Je database handelt dat allemaal bijzonder makkelijk en snel voor je af. Je hebt er geenszins last van.

[ Voor 20% gewijzigd door NMe op 19-01-2012 12:34 ]

[Waking_The_Dead]

Een argument voor de oplossing van je collega's is ook consistentie. Als je sowieso voor elke tabel een auto-increment gebruikt als PK, dan is dat veel gemakkelijker naar onderhoud toe. Door het gebruik van een auto-increment in combinatie met een foreign key kan iemand die eventueel na jou het project moet overnemen, veel eenvoudiger zien wat jouw bedoeling was. Door de PK van woning over te nemen in andere tabellen bezorg je jouw eventuele opvolger alleen maar last.

Voor eventuele performance moet je het in elk geval niet doen.

[com2,1ghz]

NMe schreef op donderdag 19 januari 2012 @ 12:33:
Je moet mij niet overtuigen maar je collega's. Als ze op jouw werk een standaard aanhouden dan heb je je daar maar bij te voegen óf je moet je collega's overtuigen. Er zijn geen echt overwegende argumenten voor elke stelling. Die autoincrement wordt door sommigen als super handig en clean gezien terwijl anderen beweren dat het onnodig en juist niet clean is.

In alle redelijkheid: wat kost het "bijhouden van een autoincrement" jou? Je database handelt dat allemaal bijzonder makkelijk en snel voor je af. Je hebt er geenszins last van.

Ik zit hier als stagair en als het aan hun standaard ligt dan moet ik overal een auto increment veldje opgooien want "het is handig".

Voor mijn systeemdeel wat ik moet bouwen heb ik allerlei diagrammen moeten maken waaronder een EER diagram.
Het gaat er niet om "dat het maar werkt" maar dat het op een nette wijze gebouwd wordt. Of ik heb de logica van het normaliseren niet goed begrepen. Op school werd er altijd gepusht om geen onnodige auto increment velden te hebben als dat niet nodig is

[Waking_The_Dead]

com2,1ghz schreef op donderdag 19 januari 2012 @ 12:41:
Op school werd er altijd gepusht om geen onnodige auto increment velden te hebben als dat niet nodig is

Dat was bij mij ook zo, maar na één maand in de praktijk heb ik die regel snel overboord gegooid. En nu elf jaar later ben ik daar nog steeds hartstikke blij mee ;-)

[Nukar]

Er valt veel te zeggen voor onderhoudbaarheid en herleidbaarheid (in de toekomst).Wat als de Db wordt uitgebreid? Welke consequenties heeft het niet hebben van een eigen primary key dan?

Wat als de tabellen 'villa' en 'flat' in de toekomst aan andere tabellen gekoppeld worden? Dan is de kans groot dat je via de 'woning' tabel moet linken.
Nu lijkt deze simpele toevoeging overbodig. Maar je moet vooruit kijken en rekening houden met wensen en oplossingen van de toekomst.

[com2,1ghz]

Nukar schreef op donderdag 19 januari 2012 @ 12:50:
Er valt veel te zeggen voor onderhoudbaarheid en herleidbaarheid (in de toekomst).Wat als de Db wordt uitgebreid? Welke consequenties heeft het niet hebben van een eigen primary key dan?

Wat als de tabellen 'villa' en 'flat' in de toekomst aan andere tabellen gekoppeld worden? Dan is de kans groot dat je via de 'woning' tabel moet linken.
Nu lijkt deze simpele toevoeging overbodig. Maar je moet vooruit kijken en rekening houden met wensen en oplossingen van de toekomst.

Het is zo n beetje zeker dat ook in de toekomst er niets aan veranderd zal worden. Dat weet ik zeker.

Maar ik snap jullie punt. Waar het ook om gaat is dat ik altijd een goede argument wil horen waarom ik iets wel of niet zou moeten doen wat ik altijd hoor is het volgende: "In het systeem is het zo", "is ooit zo bepaald maar weet niet waarom", "dat mag niet, waarom weet ik niet".

Ik ga er een auto increment id velt aan toevoegen met een unique constraint.

[Danot]

com2,1ghz schreef op donderdag 19 januari 2012 @ 12:55:
[...]
Het is zo n beetje zeker dat ook in de toekomst er niets aan veranderd zal worden. Dat weet ik zeker.

Ik vind het mooi om te zien dat je gedreven bent als stagair. Veel IT'ers zijn niet zo scherp bezig met databases. En dat je denkt dat er niets veranderd gaat worden is mooi, maar in de praktijk is dat nooit zo. Daarom zijn IT-projecten zo lastig. De opdrachtgever blijft zijn wensen bijstellen.

[com2,1ghz]

Danot schreef op donderdag 19 januari 2012 @ 13:01:
[...]

Ik vind het mooi om te zien dat je gedreven bent als stagair. Veel IT'ers zijn niet zo scherp bezig met databases. En dat je denkt dat er niets veranderd gaat worden is mooi, maar in de praktijk is dat nooit zo. Daarom zijn IT-projecten zo lastig. De opdrachtgever blijft zijn wensen bijstellen.

Als ik iets moet aanpassen, ookal is het niet de meest nette oplossing, dan moet ik weten waarom. Naast het bedrijf waar ik mijn project moet verantwoorden, moet ik dit ook aan mijn school doen

O wee als ik een oplossing kan bedenken die beter is dan het bestaande in het systeem als stagair

[Janoz]

com2,1ghz schreef op donderdag 19 januari 2012 @ 12:15:
[...]

Een primary key is naar mijn weten altijd uniek dus dan zou ik toch geen unique constraint voor hoeven te maken toch? Een tupel uit flat/villa identificeer ik dmv de primary key wat tevens een foreign key is naar woningId.

Ja, een PK is uniek, maar wanneer iets uniek moet zijn betekend dit niet automatisch dat het dan ook de PK moet zijn.

Wat zij willen is dat ik in flat/villa tabel een veld id toevoeg met een auto increment op waarmee ik vervolgens een unique constraint op woningId zou moeten doen. Dat lijkt mij dus overbodig.

Hoewel beide keuzes een stijl kwestie zijn vind ik de argumenten van beide kanten zwak. Zei komen idd niet verder dan 'dat is handig' maar vergeten de waarom. Jij daarentegen komt ook niet verder dan 'He, een PK is uniek en dit veld moet uniek zijn dus kunnen we die mooi bij elkaar vegen toch?'.

Wanneer ik beide keuzes voorgelegd zou krijgen zou ikzelf eerder de voorkeur hebben voor de aanpak van je collegae. De reden hiervoor is dat ik er dan in de code vanuit kan gaan dat elk record altijd zijn unieke ID in de kolom 'id' heeft staan. Hierdoor kun je erg simpel een abstracte implementatie voor een dao class maken.

Er zijn echter meer oplossingen. Wat je hier te pakken hebt is precies de mismatch tussen een relationeel model en een object georienteerd model. Eigenlijk is woning de superclass en zijn villa en appartement subclasses van woning. Hoewel dit in OO een heel simpele standaard structuur is, is dit in een relationeel model eigenlijk zeer moeilijk af te dwingen.

Een andere oplossing is bijvoorbeeld om alle velden bij de woningtabel in te stoppen. Nadeel hiervan is dat de extra velden van appartement en villa niet verplicht afgedwongen kunnen worden door de database.

[com2,1ghz]

Janoz schreef op donderdag 19 januari 2012 @ 13:23:
[...]

Ja, een PK is uniek, maar wanneer iets uniek moet zijn betekend dit niet automatisch dat het dan ook de PK moet zijn.


[...]

Hoewel beide keuzes een stijl kwestie zijn vind ik de argumenten van beide kanten zwak. Zei komen idd niet verder dan 'dat is handig' maar vergeten de waarom. Jij daarentegen komt ook niet verder dan 'He, een PK is uniek en dit veld moet uniek zijn dus kunnen we die mooi bij elkaar vegen toch?'.

Wanneer ik beide keuzes voorgelegd zou krijgen zou ikzelf eerder de voorkeur hebben voor de aanpak van je collegae. De reden hiervoor is dat ik er dan in de code vanuit kan gaan dat elk record altijd zijn unieke ID in de kolom 'id' heeft staan. Hierdoor kun je erg simpel een abstracte implementatie voor een dao class maken.

Er zijn echter meer oplossingen. Wat je hier te pakken hebt is precies de mismatch tussen een relationeel model en een object georienteerd model. Eigenlijk is woning de superclass en zijn villa en appartement subclasses van woning. Hoewel dit in OO een heel simpele standaard structuur is, is dit in een relationeel model eigenlijk zeer moeilijk af te dwingen.

Een andere oplossing is bijvoorbeeld om alle velden bij de woningtabel in te stoppen. Nadeel hiervan is dat de extra velden van appartement en villa niet verplicht afgedwongen kunnen worden door de database.

Het zit wat ingewikkelder in elkaar maar simpel gezegd, flat en villa zijn geen woningen maar hebben de superklasse genaamd Woningsoort. Één woning hoort dus bij een Woningsoort Op databaseniveau horen flat en villa bij woning maar op codeniveau doe ik er meer dingen mee wat niet woning gerelateerd is.

[NMe]

Janoz schreef op donderdag 19 januari 2012 @ 13:23:
[...]

Een andere oplossing is bijvoorbeeld om alle velden bij de woningtabel in te stoppen. Nadeel hiervan is dat de extra velden van appartement en villa niet verplicht afgedwongen kunnen worden door de database.

't Is een tijd geleden dat ik met een database gewerkt heeft die ze fatsoenlijk ondersteunde, maar constraints kunnen dat toch afdwingen?

[com2,1ghz]

NMe schreef op donderdag 19 januari 2012 @ 13:42:
[...]

't Is een tijd geleden dat ik met een database gewerkt heeft die ze fatsoenlijk ondersteunde, maar constraints kunnen dat toch afdwingen?

Ja, constraints op tabelniveau. Maar dan klopt je normalisatie niet meer .

[Anoniem: 434488]

Opa database-specialist aan het woord (15 jaar met Oracle databases).
Er zijn een paar harde vuistregels die ik deels uit het boekje en deels uit ervaring heb geleerd, en die iedere keer weer hun nut bewijzen:
- elke tabel heeft een primary key in de vorm van een unieke, betekenisloze ID. Die heet meestal ook ... ID ;-)
- zo'n ID vul je met een auto-increment, of sequence, of hoe het maar heet in jouw database. Elke primary key heeft zijn eigen auto-increment/sequence, bij voorkeur.
- elke relatie wordt door middel van een Foreign Key relatie beschreven. dus naar tabel1.ID wordt verwezen vanuit tabel2 dmv tabel2.tabel1_ID. Zo kan je ook zonder functionele kennis of documentatie 90% van een datamodel doorgronden door puur naar de kolomnamen te kijken.
- @NMe heeft gelijk dat constraints ook integriteit afdwingen. Daar zijn ze voor bedoeld en dat is NOODZAKELIJK. Zo voorkom je dat je detailrecords zonder masterrecord hebt. Of, andersom, dat je geen factuurrecord kan weggooien waar nog factuurregel-records aan hangen. Erg fijn.

Als ik naar jouw verhaal kijk (wat ik nog niet helemaal snap ;P), dan lijkt het erop alsof je woningen (die dingen van steen) in een database op wil slaan. Maar je wil de eigenschappen genormaliseerd opslaan in de vorm van woningtypes (de abstracties). Dat is zeer verstandig. als dat het geval is, lijkt de oplossing simpel:

- maak een tabel WONINGTYPE. die bevat een ID en een omschrijving
bijvoorbeeld:
ID =1 , omschrijving = 'Villa'
ID =2, omschrijving = 'Flat'

Dan maak je een tabel WONINGEN. die heeft ook een ID, en allemaal relevante velden die de woningen (die van steen en dakpannen!) beschrijven (adres, aantal kamers, etc). En een veld WONINGTYPE_ID. die heeft een FK naar WONINGTYPE. Dat is dan een 1:n relatie en is dan volgens mij prima genormaliseerd.

Mocht je meerdere woningtypes aan een woning willen kunnen koppelen, dan zul je er een tabel tussen moeten zetten om een N:M relatie te maken.

Bijvoorbeeld: tabel WONINGEN_WONINGTYPE, die een ID bevat (goh!), een WONINGTYPE_ID en een WONING_ID.
WONINGEN bevat dan geen referentie naar WONINGTYPE, maar de tabel WONINGEN_WONINGTYPE beschrijft voor elke woning welke types die kan zijn.

Kleine toevoeging: in die 'koppeltabel' kan je ook eigenschappen opslaan. Bijvoorbeeld begin- en einddatum. Dan is een zeker woning tot 1 januari een villa, en daarna een flat.

Ben ik al een beetje vaag?

[ Voor 3% gewijzigd door Anoniem: 434488 op 19-01-2012 13:57 ]

[com2,1ghz]

Anoniem: 434488 schreef op donderdag 19 januari 2012 @ 13:55:
Opa database-specialist aan het woord (15 jaar met Oracle databases).
Er zijn een paar harde vuistregels die ik deels uit het boekje en deels uit ervaring heb geleerd, en die iedere keer weer hun nut bewijzen:
- elke tabel heeft een primary key in de vorm van een unieke, betekenisloze ID. Die heet meestal ook ... ID ;-)
- zo'n ID vul je met een auto-increment, of sequence, of hoe het maar heet in jouw database. Elke primary key heeft zijn eigen auto-increment/sequence, bij voorkeur.
- elke relatie wordt door middel van een Foreign Key relatie beschreven. dus naar tabel1.ID wordt verwezen vanuit tabel2 dmv tabel2.tabel1_ID. Zo kan je ook zonder functionele kennis of documentatie 90% van een datamodel doorgronden door puur naar de kolomnamen te kijken.
- @NMe heeft gelijk dat constraints ook integriteit afdwingen. Daar zijn ze voor bedoeld en dat is NOODZAKELIJK. Zo voorkom je dat je detailrecords zonder masterrecord hebt. Of, andersom, dat je geen factuurrecord kan weggooien waar nog factuurregel-records aan hangen. Erg fijn.

Als ik naar jouw verhaal kijk (wat ik nog niet helemaal snap ;P), dan lijkt het erop alsof je woningen (die dingen van steen) in een database op wil slaan. Maar je wil de eigenschappen genormaliseerd opslaan in de vorm van woningtypes (de abstracties). Dat is zeer verstandig. als dat het geval is, lijkt de oplossing simpel:

- maak een tabel WONINGTYPE. die bevat een ID en een omschrijving
bijvoorbeeld:
ID =1 , omschrijving = 'Villa'
ID =2, omschrijving = 'Flat'

Dan maak je een tabel WONINGEN. die heeft ook een ID, en allemaal relevante velden die de woningen (die van steen en dakpannen!) beschrijven (adres, aantal kamers, etc). En een veld WONINGTYPE_ID. die heeft een FK naar WONINGTYPE. Dat is dan een 1:n relatie en is dan volgens mij prima genormaliseerd.

Mocht je meerdere woningtypes aan een woning willen kunnen koppelen, dan zul je er een tabel tussen moeten zetten om een N:M relatie te maken.

Bijvoorbeeld: tabel WONINGEN_WONINGTYPE, die een ID bevat (goh!), een WONINGTYPE_ID en een WONING_ID.
WONINGEN bevat dan geen referentie naar WONINGTYPE, maar de tabel WONINGEN_WONINGTYPE beschrijft voor elke woning welke types die kan zijn.

Kleine toevoeging: in die 'koppeltabel' kan je ook eigenschappen opslaan. Bijvoorbeeld begin- en einddatum. Dan is een zeker woning tot 1 januari een villa, en daarna een flat.

Ben ik al een beetje vaag?

Nou zie ik dat mn voorbeeld krom is maar dit zijn de echte gegevens:
Ik moet het volgende doen:

Enquete(id, naam, vragenlijsttemplateid)

agendaEnquete(enqueteid, type, status)

Ik moet een enquetesysteem maken voor een bestaand agendamodule waar ik een type en status van nodig heb. Het gaat er ook om dat dit enquetesysteem generiek moet zijn dat er in de toekomst ook een mogelijkheid moet komen om een andere module dan de agenda toe te voegen.

Ieder gebruiker van het systeem heeft een eigen definitie voor een type en status in de agenda en deze dienen gekoppeld te worden wanneer ik bij het creeren van een enquete aangeef dat het een enquete moet zijn voor de agenda.
Dus voor de duidelijkheid:
User jan heeft de volgende typen: Vrij, Bezoek aan klant, Ziek
User jan heeft de volgende statussen: definitief, geannuleerd, overig

User piet heeft de volgende typen: Verlof, Klantenbezoek, afwezig
User piet heeft de volgende statussen: Ok, geannuleerd

In de database is agendaEnquete een enquete. In de code is agendaEnquete iets waarmee ik alle typen en statussen van de huidige gebruiker kan opvragen en deze in de enquete kan koppelen.

Dus jan maakt een enquete aan, hierin geeft hij aan dat het een agendaEnquete. Wanneer dit wordt aangegeven, gaat jan een type en een status meegeven. Bij het opslaan van de enquete, wordt er ook in de agendaEnquete tabel de enqueteId, typeId en statusId opgeslagen.

[Anoniem: 434488]

Begrijp ik dus goed dat iedere gebruiker zijn eigen set van statussen heeft? en wat de een "verlof" noemt, de ander als "vrij" vastlegt? What a mess...
klinkt alsof je dat met een N:M relatie op moet lossen. Als dat echt is wat de gebruikers willen (maar ik betwijfel het).
Maar in dat geval sla je in één tabel alle mogelijke types op (vrij, verlof, afwezig etc), En dan maak je zo'n koppeltabel enquete_type (bijvoorbeeld) met een enquete_id en een type_id.
dan krijg je dus:

code:

TYPES
ID      BESCHRIJVING
1       Vrij
2       Bezoek aan klant
3       Klantenbezoek
.....   .....

USER
ID    NAAM
10    Jan
20    Piet

ENQUETE_TYPE
ID     USER_ID   TYPE_ID
5      10              1
6      10              2
7      20              3

Jouw situatie is duidelijk wat complexer (sorry, geen zin het helemaal te doorgronden ), maar dit soort constructies moeten jou wel gaan helpen de boel gedegen te modelleren.

Overigens valt me op dat veel mensen een OO achtergrond hebben en ook op die manier de database proberen te modelleren. Geloof me, dat werkt niet zo. Een datamodel modelleer je anders. Je zal in je API of transformatielaag of hoe je het dan ook noemt de vertaalslag tussen datamodel en objectmodel moeten maken. En dat vergt een andere manier van denken.

[com2,1ghz]

Anoniem: 434488 schreef op donderdag 19 januari 2012 @ 14:35:
Begrijp ik dus goed dat iedere gebruiker zijn eigen set van statussen heeft? en wat de een "verlof" noemt, de ander als "vrij" vastlegt? What a mess...
klinkt alsof je dat met een N:M relatie op moet lossen. Als dat echt is wat de gebruikers willen (maar ik betwijfel het).
Maar in dat geval sla je in één tabel alle mogelijke types op (vrij, verlof, afwezig etc), En dan maak je zo'n koppeltabel enquete_type (bijvoorbeeld) met een enquete_id en een type_id.
dan krijg je dus:

code:

TYPES
ID      BESCHRIJVING
1       Vrij
2       Bezoek aan klant
3       Klantenbezoek
.....   .....

USER
ID    NAAM
10    Jan
20    Piet

ENQUETE_TYPE
ID     USER_ID   TYPE_ID
5      10              1
6      10              2
7      20              3

Jouw situatie is duidelijk wat complexer (sorry, geen zin het helemaal te doorgronden ), maar dit soort constructies moeten jou wel gaan helpen de boel gedegen te modelleren.

Overigens valt me op dat veel mensen een OO achtergrond hebben en ook op die manier de database proberen te modelleren. Geloof me, dat werkt niet zo. Een datamodel modelleer je anders. Je zal in je API of transformatielaag of hoe je het dan ook noemt de vertaalslag tussen datamodel en objectmodel moeten maken. En dat vergt een andere manier van denken.

code:

AGENDATYPES
ID  USERID     BESCHRIJVING
1       10          Vrij
2       10          Bezoek aan klant
3       10          Klantenbezoek


AGENDASTATUS
ID  USERID     BESCHRIJVING
1       10          definitief
2       10          geannuleerd
3       10          overige

USER
ID    NAAM
10    Jan
20    Piet


ENQUETE
ID   USERID    NAAM                               VRAGENLIJSTTEMPLATEID
1    10             Kwaliteitmeting                  84
2    20             Algemeen dienstverlening   45
3    10             Overig iets                          99

AGENDAENQUETE
ENQUETEID    TYPE   STATUS
1             1       3

Dus jan wilt een enquete aanmaken die bedoeld is voor de agenda.
Jan krijgt een scherm waarmee hij een enquete kan aanmaken maar met agenda specifieke velden. Dat zijn dus agendatype en agenda status.

Jan kiest agendatype "Vrij", dat is dus ID=1 en de status Overig en dat is ID=3.

Enquete wordt opgeslagen in ENQUETE, en in AGENDAENQUETE

In AGENDAENQUETE hou ik dus bij dat deze tupen ALLEEN bij deze enquete hoort en nooit bij iets anders.


edit:
Dus doordat ik geen standaard gedefinieerde agendatype en agendastatus heb, kan ik in de tabel ENQUETE geen foreign key hebben naar AGENDAENQUETE.

En daarom heb ik dus de enqueteid als primary key van agendaenquete. Collega zegt dat er in deze tabel een auto increment id moet komen, ik vind van niet. Vandaar dat ik dus hiermee zat

[ Voor 6% gewijzigd door com2,1ghz op 19-01-2012 14:54 ]

[Remus]

com2,1ghz schreef op donderdag 19 januari 2012 @ 11:47:
Beste Tweakers,

Nou heb ik op mn werk te maken met mensen die denken het beter te weten zonder een onderbouwd argument en graag zou ik van jullie raad willen weten.

Situatie:

Ik heb 3 tabellen bedacht om mijn situatie te verduidelijken:
woning(id, naam, adres,)

flat(woningId, verdieping, lift)

villa(woningId, perceeloppervlakte)

Het gaat er om dat een woning of een flat kan zijn of een villa

De cardinaliteit is als volgt:
Een woning kan of een flat zijn of een villa.
Wanneer deze woning wordt opgeslagen, wordt bij de bijbehorende flat/villa tabel de gegevens meegeschreven. De flat/villa hebben beide hun primary key als foreign key naar woning.

Een flat of villa kan dus niet alleen bestaan.

Nou moeten we even niet nadenken over 1 woning die een flat EN een villa is. Het is altijd 1 of het ander en dat is al afgevangen in de code. Het gaat er om dat ik een woning kan aanmaken zonder dat ik weet wat voor soort het is en achteraf een soort kan koppelen.

Nou beweren mn collegas dat ik dit niet mag doen omdat er overal een ID moet komen met auto_increment.
Ik ben het hiermee niet mee eens omdat ik wil afdwingen dat het nooit mogelijk mag zijn dat 1 woning meerdere keer voorkomt in flat/villa tabel.

Is het nou fout dat ik de primary key van woning gebruik als primary key voor flat/villa tabel?

Persoonlijk zou ik in de subtables als primary key de foreign key naar de supertable nemen (en evt geen eigen primary key en maar een unique key constraint die not null is).
Waarom: Het bestaan van de subtable is volledig afhankelijk van de supertable (en omdat een row in de subtable geen aparte betekenis heeft zonder het bestaan van de overeenkomstige row in de supertable). Dus wat mij betreft geen aparte autoincremented id voor de subtables.

Als je PostgreSQL gebruikt, dan kan je overigens table inheritance gebruiken: http://www.postgresql.org/docs/8.1/static/ddl-inherit.html (al zitten daar wel een aantal haken enogen aan, bijvoorbeeld mbt foreign keys).

[com2,1ghz]

Remus schreef op donderdag 19 januari 2012 @ 15:04:
[...]

Persoonlijk zou ik in de subtables als primary key de foreign key naar de supertable nemen (en evt geen eigen primary key en maar een unique key constraint die not null is).
Waarom: Het bestaan van de subtable is volledig afhankelijk van de supertable (en omdat een row in de subtable geen aparte betekenis heeft zonder het bestaan van de overeenkomstige row in de supertable). Dus wat mij betreft geen aparte autoincremented id voor de subtables.

Als je PostgreSQL gebruikt, dan kan je overigens table inheritance gebruiken: http://www.postgresql.org/docs/8.1/static/ddl-inherit.html (al zitten daar wel een aantal haken enogen aan, bijvoorbeeld mbt foreign keys).

Dat heb ik nu dus. De subtable heeft als primary key een foreign key naar de supertable. Collegas beweren dus dat dit niet goed is.

[Remus]

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:09:
[...]

Dat heb ik nu dus. De subtable heeft als primary key een foreign key naar de supertable. Collegas beweren dus dat dit niet goed is.

Maar wat zijn hun argumenten daarvoor?

[com2,1ghz]

Remus schreef op donderdag 19 januari 2012 @ 15:23:
[...]

Maar wat zijn hun argumenten daarvoor?

Nou beweren mn collegas dat ik dit niet mag doen omdat er overal een ID moet komen met auto_increment.
Ik ben het hiermee niet mee eens omdat ik wil afdwingen dat het nooit mogelijk mag zijn dat 1 woning meerdere keer voorkomt in flat/villa tabel.

[NMe]

Dat zijn geen argumenten. Belangrijker: wat zijn jouw standpunten tegen en waarom verspil je zoveel tijd aan deze non-issue? Nogmaals, als ál jouw collega's roepen dat het zo moet en jij geen standhoudende tegenargumenten hebt, dan zijn dit gewoon hun standaarden waar jij je aan moet houden als werknemer/stagiair in hetzelfde bedrijf.

Er zijn geen goede redenen vóór en geen goede redenen tégen het gebruiken van die extra key, en dat is in dit topic nu al een paar keer gezegd. Bij keuzes die persoonlijk zijn heb je je maar te voegen aan de standaarden binnen het bedrijf waarin je werkt.

[com2,1ghz]

NMe schreef op donderdag 19 januari 2012 @ 15:25:
Dat zijn geen argumenten. Belangrijker: wat zijn jouw standpunten tegen en waarom verspil je zoveel tijd aan deze non-issue? Nogmaals, als ál jouw collega's roepen dat het zo moet en jij geen standhoudende tegenargumenten hebt, dan zijn dit gewoon hun standaarden waar jij je aan moet houden als werknemer/stagiair in hetzelfde bedrijf.

Er zijn geen goede redenen vóór en geen goede redenen tégen het gebruiken van die extra key, en dat is in dit topic nu al een paar keer gezegd. Bij keuzes die persoonlijk zijn heb je je maar te voegen aan de standaarden binnen het bedrijf waarin je werkt.

Ok dat snap ik, maar in mijn afstudeerverslag kan ik niet deze keuze beargumenteren door te zeggen "ja zo doet het bedrijf het". Dat kan in geen enkel project. Jij gaat niet dingen doen omdat "hij het zegt" maar omdat er een reden achter zit. En die reden is in deze situatie "het is zo in het systeem maar waarom weten we niet".

Daar kan ik dus niets mee en daardoor heb ik dit topic om aan jullie, de experts te vragen waarom mijn keuze voor dit niet goed zou zijn.

[NMe]

In je afstudeerverslag hoef je ongetwijfeld niet zó gedetailleerd op je keuze in te gaan. Ze verwachten op je school echt niet dat je van elk veld uitlegt waarom je dat veld hebt gemaakt en waarom in die vorm. Op het moment dat je tijdens of na je presentatie de vraag krijgt waarom je het zo gedaan hebt dan kun je zeggen dat je dat verzoek hebt gekregen van je collega's en dat je geen reden zag om het niet te doen omdat het performancetechnisch geen probleem is en zelfs in de toekomst ruimte biedt om makkelijk de requirements aan te passen zodat een woning wel tegelijk een villa én een flat kan zijn.

[Anoniem: 434488]

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:34:
[...]

Ok dat snap ik, maar in mijn afstudeerverslag kan ik niet deze keuze beargumenteren door te zeggen "ja zo doet het bedrijf het". Dat kan in geen enkel project. Jij gaat niet dingen doen omdat "hij het zegt" maar omdat er een reden achter zit. En die reden is in deze situatie "het is zo in het systeem maar waarom weten we niet".

Daar kan ik dus niets mee en daardoor heb ik dit topic om aan jullie, de experts te vragen waarom mijn keuze voor dit niet goed zou zijn.

Een beetje eigenwijsheid bespeur ik wel bij je

Even los van de oplossing, de dogma's zoals ik die noemde zijn er niet voor niets. Zo wordt het al tientallen jaren binnen DBMS-en gedaan en het is bewezen dat dit een robuuste en onderhoudbare oplossing oplevert. Met alle respect, jij mist nog de ervaring om dat te in te zien. Komt nog wel als het goed is
Ik zou niet in je afstudeerverslag zetten "ja zo doet het bedrijf het" inderdaad. Je kan wel verwijzen naar de heersende standaarden en best practices. Wellicht moet je nog wat research doen naar de op dit moment geldende standaarden. Geen stagebegeleider die je dat kwalijk zal nemen gok ik,

NME en ik zitten aardig op één lijn zie ik. ghehe.

[Remus]

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:34:
[...]

Ok dat snap ik, maar in mijn afstudeerverslag kan ik niet deze keuze beargumenteren door te zeggen "ja zo doet het bedrijf het". Dat kan in geen enkel project. Jij gaat niet dingen doen omdat "hij het zegt" maar omdat er een reden achter zit. En die reden is in deze situatie "het is zo in het systeem maar waarom weten we niet".

Daar kan ik dus niets mee en daardoor heb ik dit topic om aan jullie, de experts te vragen waarom mijn keuze voor dit niet goed zou zijn.

Ik zou eerst proberen je collega's zo ver te krijgen om uit te leggen waarom ze vinden dat er een aparte auto-increment id op de subtable moet ipv het dogmatisch 'het moet omdat we het zo doen'. Geven ze geen aanvullende uitleg, dan zou ik gewoon in het verslag opnemen dat je deze oplossingsrichting gekozen hebt omdat dat onderdeel is van de database/design/coding standards van het bedrijf.

NMe schreef op donderdag 19 januari 2012 @ 15:42:
Op het moment dat je tijdens of na je presentatie de vraag krijgt waarom je het zo gedaan hebt dan kun je zeggen dat je dat verzoek hebt gekregen van je collega's en dat je geen reden zag om het niet te doen omdat het performancetechnisch geen probleem is en zelfs in de toekomst ruimte biedt om makkelijk de requirements aan te passen zodat een woning wel tegelijk een villa én een flat kan zijn.

Dat kan met de andere oplossing ook. Het specifiek type wordt over het algemeen aangegeven met een type-discriminator in de supertable (en dus kan je dan maar één type zijn).

Anoniem: 434488 schreef op donderdag 19 januari 2012 @ 15:50:
Even los van de oplossing, de dogma's zoals ik die noemde zijn er niet voor niets. Zo wordt het al tientallen jaren binnen DBMS-en gedaan en het is bewezen dat dit een robuuste en onderhoudbare oplossing oplevert.

Ik denk niet dat je blanket kan zeggen 'Zo wordt het al jaren [...] gedaan'. Beide oplossingen worden gebruikt en beide hebben hun voors en tegens, maar geen is per definitie fout of beter.

[ Voor 13% gewijzigd door Remus op 19-01-2012 15:54 ]

[com2,1ghz]

Anoniem: 434488 schreef op donderdag 19 januari 2012 @ 15:50:
[...]

Een beetje eigenwijsheid bespeur ik wel bij je

Even los van de oplossing, de dogma's zoals ik die noemde zijn er niet voor niets. Zo wordt het al tientallen jaren binnen DBMS-en gedaan en het is bewezen dat dit een robuuste en onderhoudbare oplossing oplevert. Met alle respect, jij mist nog de ervaring om dat te in te zien. Komt nog wel als het goed is
Ik zou niet in je afstudeerverslag zetten "ja zo doet het bedrijf het" inderdaad. Je kan wel verwijzen naar de heersende standaarden en best practices. Wellicht moet je nog wat research doen naar de op dit moment geldende standaarden. Geen stagebegeleider die je dat kwalijk zal nemen gok ik,

NME en ik zitten aardig op één lijn zie ik. ghehe.

Destijds tijdens de databaselessen ben ik afgebrand door het feit dat ik op ieder tabel een a_i id bijhield en ik twee keer moest nadenken voordat ik zo n a_i veldje zou moeten toevoegen. Geloof me, ik word hierop afgerekend als ik keuzes ga nemen waar ik niet achter sta.

Ik respecteer de keuzes van de experts, maar dan moet er echt een argument komen waarvan ik zeg nou dat is een goede reden waarom het wel of niet anders kan.

Niet omdat ik eigenwijs ben, maar ik hou er niet van om dingen te doen waarvan ik niet weet waarom het zo is.

[Anoniem: 434488]

Remus schreef op donderdag 19 januari 2012 @ 15:51:

Ik denk niet dat je blanket kan zeggen 'Zo wordt het al jaren [...] gedaan'. Beide oplossingen worden gebruikt en beide hebben hun voors en tegens, maar geen is per definitie fout of beter.

Ik wil zeker niet de indruk wekken dat 'mijn' werkwijze de enige juiste is. Ik heb wel een voorkeur laten we daar maar niet aan gaan discussieren want dan wordt het een latertje vandaag!

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:57:
[...]

Destijds tijdens de databaselessen ben ik afgebrand door het feit dat ik op ieder tabel een a_i id bijhield en ik twee keer moest nadenken voordat ik zo n a_i veldje zou moeten toevoegen. Geloof me, ik word hierop afgerekend als ik keuzes ga nemen waar ik niet achter sta.

Het is hier al eerder gezegd geloof ik, maar wat je op school leert staat vaak haaks op de realiteit. Helaas.
Overigens zit er wel een kern van waarheid in dat twee keer nadenken... "zomaar" allerlei id's en tellertjes toevoegen is natuurlijk ook niet zinvol.

Ik respecteer de keuzes van de experts, maar dan moet er echt een argument komen waarvan ik zeg nou dat is een goede reden waarom het wel of niet anders kan.

*pakt handschoen op* op welke keuze zoek je argumenten? om ergens juist wel altijd een id voor te plakken? Daar wil ik dan nog wel op ingaan.

Niet omdat ik eigenwijs ben, maar ik hou er niet van om dingen te doen waarvan ik niet weet waarom het zo is.

Prima instelling hoor. Altijd blijven vragen. Het liefst open vragen hè

[NMe]

Het belangrijkste voordeel van hun methode is, zoals al eerder gezegd in dit topic, consistentie. Het is fijn als elke tabel een eigen ID-veld heeft zodat je een row altijd makkelijk kan terugvinden op basis van hetzelfde criterium.

En als je een goed argument wil hebben om vooral zo'n ID te gebruiken: je stagebegeleiders bij het bedrijf zelf hebben je dat gevraagd. Wil je bij hun bekend staan als die eigenwijze student die niks aanneemt van een ervaren programmeur of als iemand die weliswaar vraagt waarom maar bij gebrek aan tegenargumenten toch meegaat met wat zijn collega's zeggen? Voor een deel is het ook gewoon hoe je over wil komen...

[Janoz]

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:34:
[...]

Ok dat snap ik, maar in mijn afstudeerverslag kan ik niet deze keuze beargumenteren door te zeggen "ja zo doet het bedrijf het". Dat kan in geen enkel project. Jij gaat niet dingen doen omdat "hij het zegt" maar omdat er een reden achter zit. En die reden is in deze situatie "het is zo in het systeem maar waarom weten we niet".

Daar kan ik dus niets mee en daardoor heb ik dit topic om aan jullie, de experts te vragen waarom mijn keuze voor dit niet goed zou zijn.

Maar je hebt op dit moment ook nog steeds geen steekhoudend tegenargument gegeven welke je in je verslag kunt zetten om te onderbouwen waarom je het anders hebt gedaan dan in het stagebedrijf gebruikelijk is. Op dit moment is de situatie gewoon niet anders dan hun woord tegen het jouwe, en frankly zou ik dergelijke eigenwijsheid eerder 'afstraffen' in een verslag (maar dat is mijn persoonlijke mening).

NMe schreef op donderdag 19 januari 2012 @ 13:42:
[...]

't Is een tijd geleden dat ik met een database gewerkt heeft die ze fatsoenlijk ondersteunde, maar constraints kunnen dat toch afdwingen?

Kan vast, maar hij is een stuk ingewikkelder dan een standaard 'not null'. Het verplicht zijn van het ene veld is immers afhankelijk van de vulling van een ander veld (de discriminator) in het zelfde record.

[Remus]

Janoz schreef op donderdag 19 januari 2012 @ 16:26:
Kan vast, maar hij is een stuk ingewikkelder dan een standaard 'not null'. Het verplicht zijn van het ene veld is immers afhankelijk van de vulling van een ander veld (de discriminator) in het zelfde record.

Als de database CHECK constraints (en/of triggers) ondersteunt is het op zich geen probleem. Alleen als je erg veel velden hebt die afhankelijk van de discriminator geen waarde mogen hebben (of juist een waarde moeten hebben) dan komt dat de onderhoudbaarheid en waarschijnlijk ook de performance niet ten goede.

[com2,1ghz]

Janoz schreef op donderdag 19 januari 2012 @ 16:26:
[...]

Maar je hebt op dit moment ook nog steeds geen steekhoudend tegenargument gegeven welke je in je verslag kunt zetten om te onderbouwen waarom je het anders hebt gedaan dan in het stagebedrijf gebruikelijk is. Op dit moment is de situatie gewoon niet anders dan hun woord tegen het jouwe, en frankly zou ik dergelijke eigenwijsheid eerder 'afstraffen' in een verslag (maar dat is mijn persoonlijke mening).


[...]

Kan vast, maar hij is een stuk ingewikkelder dan een standaard 'not null'. Het verplicht zijn van het ene veld is immers afhankelijk van de vulling van een ander veld (de discriminator) in het zelfde record.

Ik snap nu niet waar het woord eigenwijsheid nou vandaan komt.

Ik heb de keuze genomen om de primary key van een tabel meteen een foreign key te maken naar een ander tabel om zo de kardinaliteit af te dwingen. Het is op geen enkel manier mogelijk om nu 1 enquete te hebben die 2 keer voorkomt in agendaEnquete. Als iemand dan beweert dat het fout is om het zo te doen omdat er een a_i veld op moet komen, dan wil ik ook weten waarom.

Ik kreeg als reden dat er een auto incrementent veld moest komen en een unique constraint kon doen. Dan denk ik ja maar wat is het nut van die a_i veld dan? Is het dan niet onnodig dat ik die dan in zet?
Dingen als "dat is ooit zo bepaald", "het systeem wilt het zo, waarom weet ik niet" heb ik dus niets aan.

En daarom dacht ik het even hier te vragen zodat ik het echt zeker weet. Als stagair zijnde leer ik ook van alles door het te begrijpen, en niet over te nemen.

[Grijze Vos]

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:34:
[...]

Ok dat snap ik, maar in mijn afstudeerverslag kan ik niet deze keuze beargumenteren door te zeggen "ja zo doet het bedrijf het". Dat kan in geen enkel project. Jij gaat niet dingen doen omdat "hij het zegt" maar omdat er een reden achter zit. En die reden is in deze situatie "het is zo in het systeem maar waarom weten we niet".

Daar kan ik dus niets mee en daardoor heb ik dit topic om aan jullie, de experts te vragen waarom mijn keuze voor dit niet goed zou zijn.

Tuurlijk kan je dat wel zeggen: "De keuze tussen X en Y is triviaal, er zijn geen zwaarwegende argumenten voor eender welke methode. Vanwege consistentie met andere code van het bedrijf is gekozen voor X."

[Janoz]

com2,1ghz schreef op donderdag 19 januari 2012 @ 16:37:
Ik snap nu niet waar het woord eigenwijsheid nou vandaan komt.

eigenwijs hoort eigenlijk ook tussen aanhalingstekens, maar het komt omdat je het graag anders wilt doen dan gebruikelijk binnen de omgeving waar je opereert, zonder dat je dat kunt onderbouwen.

Ik heb de keuze genomen om de primary key van een tabel meteen een foreign key te maken naar een ander tabel om zo de kardinaliteit af te dwingen. Het is op geen enkel manier mogelijk om nu 1 enquete te hebben die 2 keer voorkomt in agendaEnquete. Als iemand dan beweert dat het fout is om het zo te doen omdat er een a_i veld op moet komen, dan wil ik ook weten waarom.

De waarom vraag is uitstekend. Dat zul je ook zeker niet af moeten leren. Dat je collegae dat niet kunnen onderbouwen is vervolgens wel een manko van die collegae. Zij hebben immers ooit het besluit genomen om het op die manier te doen en het is te hopen dat er toen een afweging gemaakt is.

Ik kreeg als reden dat er een auto incrementent veld moest komen en een unique constraint kon doen. Dan denk ik ja maar wat is het nut van die a_i veld dan? Is het dan niet onnodig dat ik die dan in zet?
Dingen als "dat is ooit zo bepaald", "het systeem wilt het zo, waarom weet ik niet" heb ik dus niets aan.

Wanneer je in een situatie terecht komt die twee oplossingen heeft dan zijn "dat is ooit zo bepaald" juist een heel sterk argument. Het zorgt voor consistentie in de ontwikkelde producten. Je zult op dat moment juist met een sterk argument moeten komen waarom daar vanaf geweken moet worden. En die argumenten heb je niet.

Een extra veld is misschien niet netjes, maar de dubbele functie die je aan de PK geeft is dat IMHO ook niet.

En daarom dacht ik het even hier te vragen zodat ik het echt zeker weet. Als stagair zijnde leer ik ook van alles door het te begrijpen, en niet over te nemen.

Weer helemaal correct. Het staat je juist te prijzen dat je je niet zomaar neerlegt bij de gebaande paden. Ik zeg ook niet dat je eigen idee slechter (of beter) is dan het idee dat binnen het bedrijf leeft.

[EfBe]

com2,1ghz schreef op donderdag 19 januari 2012 @ 11:47:
Nou heb ik op mn werk te maken met mensen die denken het beter te weten zonder een onderbouwd argument en graag zou ik van jullie raad willen weten.

Situatie:

Ik heb 3 tabellen bedacht om mijn situatie te verduidelijken:
woning(id, naam, adres,)

flat(woningId, verdieping, lift)

villa(woningId, perceeloppervlakte)

Het gaat er om dat een woning of een flat kan zijn of een villa

De cardinaliteit is als volgt:
Een woning kan of een flat zijn of een villa.
Wanneer deze woning wordt opgeslagen, wordt bij de bijbehorende flat/villa tabel de gegevens meegeschreven. De flat/villa hebben beide hun primary key als foreign key naar woning.

Een flat of villa kan dus niet alleen bestaan.

Nou moeten we even niet nadenken over 1 woning die een flat EN een villa is. Het is altijd 1 of het ander en dat is al afgevangen in de code. Het gaat er om dat ik een woning kan aanmaken zonder dat ik weet wat voor soort het is en achteraf een soort kan koppelen.

Nou beweren mn collegas dat ik dit niet mag doen omdat er overal een ID moet komen met auto_increment.
Ik ben het hiermee niet mee eens omdat ik wil afdwingen dat het nooit mogelijk mag zijn dat 1 woning meerdere keer voorkomt in flat/villa tabel.
Is het nou fout dat ik de primary key van woning gebruik als primary key voor flat/villa tabel?

Hoe jij het hierboven schetst met die 3 tabellen is de juiste manier wanneer je je entity inheritance hierarchy converteert naar 1 tabel per entity type. Er is nog een andere manier, en die houdt in dat je 1 tabel maakt en alle types daarin plaatst, subtype velden worden dan nullable. Het gaat hier duidelijk om een inheritance hierarchy, flat en villa zijn immers subtypes van woning.

Deze thread is al erg lang dus ik weet niet of het al gezegd is, zag wel dat mensen in deze thread beweren dat je een aparte PK op de subtype tables had moeten plaatsen. Ik begrijp wel waarom men dat denkt (men gebruikt bv een brakke O/R mapper die het niet aankan, of men denkt dat een entity model gelijk staat aan een bak met tabellen), maar ik snap alleen niet waarom zij dat beweren wanneer de theorie duidelijk voorschrijft iets anders te doen.

Zie Conceptual Schema and Relational Database Design -- G.M Nijssen & T.A. Halpin. Page 264 en verder.

Jouw collega's snappen het dus niet en jij wel. Komt vaker voor hoor, dat mensen de ballen verstand hebben van relational modeling en direct tables gaan zitten definieren voor een domain zonder te kijken naar het abstract entity model wat altijd ten grondslag ligt aan een relational model. Immers een relational model is een projectie van een abstract entity model.

Overigens zou het goed zijn dat een paar mensen in deze thread het bovenstaande boek weer eens (of voor het eerst) gingen doornemen. . Het is behoorlijk droge drek, dat boek, maar het is wel een van DE werken op het gebied van relational modeling.

Oh en 'Driven by rage', prima dat je 15 jaar db ervaring hebt, het gaat erom of je de theorie erachter snapt, niet 'hoe men het altijd doet'. Ik begrijp best dat alle tabellen een betekenisloze ID krijgen in jouw databases, dat betekent niet dat het de juiste manier is in dit geval of in sommige andere gevallen. Sterker, je daar mee bezig houden is een teken dat je je relational model niet aan de hand van een entity model maakt maar direct als basis ziet. Concepts als entity inheritance zie je dan niet want 'inheritance' is niet iets wat normaliter in database schemas direct te modelleren is als 'deze tabel is een subtype van die tabel'. (sommige RDBMS'en hebben er statements voor, maar dat daargelaten).

* EfBe -- 18 jaar DB ervaring

[ Voor 13% gewijzigd door EfBe op 20-01-2012 10:24 ]

[NMe]

Een brakke O/R-mapper is een prima reden om het juist wel te doen.

Theorie is leuk hoor, maar soms wijst de praktijk uit dat je ergens anders voor moet kiezen. Ook jij noemt geen echte reden om géén extra key op te nemen; "het is rommelig" is géén reden als het aan de applicatiekant zaken makkelijker maakt zonder nadelen te hebben voor de performance van je DB. Sowieso is het al helemaal niet aan een stagiair om de stijlregels binnen een bedrijf te herschrijven op basis van vage persoonlijke voorkeuren.

[Waking_The_Dead]

EfBe schreef op vrijdag 20 januari 2012 @ 10:02:
Deze thread is al erg lang dus ik weet niet of het al gezegd is, zag wel dat mensen in deze thread beweren dat je een aparte PK op de subtype tables had moeten plaatsen. Ik begrijp wel waarom men dat denkt (men gebruikt bv een brakke O/R mapper die het niet aankan, of men denkt dat een entity model gelijk staat aan een bak met tabellen), maar ik snap alleen niet waarom zij dat beweren wanneer de theorie duidelijk voorschrijft iets anders te doen.

Wat de theorie voorschijft is allemaal goed en wel maar dat is gewoon niet praktisch imo.
Als je op een project werkt met (zoals ik nu) 700 tabellen dan is het gewoon een must om standaarden af te spreken. En die standaard bij ons is dat de PK van elke tabel een auto-increment is met een vaste naam: "ID_<tabelnaam>". Dat is voor zowel de DBA, de ontwikkelaars en analysten de handigste oplossing. Het custom framework houdt rekening met die conventie en dat werkt echt wel zeer vlot.

Als je voor elke tabel de theorie volgens de letter toepast dan is je project gedoemd omdat het totaal niet onderhoudbaar is.

[NMe]

De theorie schrijft ook de derde normaalvorm voor, terwijl de meesten van ons na die derde normaalvorm nog wel eens gaan kijken wat er aan performance te winnen valt door te denormaliseren en in de vierde of vijfde normaalvorm te eindigen. Heck, ik werk nu toevallig aan een project waarin ik 4 enorme tabellen in de eerste normaalvorm heb moeten houden omdat de aard van de data de performance van de app met genormaliseerde data met een factor 30 vertraagde.

Theorie is leuk, maar common sense is leuker.

[EfBe]

NMe schreef op vrijdag 20 januari 2012 @ 12:12:
Een brakke O/R-mapper is een prima reden om het juist wel te doen.

Theorie is leuk hoor, maar soms wijst de praktijk uit dat je ergens anders voor moet kiezen. Ook jij noemt geen echte reden om géén extra key op te nemen; "het is rommelig" is géén reden als het aan de applicatiekant zaken makkelijker maakt zonder nadelen te hebben voor de performance van je DB. Sowieso is het al helemaal niet aan een stagiair om de stijlregels binnen een bedrijf te herschrijven op basis van vage persoonlijke voorkeuren.

Ik noem ook geen reden om roze olifantjes toe te passen. Ik noem juist een reden om het wel te doen, nl. de reden die is beschreven in theorie, bewezen door 2 toonaangevende professoren op dit gebied.

Dat je het juist anders wilt doen moet je uiteraard zelf weten. De TS vroeg wat juist was, ik heb dat aangegeven. Een aparte PK is niet juist, temeer omdat je dan 2 aparte PKs hebt in 1 entity, nl. de PK in woning en de PK in de subtype table. 2 PKs om 1 entity aan te duiden is redundant: de 2e kan weg, want die voegt niets toe, de 1e is al genoeg om de entity instance uniek te herkennen.

Je praat over performance, maar je faalt om het op dit specifieke probleem toe te passen . Inheritance over meerdere tabellen verdelen kan nadelen hebben mbt performance, daarom wordt soms gekozen voor het 'platslaan' van de hierarchy tot 1 tabel met een discriminator column die het type aangeeft van de entity instance in een row. Jouw nieuwe PK in de subtype tables hebben geen moer met performance te maken, sterker nog, de code wordt complexer hierdoor en dat geeft alleen maar narigheid.

Waking_The_Dead schreef op vrijdag 20 januari 2012 @ 12:21:
[...]
Wat de theorie voorschijft is allemaal goed en wel maar dat is gewoon niet praktisch imo.

Tja, als jij maar wat raak wilt prutsen zonder enige theoretische basis, mijn zegen heb je. Het is alleen niet echt nuttig. Je bent het toch met me eens dat als ABC op 2 manieren getransformeerd kan worden naar database tabellen, jij niet met een 3e aan kan komen, want er zijn maar 2 manieren? Waarom zou je ook met een 3e manier aan moeten komen als er al 2 zijn?

Als je op een project werkt met (zoals ik nu) 700 tabellen dan is het gewoon een must om standaarden af te spreken. En die standaard bij ons is dat de PK van elke tabel een auto-increment is met een vaste naam: "ID_<tabelnaam>". Dat is voor zowel de DBA, de ontwikkelaars en analysten de handigste oplossing. Het custom framework houdt rekening met die conventie en dat werkt echt wel zeer vlot.

Lijkt me een beetje een onzinnige standaard. Ten eerste is de naam vastleggen in de PK niet echt handig (table rename) en overbodig (je weet in welke table hij zit, je plaatst toch ook niet de tabelnaam achter ieder andere veld?), en ten tweede is het niet nuttig bij inheritance hierarchien. Daar _is_ een standaard voor, nl. die ik beschreven heb. Dat jullie standaard daar niet in voorziet is een teken dat die standaard van jullie dus niet helemaal correct is. Dat hoeft niet slecht te zijn, maar als jullie inheritance hierarchien gebruiken loop je wel tegen problemen op.

Als je voor elke tabel de theorie volgens de letter toepast dan is je project gedoemd omdat het totaal niet onderhoudbaar is.

Niet zelf stellingen gaan verzinnen die je niet zelf kunt waarmaken. Het toepassen van bewezen theorieen is juist wel onderhoudbaar, want je weet dat wat is toegepast ook werkt. Dat hebben anderen nl. al voor je uitgezocht.

[ Voor 36% gewijzigd door EfBe op 20-01-2012 13:03 ]

[Janoz]

NMe schreef op vrijdag 20 januari 2012 @ 12:31:
De theorie schrijft ook de derde normaalvorm voor, terwijl de meesten van ons na die derde normaalvorm nog wel eens gaan kijken wat er aan performance te winnen valt door te denormaliseren en in de vierde of vijfde normaalvorm te eindigen. Heck, ik werk nu toevallig aan een project waarin ik 4 enorme tabellen in de eerste normaalvorm heb moeten houden omdat de aard van de data de performance van de app met genormaliseerde data met een factor 30 vertraagde.

Theorie is leuk, maar common sense is leuker.

Hierbij wil ik trouwens wel even de kanttekening plaatsen dat je in eerste instantie uitgaat van de 3e normaalvorm en pas daarna gaat denormaliseren. Een "3e normaalvorm, tenzij" policy.

Maar goed, met de hele noSQL 'hype' zullen er sowieso wat knoppen flink om moeten en heel wat heilige huisjes omgeschopt moeten worden.

[Remus]

Waking_The_Dead schreef op vrijdag 20 januari 2012 @ 12:21:
Wat de theorie voorschijft is allemaal goed en wel maar dat is gewoon niet praktisch imo.
Als je op een project werkt met (zoals ik nu) 700 tabellen dan is het gewoon een must om standaarden af te spreken. En die standaard bij ons is dat de PK van elke tabel een auto-increment is met een vaste naam: "ID_<tabelnaam>". Dat is voor zowel de DBA, de ontwikkelaars en analysten de handigste oplossing. Het custom framework houdt rekening met die conventie en dat werkt echt wel zeer vlot.

Als je voor elke tabel de theorie volgens de letter toepast dan is je project gedoemd omdat het totaal niet onderhoudbaar is.

Die naamgeving kan je nog steeds aanhouden, alleen dan zonder de auto-incremented id voor id kolom. Die krijgt zijn waarde gewoon van de PK van de supertable. Persoonlijk krijg ik overigens altijd jeuk van de tabelnaam herhalen in kolommen die onderdeel zijn van de tabel zelf

Maar inderdaad: soms moet je praktisch zijn.

[NMe]

Janoz schreef op vrijdag 20 januari 2012 @ 12:56:
[...]

Hierbij wil ik trouwens wel even de kanttekening plaatsen dat je in eerste instantie uitgaat van de 3e normaalvorm en pas daarna gaat denormaliseren. Een "3e normaalvorm, tenzij" policy.

Daarom zei ik ook "na die derde normaalvorm."

EfBe schreef op vrijdag 20 januari 2012 @ 12:55:
[...]

Ik noem ook geen reden om roze olifantjes toe te passen. Ik noem juist een reden om het wel te doen, nl. de reden die is beschreven in theorie, bewezen door 2 toonaangevende professoren op dit gebied.

"Want twee professoren zeggen dat" is ook geen reden. Wat is de reden dat deze professoren het noemen? Ik heb jou alleen het "orde en netheid"-argument zien noemen, en dat is nooit een reden om daar niet van te mogen afwijken als je daar een reden voor hebt. Een O/R-mapper die anders niet met je tabel overweg kan is een prima reden...

Tja, als jij maar wat raak wilt prutsen zonder enige theoretische basis, mijn zegen heb je. Het is alleen niet echt nuttig.

Nogal een gedurfde aanname die je daar maakt over iemand die je niet kent en die er zelf geen uitspraken over heeft gedaan hoeveel theoretische kennis hij bezit. Zullen we dit soort insinuaties maar achterwege laten?

Lijkt me een beetje een onzinnige standaard. Ten eerste is de naam vastleggen in de PK niet echt handig (table rename) en overbodig (je weet in welke table hij zit, je plaatst toch ook niet de tabelnaam achter ieder andere veld?)

Het maakt de behoefte voor aliassen bij joins wat minder dringend in sommige gevallen en in een hoger aantal gevallen maakt het de ambiguïteit van de veldnaam minder.

Niet zelf stellingen gaan verzinnen die je niet zelf kunt waarmaken. Het toepassen van bewezen theorieen is juist wel onderhoudbaar, want je weet dat wat is toegepast ook werkt. Dat hebben anderen nl. al voor je uitgezocht.

Dat een theorie bewezen is maakt het niet per definitie altijd de juiste keuze. Zie mijn vorige post. Tabellen in de eerste normaalvorm zou ik normaal nooit doen maar de praktijk wees iets anders uit. Uiteindelijk moet er toch geld verdiend worden, en dat lukt niet als elke request 20 seconden duurt.

[Gomez12]

com2,1ghz schreef op donderdag 19 januari 2012 @ 15:34:
[...]
Ok dat snap ik, maar in mijn afstudeerverslag kan ik niet deze keuze beargumenteren door te zeggen "ja zo doet het bedrijf het". Dat kan in geen enkel project.

Hoe kom je erbij dat het niet zou kunnen?
Ik ben ietwat nieuwsgieriger hoe je x tijd besteden aan het discussieren over een persoonlijke keuze / bedrijfsstandaard wilt verantwoorden.

Als je school een beetje praktijkgericht is dan is bedrijfsstandaard + uitgelegd dat anders misschien beter was maar hun wilden toch bedrijfsstandaard voldoende. Je moet toch iets opleveren waar het bedrijf iets aan heeft en jij iets van leert, niet een verslag over x maanden discussie maken.

Daar kan ik dus niets mee en daardoor heb ik dit topic om aan jullie, de experts te vragen waarom mijn keuze voor dit niet goed zou zijn.

Je kan altijd met betere suggesties komen, alleen eind van de rit ga jij weg en moeten hun er aan werken. Als je school van mening is dat stageprojecten by default overnieuw gedaan moeten worden als stagair weg is (wat gaat gebeuren als het niet naar bedrijfsstandaard is en wel nuttig en je hun niet hebt kunnen overtuigen) dan heb je wmb een aparte school...

[Waking_The_Dead]

Tja, als jij maar wat raak wilt prutsen zonder enige theoretische basis, mijn zegen heb je. Het is alleen niet echt nuttig. Je bent het toch met me eens dat als ABC op 2 manieren getransformeerd kan worden naar database tabellen, jij niet met een 3e aan kan komen, want er zijn maar 2 manieren? Waarom zou je ook met een 3e manier aan moeten komen als er al 2 zijn?

Ik heb een universitaire opleiding toegepaste informatica gevolgd waarbij "databanken" een van de hoofdvakken was; theoretische kennis en basis genoeg. Na 11 jaar in de praktijk kan ik ook zeggen dat je heel veel van de theorie moet afwijken om iets werkbaar/onderhoudbaar/performant te houden. Als jij dat dan "prutsen" en "niet echt nuttig" wilt noemen, be my guest.

Misschien nog even voor de goede orde: die standaard waarover ik sprak, lag al lang vast voordat ik het project vervoegde en ik zeg ook niet dat het de heilige graal is. Het was gewoon een voorbeeld van een standaard en het feit dat we ons aan die standaar houden binnen het project.

[EfBe]

NMe schreef op vrijdag 20 januari 2012 @ 13:20:
[...]
"Want twee professoren zeggen dat" is ook geen reden. Wat is de reden dat deze professoren het noemen? Ik heb jou alleen het "orde en netheid"-argument zien noemen, en dat is nooit een reden om daar niet van te mogen afwijken als je daar een reden voor hebt. Een O/R-mapper die anders niet met je tabel overweg kan is een prima reden...

... vind jij. Wat jij prima vindt is overigens niet het onderwerp: de TS vroeg wat correct was en wat niet, ik geef die aan en jij komt met een halfbakken verhaal dat je er vanaf moet wijken soms en dat een PK toevoegen aan 'villa' en 'flat' beter is.

Om even aan te geven dat het echt fout is, het volgende: een row in flat en villa zijn geen entities, maar delen van entities: de andere helft zit in 'Woning'. Jouw PK in flat en villa echter maakt het mogelijk een row uit flat en villa te zien als losstaande entity, immers het heeft een eigen PK. Dit is echter fout, immers het is maar de helft.

Jouw opzet is dezelfde als een 1:n relatie, bv tussen customer en order. Villa en Flat zijn echter geen 1:n gerelateerde entities aan woning maar subtypes. Fundamenteel verschil, omdat je een row in een van de tables nooit mag gaan zien als een losse row (dus ook een rij in woning niet, je kunt bv niet een row in woning delen tussen een flat en een villa, mocht dat al fysiek kunnen. Jouw setup suggereert dat dat wel kan, immers villa en flat zijn losstaande entities met een 1:1 (FK/UC bound) relatie met woning volgens jouw model.

Jouw model heeft nl geen verschil tussen 1:1 FK/UC relaties en een subtype relatie.

[...]
Nogal een gedurfde aanname die je daar maakt over iemand die je niet kent en die er zelf geen uitspraken over heeft gedaan hoeveel theoretische kennis hij bezit. Zullen we dit soort insinuaties maar achterwege laten?

Als iemand aan komt met 'theorie is in de praktijk niet nuttig' of soortgelijk gelul terwijl de topicstarter vroeg wat 'juist' is, en ik gewoon aangeef wat de theorie voorschijft, mag ik IMHO gewoon zeggen dat die persoon dom bezig is met zn 'theorie is in de praktijk niet nuttig'.

De laatste 10 jaar heb ik me full time bezig gehouden met precies dit vakgebied en theorie is wel degelijk nuttig hier, sterker, het is essentieel. Dat botweg ontkennen is in mijn ogen prutsen, en IMHO ook niet echt nuttig, immers wat draagt het bij aan het begrip van de theorie van TS? Dat de 'theorie ontkennende persoon' het allemaal anders doet en DUS dat je maar wat moet doen in de praktijk?

[...]
Het maakt de behoefte voor aliassen bij joins wat minder dringend in sommige gevallen en in een hoger aantal gevallen maakt het de ambiguïteit van de veldnaam minder.

Ja, dat wordt altijd aangevoerd als excuus, maar waarom dan alleen achter de ID en niet achter 'Name' etc. ? Ook is het overbodig, immers bij een join volstaat de FK in de projectie ook, die is immers hetzelfde. In join predicates moet je sowieso de source opgeven dus het is echt een onnodige actie. Maar goed, offtopic.

[...]
Dat een theorie bewezen is maakt het niet per definitie altijd de juiste keuze. Zie mijn vorige post. Tabellen in de eerste normaalvorm zou ik normaal nooit doen maar de praktijk wees iets anders uit. Uiteindelijk moet er toch geld verdiend worden, en dat lukt niet als elke request 20 seconden duurt.

Joh wat jij allemaal de-normaliseert om performance-technische redenen... dat is allemaal prachtig maar toch niet ter zake doende voor de vraag van deze thread? Immers: de TS vraag wat juist is. Als je performance wilt aanvoeren had jouw enige juiste antwoord moeten zijn: 1 tabel voor de gehele hierarchy. Maar niet een offtopic praatje over denormalized tables.

Waking_The_Dead schreef op vrijdag 20 januari 2012 @ 13:31:
[...]
Ik heb een universitaire opleiding toegepaste informatica gevolgd waarbij "databanken" een van de hoofdvakken was; theoretische kennis en basis genoeg. Na 11 jaar in de praktijk kan ik ook zeggen dat je heel veel van de theorie moet afwijken om iets werkbaar/onderhoudbaar/performant te houden. Als jij dat dan "prutsen" en "niet echt nuttig" wilt noemen, be my guest.

Ik refereer naar een theorie die als basis gebruikt wordt voor het transformeren van inheritance hierarchien naar relational models. Jij komt dan aan dat dit niet nuttig is want theorie is in de praktijk niet zo nuttig. Sorry, maar als je had opgelet tijdens je studie mbt relational databases, had je wellicht geweten dat dit in _dit kader_ wel degelijk nuttig is. Ik heb het niet over 'je moet altijd uitnormaliseren tot de 5e normaalvorm', ik heb het over het transformeren van inheritance hierarchien, precies wat TS mee zit en wat zn collegas niet snappen. Daarom vond ik die opmerking van je een beetje onnozel, zeker wanneer je ook nog een studie informatica hebt afgerond.

Misschien nog even voor de goede orde: die standaard waarover ik sprak, lag al lang vast voordat ik het project vervoegde en ik zeg ook niet dat het de heilige graal is. Het was gewoon een voorbeeld van een standaard en het feit dat we ons aan die standaar houden binnen het project.

Maakt mij verder ook niet uit, het gebruiken van een standaard is al netjes, veel mensen doen maar wat. Jij haalde echter die standaard aan als argument dat een extra PK op de subtype tables nuttig is, maar dat is echt niet zo (zie boven)

[ Voor 18% gewijzigd door EfBe op 20-01-2012 13:49 ]

[Waking_The_Dead]

Jij komt dan aan dat dit niet nuttig is want theorie is in de praktijk niet zo nuttig.

Dat heb ik nergens gezegd. Wat ik WEL gezegd heb, is dat je in de praktijk vaak van de theorie moet afwijken.

En als je, zoals in mijn geval, een framework gebruikt dat wanneer het de databank aanspreekt ervan uitgaat dat elke tabel een a_i_id heeft, dan zou het niet zo slim zijn om in het voorbeeld van TS geen a_i_id's te gebruiken. Dan moet je namelijk om het framework heen gaan ontwikkelen, en waarvoor?

Dat je een volledig theoritsch onderbouwde uitleg zou kunnen geven dat dit een brak framework is omdat het die aanname doet, is mooi. Maar daar schieten we niets mee op in de praktijk. De praktijk is dat we vast zitten aan dat framework. En om dan halsstarrig vast te houden aan de theorie, dat zou pas onnozel zijn.

Maakt mij verder ook niet uit, het gebruiken van een standaard is al netjes, veel mensen doen maar wat. Jij haalde echter die standaard aan als argument dat een extra PK op de subtype tables nuttig is, maar dat is echt niet zo (zie boven)

Het is nuttig in de zin dat je je aan de standaard moet houden. Als dat is wat de standaard van je verwacht, dan heb je twee mogelijkheden: ofwel houd je vast aan de theorie, ofwel houd je je aan de standaard. Ik ben er vrij zeker van dat je meer collega's gelukkig maakt door je aan de standaard te houden. Dat is mijn punt en niet dat de theorie niet goed is of zo...

[ Voor 27% gewijzigd door Waking_The_Dead op 20-01-2012 14:07 ]

[com2,1ghz]

Waking_The_Dead schreef op vrijdag 20 januari 2012 @ 14:02:
[...]


Dat heb ik nergens gezegd. Wat ik WEL gezegd heb, is dat je in de praktijk vaak van de theorie moet afwijken.

En als je, zoals in mijn geval, een framework gebruikt dat wanneer het de databank aanspreekt ervan uitgaat dat elke tabel een a_i_id heeft, dan zou het niet zo slim zijn om in het voorbeeld van TS geen a_i_id's te gebruiken. Dan moet je namelijk om het framework heen gaan ontwikkelen, en waarvoor?

Dat je een volledig theoritsch onderbouwde uitleg zou kunnen geven dat dit een brak framework is omdat het die aanname doet, is mooi. Maar daar schieten we niets mee op in de praktijk. De praktijk is dat we vast zitten aan dat framework. En om dan halsstarrig vast te houden aan de theorie, dat zou pas onnozel zijn.

In ons framework hebben wij ook een conventie voor de database, bijvoorbeeld de veldnaam voor de a_i en zo zijn er nog meerdere standaarden. Waar ik op doel is dat ik die a_i wil weglaten doordat ik het niet nodig zou hebben en daardoor een welles nietes discussie ontstaat.

Tevens is de theorie niet gebakken lucht maar gebaseerd op basis van de praktijk. Als de theorie zoveel afwijkt van de praktijk dan moet er naar mijn idee nagedacht worden of er wel de juiste beslissingen zijn genomen in de structuur/framework.

Ik neem ook aan dat er meer mensen en ook langer nagedacht hebben over databases dan een bedrijfje die een framework wil bouwen.

[Waking_The_Dead]

Het framework in kwestie is geschreven door een ex-collega van me die bij aanvang van het project bij alles betrokken was. Hij wist wel het een en ander af van databases, maar lang niet de theoretische kennis die jij en ik hebben. Dat was zeven jaar geleden; toen er nog maar 20 tabellen voor het project nodig waren. Nu hebben we er 700. Het framework gaat er van uit dat een tabel een auto_increment heeft. Punt. En ik zit er mee

Dat is ook "de praktijk". Je krijgt voortdurend te maken met mensen die denken dat ze weten zat ze doen, maar dat doen ze niet. Daar komen dan nog eens deadlines en onheuse klanten bij en op die manier wordt de kloof tussen theorie en praktijk al snel heel groot.

[NMe]

EfBe schreef op vrijdag 20 januari 2012 @ 13:46:
[...]

... vind jij. Wat jij prima vindt is overigens niet het onderwerp: de TS vroeg wat correct was en wat niet, ik geef die aan en jij komt met een halfbakken verhaal dat je er vanaf moet wijken soms en dat een PK toevoegen aan 'villa' en 'flat' beter is.

Nee, dat is wat jij ervan maakt. De topicstarter vroeg of het fout was om géén apart auto increment ID te maken. Daar heeft hij antwoord op gehad: nee, dat is niet fout. Het tegenovergestelde is echter óók niet fout. Nergens heeft de TS gevraagd wat "juist" is, en bovendien is er geen absolute waarheid die altijd juist is in dit geval. Die absolute waarheid heb ik niet, de TS niet en jij ook niet, ook niet met jouw twee professoren in de hand. Bovendien merk ik op dat je behalve netheid nog steeds geen goede reden hebt genoemd die het toevoegen van dat ID absoluut "fout" maakt.

Om even aan te geven dat het echt fout is, het volgende: een row in flat en villa zijn geen entities, maar delen van entities: de andere helft zit in 'Woning'. Jouw PK in flat en villa echter maakt het mogelijk een row uit flat en villa te zien als losstaande entity, immers het heeft een eigen PK. Dit is echter fout, immers het is maar de helft.

Dat is een fout in theorie. Niet in de praktijk. Als een bedrijf ervoor kiest om niet de entiteit te nummeren maar de row in de tabel, dan gaat je hele argument niet meer op. Leg niet je eigen stijlregels aan anderen op als absolute waarheid.

Jouw model heeft nl geen verschil tussen 1:1 FK/UC relaties en een subtype relatie.

"Mijn model" heeft niks. Het zal mijn aan mijn reet roesten waar de topicstarter voor kiest. Ik zou zijn voorgestelde model ook niet gebruiken, ik zou in de voorgestelde versimpelde vorm alles in één tabel gooien tenzij het aantal nutteloze velden per categorie daarmee excessief wordt.

Als iemand aan komt met 'theorie is in de praktijk niet nuttig' of soortgelijk gelul terwijl de topicstarter vroeg wat 'juist' is, en ik gewoon aangeef wat de theorie voorschijft, mag ik IMHO gewoon zeggen dat die persoon dom bezig is met zn 'theorie is in de praktijk niet nuttig'.

Van mij mag je dat, maar dat geeft alleen maar aan dat je zelf absoluut niet pragmatisch bent én dat je de topicstart niet goed gelezen hebt. Daarnaast suggereerde je dat de user waar je op reageerde geen kennis had, en dat is nogal iets anders dan zeggen dat zijn stelling dom is.

De laatste 10 jaar heb ik me full time bezig gehouden met precies dit vakgebied en theorie is wel degelijk nuttig hier, sterker, het is essentieel.

Maar waarom dan? Kom eens met een steekhoudend argument tegen het gebruik van die extra primary key? Nogmaals, "het is niet netjes" is niet steekhoudend. Er is wel meer niet netjes, en dat is dan ook de reden dat ik denormalisatie en spul in de eerste normaalvorm opnemen erbij betrek. Beiden zijn ook niet netjes en volgens elke theorie zelfs ranzig. En toch zijn het in de praktijk prima methodieken om met bepaalde situaties om te gaan. Of zeg je ook altijd tegen je baas dat je een totaal wanproduct hebt afgeleverd maar het theoretisch wel correct werkt?

Nogmaals: theoretisch heb je gelijk. Het is cleaner om vooral die extra key niet op te nemen. Maar het is ook geen struikelblok voor je DB om het wel te doen terwijl een dringende reden is om het wel te doen (company standards) en een potentiële reden waar wij alleen maar naar kunnen raden (die brakke O/R-mapper die eraan ten grondslag zou kunnen liggen). Roepen dat jouw waarheid altijd waar is is kortzichtig en (sorry hiervoor, maar jij gebruikte hetzelfde woord) dom.

com2,1ghz schreef op vrijdag 20 januari 2012 @ 14:12:
[...]

Tevens is de theorie niet gebakken lucht maar gebaseerd op basis van de praktijk. Als de theorie zoveel afwijkt van de praktijk dan moet er naar mijn idee nagedacht worden of er wel de juiste beslissingen zijn genomen in de structuur/framework.

In sommige gevallen wel, in andere gevallen niet. De theorie werkt op papier heel mooi omdat daar nooit speciale vereisten voor gesteld zijn. Die vereisten zijn er in de praktijk in het bedrijfsleven altijd.

Bovendien, wil je je hier echt lang mee bezig houden? Je bent bezig met je afstudeerstage en zit nu te steggelen over een non-issue. Het boeit niet, welke van de twee opties je ook kiest. Zet in je afstudeerverslag dat dit de company standard was die je verzocht is, en als je van je collega's geen reden krijgt dan haal je er gewoon die brakke O/R-mapper bij als ernaar gevraagd wordt. Dat heeft het voordeel dat je nu geen tijd verspilt én geen eigenwijze indruk maakt bij de mensen die je straks een punt moeten geven voor je stage...

Ik neem ook aan dat er meer mensen en ook langer nagedacht hebben over databases dan een bedrijfje die een framework wil bouwen.

Het probleem met mensen die lesmethoden schrijven is dat ze vaak amper praktijkervaring hebben. Neem niet alles wat je leest voor waar aan, kijk wat je er zelf van kan gebruiken en hoe je het het beste toepast. Afhankelijk van de situatie is afwijken van de standaard wel degelijk vaak zinnig.

[ Voor 17% gewijzigd door NMe op 20-01-2012 14:29 ]

[Gomez12]

com2,1ghz schreef op vrijdag 20 januari 2012 @ 14:12:
[...]

In ons framework hebben wij ook een conventie voor de database, bijvoorbeeld de veldnaam voor de a_i en zo zijn er nog meerdere standaarden. Waar ik op doel is dat ik die a_i wil weglaten doordat ik het niet nodig zou hebben en daardoor een welles nietes discussie ontstaat.

Tevens is de theorie niet gebakken lucht maar gebaseerd op basis van de praktijk. Als de theorie zoveel afwijkt van de praktijk dan moet er naar mijn idee nagedacht worden of er wel de juiste beslissingen zijn genomen in de structuur/framework.

Ik neem ook aan dat er meer mensen en ook langer nagedacht hebben over databases dan een bedrijfje die een framework wil bouwen.

Soms moet je je simpelweg schikken naar de praktijk...

Dat geef je mooi aan in het bolde zinnetje. De praktijk kan nog zo krom zijn, als stagair ben je niet binnengehaald om structuur / framework te herschrijven. Je moet iets opleveren binnen dat framework.

Dat het theoretisch fout is dat is niet zo relevant als jij er maar 3 maanden zit en er 10 man al jarenlang in het framework werken en het herbouwen van het framework een meerjaren project is.

Op het moment dat jij theoretische meesterstukjes gaat afleveren die niemand kan onderhouden omdat hun praktisch anders werken heb je wmb je stage compleet verkeerd gedaan
Je kan kanttekeningen plaatsen, je kan verbeterpunten aangeven, maar uiteindelijk moet je werken met de praktijk en niet met de theorie.

[matthijsln]

Er wordt wel heel veel aangenomen over wat stagiaires allemaal wel en niet mogen zeg!

Ik zou zeggen, als je een enorm brakke O/R mapper gebruikt, laat een stagiair eens een onderzoek doen om het over te zetten naar een betere (bijvoorbeeld één waar je gewoon @Inheritance(strategy=JOINED) op je class zet) waarbij je ook dit soort dingen mee kan nemen. Heb je ook nog wat interessants om in het verslag te zetten, in plaats van 'ik mocht niks veranderen want het werkt al jaren zo'.

Vooral omdat een aantal zo van de praktijk zijn, is een uitwerking van de praktijk volgens een goed theoretisch model met een goede O/R mapper door een stagiar misschien zelfs wel een goede vergelijkingscase te maken en vallen de 'praktische overwegingen' toch wel mee - of niet.

[com2,1ghz]

matthijsln schreef op vrijdag 20 januari 2012 @ 15:15:
Er wordt wel heel veel aangenomen over wat stagiaires allemaal wel en niet mogen zeg!

Ik zou zeggen, als je een enorm brakke O/R mapper gebruikt, laat een stagiair eens een onderzoek doen om het over te zetten naar een betere (bijvoorbeeld één waar je gewoon @Inheritance(strategy=JOINED) op je class zet) waarbij je ook dit soort dingen mee kan nemen. Heb je ook nog wat interessants om in het verslag te zetten, in plaats van 'ik mocht niks veranderen want het werkt al jaren zo'.

Vooral omdat een aantal zo van de praktijk zijn, is een uitwerking van de praktijk volgens een goed theoretisch model met een goede O/R mapper door een stagiar misschien zelfs wel een goede vergelijkingscase te maken en vallen de 'praktische overwegingen' toch wel mee - of niet.

That's my point.

[NMe]

com2,1ghz schreef op vrijdag 20 januari 2012 @ 15:17:
[...]

That's my point.

Maar dat is niet je opdracht.

[matthijsln]

NMe schreef op vrijdag 20 januari 2012 @ 15:28:
[...]

Maar dat is niet je opdracht.

Think out of the box

[Waking_The_Dead]

matthijsln schreef op vrijdag 20 januari 2012 @ 15:35:
[...]


Think out of the box

Haha. DAt doet me denken aan die keer dat ik op een mondeling examen een antwoord bedacht had op een andere vraag omdat ik de echte vraag niet kon beantwoorden. Dat is me toen door de prof ook niet in dank afgenomen

[EfBe]

NMe schreef op vrijdag 20 januari 2012 @ 14:24:
[...]
Nee, dat is wat jij ervan maakt. De topicstarter vroeg of het fout was om géén apart auto increment ID te maken. Daar heeft hij antwoord op gehad: nee, dat is niet fout. Het tegenovergestelde is echter óók niet fout.

jazeker wel, ik geef dat nota bene aan, jij quote het zelfs in je post. Het gaat er niet om of een of andere gare data-access layer het toch kan lezen/schrijven, het gaat erom of het model correct is, nl. wat stelt het voor. Een entity met 2 verschillende PKs is incorrect, punt.

Nergens heeft de TS gevraagd wat "juist" is, en bovendien is er geen absolute waarheid die altijd juist is in dit geval. Die absolute waarheid heb ik niet, de TS niet en jij ook niet, ook niet met jouw twee professoren in de hand. Bovendien merk ik op dat je behalve netheid nog steeds geen goede reden hebt genoemd die het toevoegen van dat ID absoluut "fout" maakt.

Hoezo heb ik die ook niet? Jij gaat beweren dat ik niet weet waar ik me al 10 jaar lang full time mee bezig houdt? Mag hoor, maar het verandert niet zoveel. Ik snap je overigens niet helemaal: waarom zit je zo te drammen ipv aan te nemen wat iemand die er veel en veel meer tijd in gestoken heeft zegt mbt dit kleine aspect van relational models?

[...]
Dat is een fout in theorie. Niet in de praktijk. Als een bedrijf ervoor kiest om niet de entiteit te nummeren maar de row in de tabel, dan gaat je hele argument niet meer op. Leg niet je eigen stijlregels aan anderen op als absolute waarheid.

Row == entity instance. Jouw bewering hierboven slaat echt nergens op, sorry. Het heeft niets met stijlregels te maken, maar met wat een correct relational model is.

[...]
Maar waarom dan? Kom eens met een steekhoudend argument tegen het gebruik van die extra primary key?

Die heb ik gegeven, lees je eigen post maar door, je quote hem zelfs.

Nogmaals, "het is niet netjes" is niet steekhoudend. Er is wel meer niet netjes, en dat is dan ook de reden dat ik denormalisatie en spul in de eerste normaalvorm opnemen erbij betrek. Beiden zijn ook niet netjes en volgens elke theorie zelfs ranzig. En toch zijn het in de praktijk prima methodieken om met bepaalde situaties om te gaan. Of zeg je ook altijd tegen je baas dat je een totaal wanproduct hebt afgeleverd maar het theoretisch wel correct werkt?

Ik zeg nergens 'niet netjes', want dat is irrelevant en subjectief: ik heb het over correct en niet correct. Jij beweert dat wat niet correct is, toch prima werkt. In dit geval levert dat zooi op, maar tja, dat is jouw verantwoordelijkheid. Overigens heb ik geen baas en maak ik al 10 jaar O/R mapper tools en frameworks, die o.a. de transformaties waar ik het over heb zelf doorvoeren (van entity model naar relational model) en andersom hierarchieen kunnen herkennen in relational models.

Nogmaals: theoretisch heb je gelijk. Het is cleaner om vooral die extra key niet op te nemen. Maar het is ook geen struikelblok voor je DB om het wel te doen terwijl een dringende reden is om het wel te doen (company standards) en een potentiële reden waar wij alleen maar naar kunnen raden (die brakke O/R-mapper die eraan ten grondslag zou kunnen liggen). Roepen dat jouw waarheid altijd waar is is kortzichtig en (sorry hiervoor, maar jij gebruikte hetzelfde woord) dom.

Die relational database zal het worst wezen, die kent het concept 'inheritance' niet. De code die de database gebruikt echter wel. En daar zit hem nu net het probleem: wanneer het niet correct wordt gemodeled zal een andere applicatie ervanuit kunnen gaan dat een model met wat jij voorstelt niet inheritance is maar een 1:1 FK/UC situatie. En dat is dus fout. Bij de setup van TS heb je dat niet.

Het is overigens niet 'mijn waarheid' maar gewoon computer science. Geen gebroddel van een of andere sjaak op een forum, maar theorie waar men jaren onderzoek naar heeft gedaan. Doe er je voordeel mee zou ik zeggen. Je laat blijken dat je het onzin vindt, dat mag, your loss.

[Waking_The_Dead]

Ik zeg nergens 'niet netjes', want dat is irrelevant en subjectief: ik heb het over correct en niet correct. Jij beweert dat wat niet correct is, toch prima werkt. In dit geval levert dat zooi op, maar tja, dat is jouw verantwoordelijkheid. Overigens heb ik geen baas en maak ik al 10 jaar O/R mapper tools en frameworks, die o.a. de transformaties waar ik het over heb zelf doorvoeren (van entity model naar relational model) en andersom hierarchieen kunnen herkennen in relational models.

Je hebt geen baas en je houdt je al tien jaar op theoretisch (frameworks maken noem ik theorie, ja) vlak bezig met databases... M.a.w. je hebt dus geen praktijkervaring met projecten waar je met collega's moet rekening houden, aan een baas rapporteert en de klant tevreden houdt..... zegt genoeg.

[EfBe]

Waking_The_Dead schreef op vrijdag 20 januari 2012 @ 16:01:
[...]
Je hebt geen baas en je houdt je al tien jaar op theoretisch (frameworks maken noem ik theorie, ja) vlak bezig met databases... M.a.w. je hebt dus geen praktijkervaring met projecten waar je met collega's moet rekening houden, aan een baas rapporteert en de klant tevreden houdt..... zegt genoeg.

Tja, voor die tijd deed ik ook niks, of wel? En de duizenden bedrijven die onze software gebruiken hebben ook nooit eisen etc...

Gast, ik begrijp niet echt wat jouw probleem is. TS vraagt iets, ik geef een antwoord maar jij harkt dat ondersteboven als zijnde niet nuttige info. Na wat gezeik kom je met de bovenstaande post die jouw gelijk kennelijk moet aangeven en dat ik niet weet waarover ik praat.

Zelden zulke kortzichtigheid meegemaakt. Het probleem dat TS schetst is inheritance -> relational model transformatie, gebruikt in relational models die gebruikt worden door OO code, dmv o/r mappers. Laat dat nu net mijn vakgebied zijn waar ik toevallig wel iets meer afweet dan de gemiddelde developer (en van andere zaken dus minder) en daarom dacht ik, laat ik TS helpen met wat theorie, hoe het geheel logischerwijze is opgebouwd etc.

Maar wat blijkt? Kennelijk schop ik sommigen tegen het zere been met wat theorie en moet dat worden afgemaakt met sneue posts zoals die van jou hierboven.

[NMe]

EfBe schreef op vrijdag 20 januari 2012 @ 15:53:
[...]

Een entity met 2 verschillende PKs is incorrect, punt.

Row == entity instance.

Je spreekt jezelf tegen. Als een row gelijk zou zijn aan een entitiy instance, dan maakt dat een tabel per definitie een entity zijn Flat en Woning aparte entities, wat de eerste quote onwaar maakt óf je punt op losse schroeven zet.

Die heb ik gegeven, lees je eigen post maar door, je quote hem zelfs.

Daar lees ik alleen verwijzingen naar professoren die roepen dát het "niet correct" is. Ben ik het mee eens hoor, maar ik kijk niet blind naar wat anderen doen. Als jij mij geen overtuigende reden kan noemen waarom iets altijd gebruikt zou moeten worden boven een andere methode, dan ga ik ervan uit dat beide methodes hun voor- en nadelen hebben.

Ik zeg nergens 'niet netjes', want dat is irrelevant en subjectief: ik heb het over correct en niet correct. Jij beweert dat wat niet correct is, toch prima werkt. In dit geval levert dat zooi op, maar tja, dat is jouw verantwoordelijkheid.

Zooi? Een extra veldje dat alleen intern gebruikt wordt? Beetje overdreven.

Overigens heb ik geen baas en maak ik al 10 jaar O/R mapper tools en frameworks, die o.a. de transformaties waar ik het over heb zelf doorvoeren (van entity model naar relational model) en andersom hierarchieen kunnen herkennen in relational models.

Het feit dat je eigen baas bent en dus geen mensen hebt die jouw werk toetsen aan de praktijk spreekt niet echt voor je. Ik zeg niet dat dat betekent dat je slecht werk levert (want ik wéét dat je dat niet doet ) maar om die reden heeft die opmerking waarschijnlijk niet het effect dat je ermee wilde bereiken.

Die relational database zal het worst wezen, die kent het concept 'inheritance' niet. De code die de database gebruikt echter wel. En daar zit hem nu net het probleem: wanneer het niet correct wordt gemodeled zal een andere applicatie ervanuit kunnen gaan dat een model met wat jij voorstelt niet inheritance is maar een 1:1 FK/UC situatie. En dat is dus fout. Bij de setup van TS heb je dat niet.

Daar heb je documentatie voor. Assumption is the mother of all fuckups.

Het is overigens niet 'mijn waarheid' maar gewoon computer science. Geen gebroddel van een of andere sjaak op een forum, maar theorie waar men jaren onderzoek naar heeft gedaan. Doe er je voordeel mee zou ik zeggen. Je laat blijken dat je het onzin vindt, dat mag, your loss.

Ik vind niks onzin, ik vind alleen dat je de theorie niet overal blind moet toepassen maar alleen waar dat zinnig is. Zelf nadenken. Om de derde normaalvorm er maar weer bij te halen: dat is ook computer science en in zijn algemeenheid past iedereen die ook netjes toe....tenzij het ergens niet zinnig is of er een andere reden is om dat niet te doen. Er zijn geen heilige huisjes, soms moet je gewoon eens van een standaard afwijken. Het is niet aan jou om te bepalen of dat in dit geval voor de topicstarter nu wel of niet zo is.

[Gomez12]

EfBe schreef op vrijdag 20 januari 2012 @ 16:11:
[...]
Laat dat nu net mijn vakgebied zijn waar ik toevallig wel iets meer afweet dan de gemiddelde developer (en van andere zaken dus minder) en daarom dacht ik, laat ik TS helpen met wat theorie, hoe het geheel logischerwijze is opgebouwd etc.

Het probleem is dat de praktijk nog wel eens van de theorie wil afwijken.

Vaak zat theoretische correct db's gezien die totaal niet vooruit te branden waren. Theoretisch (en praktisch) was het prachtig snel voor een heel beperkte set doeleinden, toen kwam het in de praktijk terecht en toen bedacht de betalende klant er 15.000 andere doeleinden omheen die allemaal traag als dikke stroop waren.

En tja, dan kan je uiteraard je model weer gaan bijstellen naar exact die 15.000 doeleinden en dan wachten totdat de klant weer een nieuw doeleind bedenkt. Of je kan voor een middle of the road (volgens jouw woorden incorrect) datamodel gaan wat misschien op 100 query's trager is dan het theoretische maar wel de eerste 50.000 door de klant te bedenken doeleinden redelijk tot goed ondervangt.

Simpel voorbeeld qua OP : flateigenaar behoudt dezelfde woning, maar verbouwt zijn flat om naar villa. Dat kan het theoretische model niet aan, praktijk zal waarschijnlijk gewoon zijn dat er 2 woningen komen op 1 adres, waarvan de flat vervallen is. Maar theoretisch is dit dan incorrect. Oftewel theorie is leuk tot aan een grens (en die grens moet je zo hoog mogelijk leggen imho) maar kan nooit het einddoel zijn, praktijk werkend is het einddoel.

[EfBe]

NMe schreef op vrijdag 20 januari 2012 @ 16:17:
[...]
[...]
Je spreekt jezelf tegen. Als een row gelijk zou zijn aan een entitiy instance, dan maakt dat een tabel per definitie een entity zijn Flat en Woning aparte entities, wat de eerste quote onwaar maakt óf je punt op losse schroeven zet.

Ik quote mezelf:
Om even aan te geven dat het echt fout is, het volgende: een row in flat en villa zijn geen entities, maar delen van entities: de andere helft zit in 'Woning'. Jouw PK in flat en villa echter maakt het mogelijk een row uit flat en villa te zien als losstaande entity, immers het heeft een eigen PK. Dit is echter fout, immers het is maar de helft.

De row in 'villa' is dus maar de helft van de entity instance. Met 'row==entity instance' bedoelde ik dat er een verschil is tussen data en table definitie mbt 'entity'. Jij had het over nummeren van entities vs. nummeren van rows, maar dat is hetzelfde.

[...]
Daar lees ik alleen verwijzingen naar professoren die roepen dát het "niet correct" is. Ben ik het mee eens hoor, maar ik kijk niet blind naar wat anderen doen. Als jij mij geen overtuigende reden kan noemen waarom iets altijd gebruikt zou moeten worden boven een andere methode, dan ga ik ervan uit dat beide methodes hun voor- en nadelen hebben.

Zie de quote hierboven.

Als extra argument nog dit: wanneer Villa een eigen PK zou hebben met een FK/UC naar Woning, dan is de row in Villa te wijzigen dat het naar een andere row in Woning verwijst. Dit is niet zomaar mogelijk in de setup met de PK als FK, want PK wijzigen komt feitelijk neer op delete + insert en updaten van PKs is (gelukkig) een bad practice. Het veranderen van de FK value naar Woning is ongewenst want je bent niet de entity aan het wijzigen maar aan het husselen van delen van entities. Met zooi als gevolg.

[...]
Zooi? Een extra veldje dat alleen intern gebruikt wordt? Beetje overdreven.

Het is niet overdreven, want een table field met een PK constraint is niet een normaal field. Wanneer de data wordt geladen in objects krijg je problemen wanneer je bv een hashcode wilt berekenen uit PK fields, je code moet dan dus op meerdere plekken staan terwijl de PK voor alle types in een hierarchy hetzelfde is. 'Dat veldje, ja, dat is voor intern gebruik, doen we niets mee', is IMHO dan alleen maar ballast en maakt dingen onnodig ingewikkeld. Dus, zooi.

[...]
Het feit dat je eigen baas bent en dus geen mensen hebt die jouw werk toetsen aan de praktijk spreekt niet echt voor je. Ik zeg niet dat dat betekent dat je slecht werk levert (want ik wéét dat je dat niet doet ) maar om die reden heeft die opmerking waarschijnlijk niet het effect dat je ermee wilde bereiken.

Het punt is dat de gebruikers van wat ik gemaakt heb kennelijk niet tellen als toets aan de praktijk. Ik heb vele honderden, zoniet duizenden projecten onder ogen gezien de afgelopen jaren, van databases waar ik nog snachts nachtmerries van heb tot prachtige modellen. Tuurlijk is er de afgelopen jaren geen 'baas' geweest of een collega met een uber-ego die mij wel even gaat vertellen hoe het allemaal zit, maar dat hoeft ook niet: als ik niet lever wat men in de praktijk kan gebruiken verkopen we niets.

Dit specifieke geval, PKs op subtype tables, is wel een aantal keren langsgekomen, steevast in databases waar maar wat aangeklooid was (de 'legacy' databases onder de legacy databases) en of dat gesupport kon worden. Er zitten een aantal bezwaren aan die niet echt wenselijk zijn, dus theorie is hier echt vereist. Zie mijn argumenten hierboven. Wanneer je niet binnen de theorie blijft en 'maar wat doet' loop je het risico dat men je software niet wil omdat het 'maar wat doet'. Mensen verwachten van frameworks en tools voor die frameworks dat deze werken, en foutloos zijn. Dan is er geen ruimte voor iets anders dan wat de theorie voorschrijft. Ookal is dat soms star.

Ik vind niks onzin, ik vind alleen dat je de theorie niet overal blind moet toepassen maar alleen waar dat zinnig is. Zelf nadenken. Om de derde normaalvorm er maar weer bij te halen: dat is ook computer science en in zijn algemeenheid past iedereen die ook netjes toe....tenzij het ergens niet zinnig is of er een andere reden is om dat niet te doen. Er zijn geen heilige huisjes, soms moet je gewoon eens van een standaard afwijken. Het is niet aan jou om te bepalen of dat in dit geval voor de topicstarter nu wel of niet zo is.

Afwijken van bewezen theorie kan IMHO alleen wanneer de nadelen van het afwijken van de theorie minder zwaar wegen dan de nadelen van de theorie zelf. Om on-topic te blijven: het kiezen van 1 table voor de gehele hierarchy ipv 1 table per subtype. Dat levert performance winst op, want je hoeft niet te joinen met alle subtype tables wanneer je een query voor een supertype uitvoert (daar hebben we TS nog niet over gehoord, maar dat komt nog wel denk ik ). Een van de nadelen is echter dat relationships van subtypes als constraints op de supertype table. Als dit voor lief wordt genomen omdat de performance winst hoog is, dan is dat inderdaad een goed keuze. Maar niet 'zomaar' even afwijken omdat je slimmer denkt te zijn dan de bedenkers van een theorie.

[Gomez12]

EfBe schreef op vrijdag 20 januari 2012 @ 16:43:
[...]
De row in 'villa' is dus maar de helft van de entity instance. Met 'row==entity instance' bedoelde ik dat er een verschil is tussen data en table definitie mbt 'entity'. Jij had het over nummeren van entities vs. nummeren van rows, maar dat is hetzelfde.

Is dat wel zo? Zijn het niet simpelweg 2 entities? Als ik even de OP erbij pak, dan is er qua naam en adres niets wat onlosmakelijk verbonden is met het soort woning.
Villa kan naar flat gaan en flat kan naar villa gaan, zonder dat naam en /of adres hoeft te wijzigen. In de praktijk zal het niet zo vaak gebeuren, maar theoretisch is het imho niet 1 complete entiteit

[EfBe]

Gomez12 schreef op vrijdag 20 januari 2012 @ 16:49:
[...]
Is dat wel zo? Zijn het niet simpelweg 2 entities? Als ik even de OP erbij pak, dan is er qua naam en adres niets wat onlosmakelijk verbonden is met het soort woning.

Hij zegt: "Een woning kan of een flat of een villa zijn". is-a relationship, dus lijkt me inheritance. Je voorbeeld is wel een leuke overigens:

Villa kan naar flat gaan en flat kan naar villa gaan, zonder dat naam en /of adres hoeft te wijzigen. In de praktijk zal het niet zo vaak gebeuren, maar theoretisch is het imho niet 1 complete entiteit

Je andere post er even bij halen, geeft wat meer context:

Simpel voorbeeld qua OP : flateigenaar behoudt dezelfde woning, maar verbouwt zijn flat om naar villa. Dat kan het theoretische model niet aan, praktijk zal waarschijnlijk gewoon zijn dat er 2 woningen komen op 1 adres, waarvan de flat vervallen is. Maar theoretisch is dit dan incorrect.

Wanneer een entity instance van type kan wijzigen in het domain zoals het er nu ligt (!) dan is inheritance gebruiken niet verstandig. Immers, dit is hetzelfde als wanneer je een object instantieert van een class en at runtime wijzig je dat in een totaal ander type (ben geen ruby specialist, maar volgens mij kan het zelfs daar niet echt in, en los daarvan, is het IMHO niet echt wenselijk).

Dus, stel dat het huidige domain dit toelaat, nl. dat een woning van type kan wijzigen: dan is inheritance niet nuttig en zou het model moeten wijzigen in 1 tabel voor woning met een type aanduiding (of wanneer het meerdere types kan hebben wellicht een 1:n relationship met 'woningtype' (NMe, jij mag deze erin denormaliseren dmv bitfields, hoor ). Deze wijziging is niet alleen in de database: ook in de code die de database gebruikt moet je deze wijziging doorvoeren, de types zijn immers daar ook in gebruik.

Inheritance in entity models is dus alleen nuttig wanneer de typen niet wijzigen. Een model met Employee <- Manager <- BoardMember is dan ook niet echt nuttig, een manager kan promoveren naar BoardMember, en dan? (ookal is het voor documentatie/uitleggen van inheritance soms wel makkelijk )

Het model zoals TS heeft behouden en toch type wijzigingen supporten zou ik niet doen, want de entity instances zijn verspreid over meerdere tabellen, en je krijgt vroeg of laat problemen in de code die de database gebruikt: bv wanneer je 1 row in woning deelt met een row in flat en een row in villa: dat levert 2 entity instances op in het OO programma wat de database gebruikt, en dus kun je 1 deleten en de andere updaten, terwijl dat niet zou mogen, immers het is dezelfde entity.

Geen idee of TS hier aan heeft gedacht.

[Gomez12]

EfBe schreef op vrijdag 20 januari 2012 @ 17:22:
[...]
Wanneer een entity instance van type kan wijzigen in het domain zoals het er nu ligt (!) dan is inheritance gebruiken niet verstandig.

Dus al je theoretisch correcte posts gaan over een onverstandig model?

Dat is namelijk precies het probleem met heel heel heel veel theoretisch correcte modellen, er wordt iets vergeten en ze donderen als kaartenhuizen in elkaar.

Dus, stel dat het huidige domain dit toelaat, nl. dat een woning van type kan wijzigen:

Het is irrelevant of het huidige domain het toelaat, dat zegt enkel maar of er rekening mee is gehouden met het opzetten van het domain. In de praktijk kan een flat naar een villa veranderen en vice versa.

Bedankt voor het goed aantonen waarom theoretisch correct in de praktijk niet alles is.

Het model zoals TS heeft behouden en toch type wijzigingen supporten zou ik niet doen

Ok, dan supporten we geen type wijzigingen want we hebben het niet meegenomen in het domain. Hoe krijg ik het dan theoretisch correct als iemand het toch doet?

[matthijsln]

Je bewaart even het adres, gooit je flat weg en maakt een nieuwe villa met hetzelfde adres... Voila een typewijziging. Het is namelijk niet dezelfde woning - je bouwt het opnieuw. Als je "tussenwoning" na het slopen van de huizen van de buren opeens een villa wordt ben je natuurlijk nog wel genaaid!

Is trouwens ook mooier, want stel dat er een foreign key relatie is gemaakt toen het nog een flat was (op basis van aannames die gelden voor flat en niet villa), bijvoorbeeld liftonderhoud en je maakt er een villa van, dan staat op een gegeven moment de onderhoudsmonteur voor de deur van je villa zonder lift. Als je het eerst had gedelete was ook het liftonderhoud gedelete.

edit: dit werkt natuurlijk wel goed als de liftonderhoud fk was naar het a_id van flat bij gebruik daarvan

[ Voor 7% gewijzigd door matthijsln op 20-01-2012 17:56 ]

[EfBe]

Gomez12 schreef op vrijdag 20 januari 2012 @ 17:43:
[...]
Dus al je theoretisch correcte posts gaan over een onverstandig model?

Nee, want een flat ombouwen tot een villa lijkt me onmogelijk, of bv het domain wat er ligt staat dit niet toe. Ook bv inheritance waar instances niet van typen kunnen wijzigen (bv het aloude voorbeeld animal<- Mammal <- Dog) gaat dit gewoon op. Normaliter kom je binnen domeinen niet zoveel situaties tegen waarbij entities van type moeten wijzigen EN men wil gebruik maken van inheritance. Mijn posts gingen louter over hoe het juiste relational model eruit ziet bij het converteren van entity model met inheritance naar relational model.

Overigens, als topicstarter had gemeld dat flats wel in villas kunnen veranderen had ik niet gepost wat ik had gepost, maar TS geadviseerd geen inheritance te gebruiken.

Dat is namelijk precies het probleem met heel heel heel veel theoretisch correcte modellen, er wordt iets vergeten en ze donderen als kaartenhuizen in elkaar.

Ik ben niets vergeten, het was niet gegeven. Het dondert ook niet in elkaar, het is een eis die een andere oplossing oplevert. Hetzelfde is een model maken en dan de wijziging krijgen dat een m:n relationship een eigen non-pk field krijgt. Dan moet je ook je model wijzigen _en_ je entity classes en je code.

[...]
Het is irrelevant of het huidige domain het toelaat, dat zegt enkel maar of er rekening mee is gehouden met het opzetten van het domain. In de praktijk kan een flat naar een villa veranderen en vice versa.

Als het domain voorschrijft dat het niet kan, kan het niet, het programma gaat het niet ondersteunen, dus een user kan deze wijziging niet maken.

Bedankt voor het goed aantonen waarom theoretisch correct in de praktijk niet alles is.

Extra eisen stellen aan je model die voorheen niet gegeven waren en waaruit blijkt dat een ander model nodig is, geeft aan dat het vorige model wat het gevolg was van een domain _ZONDER_ die eis fout is? het is gewoon een ander model, omdat een extra eis is toegevoegd. Beide modellen zijn correct binnen de eisen die gesteld zijn: de een is correct wanneer woningen _NIET_ van type wijzigen, en de ander is dat wanneer ze dat WEL kunnen. Dat staat los van het feit of het fysiek ook kan, het domain wat geanalyseerd is door de domain expert kan stellen dat woningen niet van type wijzigen (althans wijzigen in een type bekend binnen het systeem: van huis naar studentenwoning lijkt me mogelijk maar studentenwoning hoeft geen bekend type te zijn). Woningtypewijzigingen waren niet gegeven en flats en villas lijken me niet transformeerbaar in elkaar, dus heb ik dat genegeerd.

Tuurlijk, als TS had gesteld dat het wel mogelijk moet zijn, of wanneer het een ander domain betrof (bv de bekende puinhoop: Person <- Employee <- Customer, wat gebeurt er wanneer employee ook iets koopt?) dan is het gebruik van inheritance niet nuttig en volgt _een ander model_ uit de eisen van het domain, niet omdat 'in de praktijk theorie niet altijd werkt': je past in het geheel de theorie van transformatie van entity models naar relational models niet toe in dat geval!

[...]
Ok, dan supporten we geen type wijzigingen want we hebben het niet meegenomen in het domain. Hoe krijg ik het dan theoretisch correct als iemand het toch doet?

Hoe wou je het wijzigen wanneer je software het niet toelaat? Dus in TS' geval, omdat het niet gegeven is, is het _voor de software_ niet mogelijk. In het echte leven woont er een handige Nico in een armzalige serviceflat en die heeft veel te veel tijd en bouwt die hele flat om tot een 17 verdiepingen tellende supervilla Die Nico gaat dat melden bij de gebruikers van dit prachtige stukje software en krijgt te horen dat het niet mogelijk is: "Nico, je kunt geen flats in villas wijzigen". Nico weet wel beter, hij heeft het zweet nog diep in de oksels staan van het metselen en schilderen.

Dus, in zo'n situatie heb je een probleem, nl. de software is niet volledig: een feature mist: het wijzigen van een woningtype.

Hoe zou jij dat dan doorvoeren? Door even met een query tool wat statements uit te voeren en hop, wijzigen van woningen kan, althans in de database!. Nee, zo werkt het niet: door deze nieuwe eis kan de OO code niet gebruik maken van het type 'Villa' en 'Flat' maar alleen van 'Woning'. De code wijzigt dus, business rules wijzigen, en het entity model wijzigt door deze eis ook. Omdat dit model wijzigt, wijzigt het relational model ook, nl 3 tables worden 1 table: data wordt gemigreerd etc.

Heeft niets met 'theorie werkt in de praktijk niet' te maken, het domain met zn eisen verandert, je model wijzigt hierdoor en als resultaat krijg je andere software (!) met en andere database, waarbij Nico zn supervilla wel in past.

[Gomez12]

EfBe schreef op vrijdag 20 januari 2012 @ 18:08:
[...]
Nee, want een flat ombouwen tot een villa lijkt me onmogelijk, of bv het domain wat er ligt staat dit niet toe.

Eisen/toelatingen van het domain zijn irrelevant als je real world dingen erin wilt gaan opslaan.

Overigens, als topicstarter had gemeld dat flats wel in villas kunnen veranderen had ik niet gepost wat ik had gepost, maar TS geadviseerd geen inheritance te gebruiken.

Topicstarter heeft niets te zeggen over wat een flateigenaar met zijn flat op zijn grond mag doen.

[...]
Ik ben niets vergeten, het was niet gegeven.
...
Als het domain voorschrijft dat het niet kan, kan het niet, het programma gaat het niet ondersteunen, dus een user kan deze wijziging niet maken.

Ah, de eeuwige theoreticus. Het is niet gegeven, dus het kan niet.

[...]
Extra eisen stellen aan je model die voorheen niet gegeven waren en waaruit blijkt dat een ander model nodig is, geeft aan dat het vorige model wat het gevolg was van een domain _ZONDER_ die eis fout is? het is gewoon een ander model, omdat een extra eis is toegevoegd.

Het is geen ander model, het 1e model bevat enkel een dingetje wat over het hoofd gezien is. Door dat ene dingetje ga jij je focussen op een model wat theoretisch klopt, maar niets meer met de praktijk te maken heeft.

Hoe zou jij dat dan doorvoeren? Door even met een query tool wat DDL SQL statements uit te voeren en hop, wijzigen van woningen kan, althans in de database!. Nee, zo werkt het niet: door deze nieuwe eis kan de OO code niet gebruik maken van het type 'Villa' en 'Flat' maar alleen van 'Woning'. De code wijzigt dus, business rules wijzigen, en het entity model wijzigt door deze eis ook. Omdat dit model wijzigt, wijzigt het relational model ook, nl 3 tables worden 1 table: data wordt gemigreerd etc.

Mijn oplossing heb ik al gegeven (en past ook in jouw oplossing, enkel is niet correct volgens de theorie) nl : nieuwe woning aanmaken met zelfde naam en adres en oude woning laten vervallen. Maarja, dat is weer niet correct volgens de theorie van de 1e normaalvorm.

Heeft niets met 'theorie werkt in de praktijk niet' te maken, het domain met zn eisen verandert, je model wijzigt hierdoor en als resultaat krijg je andere software (!) met en andere database, waarbij Nico zn supervilla wel in past.

Lang leve de heilige theorie, we gaan een db conversie en nieuwe software release doen op het moment dat er 1 uitzondering is waar niet aan gedacht is.

Doe mij dan maar de praktijk waar ik een "zooi" maak door de normaalvorm te overtreden heb ik iets sneller correcte data dan met jouw volgens de theorie correcte manier van werken.

[Killemov]

Als het gaat om zwakke entiteittypen ( subclass ) dan is het opnemen van extra keys gewoon fout. De enige uitzondering die hierop geld is als een zwak entiteittype op zijn beurt weer uniek identificeerbaar moet zijn. Even een voorbeeldje uit het hoofd is de Order/Orderregel relatie waarbij de Orderregel ook weer uniek identificeerbaar moet zijn. Het gaat dan altijd om een samengestelde PK. Als dat, om wat voor reden dan ook, op een andere manier wordt geïmplementeerd dan wordt er bewust een fout gemaakt.

Dus in geval van de TS heeft de TS het juist. Want er zijn geen Villa's en Flats die geen Woning zijn.

Janoz schreef op donderdag 19 januari 2012 @ 12:05:
Hoewel je collega's niet een duidelijk argument hebben waarom er perse een ID meot zijn, klopt je eigen argumentatie ook niet. Om woningId in flat of villa uniek te houden ben je niet verplicht om daar de primary key van te maken. Een unique constraint is voldoende.

Zeker weten? Doe daar dan voor de lol toch ook maar een not null bij ... Oh ja, dan hebben we het semantisch toch al over een PK.

NMe schreef op donderdag 19 januari 2012 @ 12:28:
Zelfs als het overbodig is, wat maakt het uit? Met unique index is het alsnog bloedsnel en hou je alsnog de mogelijkheid open dat er later alsnog huizen kunnen zijn die zowel villa als flat zijn, ook al heb je dat nu niet nodig.

Het maakt niet uit, maar het is wel fout. De door jou genoemde mogelijkheid is er nu ook al. Alleen de situatie dat Flats en Villa's geen Woningen zijn kan niet.

Waking_The_Dead schreef op donderdag 19 januari 2012 @ 12:39:
Een argument voor de oplossing van je collega's is ook consistentie. Als je sowieso voor elke tabel een auto-increment gebruikt als PK, dan is dat veel gemakkelijker naar onderhoud toe. Door het gebruik van een auto-increment in combinatie met een foreign key kan iemand die eventueel na jou het project moet overnemen, veel eenvoudiger zien wat jouw bedoeling was. Door de PK van woning over te nemen in andere tabellen bezorg je jouw eventuele opvolger alleen maar last.

Voor eventuele performance moet je het in elk geval niet doen.

Dus je bedenkt iets "extra's" dat geen eigen betekenis heeft en daarmee ken je aan het geheel meer betekenis toe? Gemakkelijker in onderhoud? Dat ligt dan waarschijnlijk meer aan het databaseprodukt dan aan deze materie.

Ik vind dat met name "Waking the Dead" en "driven bij rage" nogal vasthouden aan de "Ik heb het altijd zo gedaan en het werkt toch?" -ervaring. Nogmaals, no offense, er kunnen genoeg redenen om het lekker toch met een extra serial PK te doen ... maar het is fout.

Ik zou, als het een belangrijk onderdeel zou betreffen, zeker in mijn stageverslag opnemen dat ik tot een bepaalde keuze zou zijn gedwongen zonder daarbij een afdoende verklaring te hebben gekregen.

[Killemov]

@Gomez en @EfBe, in de praktijk zouden er redenen kunnen zijn om wel PK bij Flat en Villa (Wie meervoud gebruikt ... ?) op te nemen. Die heeft de TS alleen niet gekregen en nu heeft de TS een soort probleem van omgekeerde bewijslast.

[Waking_The_Dead]

Gast, ik begrijp niet echt wat jouw probleem is. TS vraagt iets, ik geef een antwoord maar jij harkt dat ondersteboven als zijnde niet nuttige info. Na wat gezeik kom je met de bovenstaande post die jouw gelijk kennelijk moet aangeven en dat ik niet weet waarover ik praat.

Wie heeft hier een probleem? Dat heb ik toch allemaal niet gezegd. Waar haal je dat in godsnaam? Jouw antwoord is inderdaad theoretisch goed onderbouwd en legt perfect uit waarom TS zijn aanpak volgens de theorie correct is. Dat heb ik nergens ontkend en ik heb al helemaal niet gezegd dat je niet weet waarover je praat. Jij bent degene die de rest van de posters in deze thread kleineert en je wil niet inzien dat je je in een praktijksituatie bijna nooit aan de theorie kunt houden. DAT is het enige wat ik zeg.

Ik vind dat met name "Waking the Dead" en "driven bij rage" nogal vasthouden aan de "Ik heb het altijd zo gedaan en het werkt toch?" -ervaring. Nogmaals, no offense, er kunnen genoeg redenen om het lekker toch met een extra serial PK te doen ... maar het is fout.

Misschien dat je het zo begrepen hebt, maar dat is niet mijn bedoeling. Mijn punt is dat je in de praktijk de theorie bijna nooit perfect kan toepassen omwille van factoren als: slechte collega's, framework met beperkingen, tijdsdruk, lastige klant....
Ik zeg nergens dat het zo MOET, ik zeg gewoon dat het meestal anders uitdraait dan dat je zou willen omwille van de zonet genoemde factoren.

[ Voor 29% gewijzigd door Waking_The_Dead op 20-01-2012 18:47 ]

[Gomez12]

Killemov schreef op vrijdag 20 januari 2012 @ 18:32:
Ik zou, als het een belangrijk onderdeel zou betreffen, zeker in mijn stageverslag opnemen dat ik tot een bepaalde keuze zou zijn gedwongen zonder daarbij een afdoende verklaring te hebben gekregen.

Lol, zet je er dan ook even een situatieschets bij met mes op de keel, pistool tegen het hoofd etc?

En bedrijfsstandaard is zeker voor een tijdelijke stagair een afdoende verklaring. Helemaal als hij zelf al ziet dat het ook in het framework etc zo is opgenomen.

Wow, het is anders dan in het boekje staat, maar blijkbaar is het wel consequent doorgevoerd. Dat is een leermoment (waarvoor denk je dat een stage is) van hoe de theorie niet overal 100% correct doorgevoerd hoeft te zijn. Waar zelfs het naderhand toevoegen van theoretisch correcte dingen in het eindstuk simpelweg fout handelen is.

Je zit op een stage om te leren, niet om maar van iedereen verklaringen te krijgen waarom zij iets anders doen dan dat er in jouw boekje staat.

Waking_The_Dead schreef op vrijdag 20 januari 2012 @ 18:43:
[...]
Jij bent degene die de rest van de posters in deze thread kleineert en je wil niet inzien dat je je in een praktijksituatie bijna nooit aan de theorie kunt houden. DAT is het enige wat ik zeg.

Lees zijn laatste post, je kan je perfect aan de theorie houden. Simpelweg bij elk hiccupje een dbase-conversie en een nieuwe release uitbrengen. Maarja, kosten-baten analyses zullen theoretisch dan ook wel niet theoretisch interessant zijn.

[Killemov]

Gomez12 schreef op vrijdag 20 januari 2012 @ 18:54:
[...]

Lol, zet je er dan ook even een situatieschets bij met mes op de keel, pistool tegen het hoofd etc?

En bedrijfsstandaard is zeker voor een tijdelijke stagair een afdoende verklaring. Helemaal als hij zelf al ziet dat het ook in het framework etc zo is opgenomen.

...

Lees zijn laatste post, je kan je perfect aan de theorie houden. Simpelweg bij elk hiccupje een dbase-conversie en een nieuwe release uitbrengen. Maarja, kosten-baten analyses zullen theoretisch dan ook wel niet theoretisch interessant zijn.

Je zou er inderdaad om kunnen lachen als je zelf niet met de gevolgen wordt geconfronteerd. De TS moet wellicht zijn keuzes tegenover de opleiding verdedigen en voor de ene opleiding zal het niets uitmaken en voor de andere een punt in mindering. Ik roep maar wat.

Was die laatste opmerking ook aan mij gericht? Wel eens een situatie meegemaakt waarbij de kosten-baten analyse van een changerequest door een externe partij moest worden verricht? De evaluatie daarvan door een andere externe partij moest worden verricht en de request uiteindelijk op de kosten werd afgeschoten? En dat vervolgens duidelijk wordt dat de kosten van de analyse 60% van de ruwweg ingeschatte kosten van de request bedroegen?

Maar goed, het uitgangspunt zou natuurlijk niet het afwijken van de theorie moeten zijn. Toch?

[Gomez12]

Killemov schreef op vrijdag 20 januari 2012 @ 19:08:
[...]
Je zou er inderdaad om kunnen lachen als je zelf niet met de gevolgen wordt geconfronteerd. De TS moet wellicht zijn keuzes tegenover de opleiding verdedigen en voor de ene opleiding zal het niets uitmaken en voor de andere een punt in mindering. Ik roep maar wat.

Als jij termen als gedwongen gaat gebruiken in je stage-verslag / verdediging dan mag ik toch hopen dat je minpunten krijgt. Als jij je op je stage gedwongen ergens toe voelt zit je daar simpelweg echt verkeerd.

Je kan orders krijgen, je kan verplicht iets moeten doen, maar gedwongen worden? En helemaal gedwongen worden zonder een afdoende verklaring dat mag een kind van 5 zeggen, maar geen volwassen werknemer in NL.

Maar goed, het uitgangspunt zou natuurlijk niet het afwijken van de theorie moeten zijn. Toch?

Het allereerste initiele uitgangspunt moet zijn dat het volgens de theorie klopt, maar gaandeweg het proces kom je meer dan genoeg redenen tegen om van de theorie af te wijken en iets voor de praktijk te bouwen.
Zoals ik al zei, je kan kanttekeningen plaatsen bij het framework etc in de hoop dat ze daar volgend jaar een andere stagair naar laten kijken, maar als jij met een backbone + collega's zit die niet voldoen aan de theorie uit jouw boekje zou ik zeker niet stug vastblijven houden aan de theorie.
Binnen een bestaand systeem heb je meer te maken met de bestaande praktijk dan met de theorie uit het boekje.

[EfBe]

Gomez12 schreef op vrijdag 20 januari 2012 @ 18:54:
Lees zijn laatste post, je kan je perfect aan de theorie houden. Simpelweg bij elk hiccupje een dbase-conversie en een nieuwe release uitbrengen. Maarja, kosten-baten analyses zullen theoretisch dan ook wel niet theoretisch interessant zijn.

Erm... wat ik schetste is precies hoe je zo'n wijziging moet doorvoeren omdat die wijziging _alle_ lagen van de applicatie raakt. Als een wijziging in de applicatie een database wijziging vereist dan moet je die doorvoeren ja, ik snap niet echt waarom dat niet nuttig zou zijn, of sterker: hoe je die database wijziging _niet_ hoeft doorvoeren en toch de functionaliteitswijziging kan doorvoeren. Oh wacht, natuurlijk, door gewoon de 'theorie de theorie te laten en verder lekker in de praktijk maar wat aan knoeien', toch?

Anyway, ik heb gezegd wat ik wilde zeggen en ik hoop dat het TS helpt en dat het de lurkers in deze thread helpt. Veel plezier nog met het uitleggen hoe het dan allemaal wel moet, je weet wel, hoe ECHTE specialisten zoals jij het allemaal wel even oplossen, Gomez

Btw, je mag me wel proberen in de hoek te zetten als 'eeuwige theoreticus', en doen voorkomen alsof ik de praktijk niet ken, maar ik ben geen een of andere leraar, Gomez, wiens spullen niet in de praktijk worden gebruikt door duizenden bedrijven en nog meer projecten. Als wat ik vertel niet zou werken in de praktijk, had ik allang iets anders moeten doen voor de kost. Sterker, mijn software is juist zo flexibel dat het met veel in de praktijk voorkomende alternatieven kan werken ipv alleen 'dit is wat boekje ABC zegt en dus doen we het zo'. Hoe zou dat komen als ik de eeuwige theoreticus zou zijn zonder kennis hoe men het 'in de praktijk' oplost?

Ik begrijp je vijandigheid niet echt, alsof je moet bewijzen dat wat ik aandroeg te debiel voor woorden is, zeker wanneer je het ook nog eens in de praktijk gaat toepassen! Jammer, want ipv dat je dingen aandraagt die legitieme bezwaren zijn tegen het gebruik van inheritance gebaseerde modellen, ga je zitten zeiken over 'theorie vs. praktijk'. Typical.

[ Voor 30% gewijzigd door EfBe op 21-01-2012 12:01 ]

[JaQ]

Hoe komt het toch dat ieder topic over normalisatie eindigt in een soort religieuze oorlog waarbij het aantal jaren dat je in die oorlog rond loopt ook nog van belang is?

De TS heeft m.i. een redelijk standaard probleem waar veel over is gepubliceerd. Oracle noemt de oplossing voor dit probleem een "arc". Andere venders hebben ongetwijfeld een andere naam bedacht voor dit probleem, echter daar ben ik niet mee bekend.

quote: http://docs.oracle.com/cd.../e13677/data_modeling.htm

An arc is an exclusive relationship group, which is defined such that only one of the relationships can exist for any instance of an entity. For example, a seminar may be able to be taught by a staff member or an external consultant, but not by both. As examples, a seminar for new employees can be taught only by a corporate staff member, while a seminar in using Product XYX can be taught only by an external consultant with special qualifications.

All relations included in an arc should belong to the same entity and should have the same cardinality Any foreign unique identifier (foreign UID) attributes belonging to relationships in an arc should be transferred as Allow Nulls during forward engineering. The meaning of mandatory relationships in an arc is that only one relationship must exist for a given instance of an entity.

In de praktijk zie ik 3 implementatie van een arc probleem. Voor de detail-tables geldt:
1. PK = FK
2. PK op auto increment + "echte" verwijzende sleutel in tweede kolom met unieke index
3. Geen detail tabel opnemen en denormaliseren.

Optie 1 is theoretisch de juiste, optie 2 is de implementatie van optie 1 noodzakelijk door een brakke implementatie van sommige OR-mappers (hybernate als ik mij niet vergis?), optie 3 kan voor sommige use-cases beter performen.

Welke optie de juist is voor de TS, is afhankelijk van de technische omgeving (b.v. type database, OR mapper) en de specifieke use case. Zelfs aanwezige kennis kan als argument meewegen in de beslissing, immers een theoretisch correcte oplossing die voor niemand in een bedrijf te onderhouden is, is ook een foute keuze.

[Anoniem: 241683]

hibernate kan prima werken met een fk als sleutel, is alleen wat meer gepruts

[com2,1ghz]

Systeem is ouder dan 10 jaar en toen bestond hibernate nog niet. Daarvoor is er een eigen variant van ORM ontwikkeld.

[alwinuzz]

Maar als het systeem zo oud is, dan houd je je toch lekker aan de standaarden binnen het systeem?


Over een tijdje krijgen we van jouw opvolger een post in de Coffee Corner:

"Ik werk hier in een 10 jaar oud systeem waar elke tabel in de DB een uniek ID heeft. Duidelijk en makkelijk zou je denken. Maar nou heeft net één tabel die ID niet! Blijkt dat een of andere stagiair dat niet nodig vond. Ook nergens gedocumenteerd natuurlijk... Lekker consequent jongens!"

Ik zie het al voor me