[database]Gebruik van globale primary key

[Boss]

Voor een nieuwe database die wij aan het ontwerpen zijn willen we gebruik maken van globale primary keys, die allemaal gebruik maken van dezelfde generator.

Bijvoorbeeld:
Bedrijf heeft ID 1 en de bijbehorende contactpersonen ID 2 en 3. Er kan dan niet ook een bedrijf zijn met ID 2 (die ID is immers al aan een contactpersoon gegeven). Het volgende nieuwe bedrijf krijgt dus ID 4.

We zien hier eigenlijk alleen maar voordelen in: als je het ID weet van een record, weet je direct wat voor een type dat is. Zeker gezien de relatie-mogelijkheden die het bovenliggende programma moet gaan krijgen een voordeel.

De gebruiker krijgt zelf nooit het ID van een record te zien, dus vragen over vreemde hoog oplopende ID's hebben we niet.

Heeft iemand ervaring met een dergelijke opzet, en zijn er ook nadelen waar we in het ontwerpstadium nog rekening mee kunnen houden?

[EnnaN]

er gaan vast meer mensen hier iets van zeggen, maar het lijkt me nogal waanzin? Normaliter zou je gewoon een bedrijf-tabel hebben, en een contactpersonentabel. en die laatste heeft naast een contactpersoon-id ook een bedrijf-id.... ik zie geen reden om daar van af te wijken?

[justmental]

Dus als iemand het over id 15787432356 heeft moet je met dat id in alle tabellen kijken om te weten over welk gegeven hij het heeft?

[whoami]

Als je dat wil doen, gebruik dan GUID's.
Nadeel van guid's is wel dat indexen hier wat trager kunnen zijn, aangezien je minder keys in een node kunt krijgen.
Als je gebruik maakt van SQL Server, is het ook geen goed idee om een clustered index op een GUID te leggen, aangezien GUID's niet sequentieel zijn (alhoewel ik dacht dat er nu ook een sequentiele GUID implementatie bestaat).

Maar de voordelen die jij ziet, zie ik niet. Als je het ID weet, weet je nog altijd niet in welke tabel dit id zich bevind , dus je weet nog altijd niet met welke entity je te maken hebt.

Ik heb hier wel een DB waar ik GUID's gebruik als PK, maar dan wel met een ander doel: nl. omdat m'n database in replicatie staat, en m'n PK ook meteen m'n ROWGUIDCOL is voor mijn replactie.

[ Voor 14% gewijzigd door whoami op 28-03-2008 16:36 ]

[TheDane]

Wel ervaring mee. Onze systemen maken gebruik van zogenaamde "objecten". Al deze objecten hebben 1 system-wide sequence voor de primary keys.

Alle objecten hebben enkele gemeenschappelijke kenmerken, zoals creator, date_creation etc. Die komen allemaal in 1 tabel met een auto-increment veld. Het ID wordt dan teruggegeven aan de applicatie, waarna de object-specifieke kenmerken in de betreffende tabel wordt ingevoegd.

Vooralsnog biedt dat inderdaad alleen maar voordelen, je weet 't type direct, en kunt vrij eenvoudig een solide crud-achtig framework opbouwen. structuur en relaties is erg simpel, een object_hierarchy tabel met id + parentID velden, en thats it.

[Voutloos]

Ja, ga vooral nog meer waarde hechten cq inhoud geven aan een synthetishe key.

[The Eagle]

Wij hebben in ons ERP pakket wel zoiets, maar daar hebben we eigenlijk simpelweg een record met diverse volgnummers die telkens als er 1 wordt toegekend, wordt opgehoogd. Kwestie van een stukje logica inbouwen. Ook makkelijk bij te houden mocht je eens op een andersoortige reeks overgaan

[Boss]

Het programma gaat uiteindelijk gebruikt worden om communicatiegegevens bij te houden. Hier zijn nogal wat mogelijkheden in: een medewerker (persoon id) praat met een contactpersoon (persoon id) over een bedrijf (bedrijf id). Dit gesprek gaat inhoudelijk over een contract (contract ID) of over een xxx (xxx ID) en zo is er nog een aantal entiteiten.

Nu kunnen we in de tabel met communicatiegegevens een heleboel velden maken voor alle mogelijke foreign keys. Of een koppeltabel per FK type. En zo zijn er nog andere oplossingen te bedenken.

Een nadeel kan inderdaad zijn dat wanneer je echt niet weet wat voor type een bepaald ID is, je in een paar tabellen moet gaan zoeken.

Dus als iemand het over id 15787432356 heeft moet je met dat id in alle tabellen kijken om te weten over welk gegeven hij het heeft?

Gebruikers hebben het niet over ID's. Die zien alleen de bijbehorende gegevens. In de meeste gevallen is goed vast te leggen wat de 'logische' relatie is (bedrijven-contactpersonen). Er zijn echter ook situaties, zoals hierboven beschreven, waar in meerdere tabellen gezocht moet worden. Maar voor de betreffende queries had dat anders ook nodig geweest, alleen dan steeds op andere velden.

Als je dat wil doen, gebruik dan GUID's.

Waarom, als dat alleen maar trager is?

[rinkel]

Boss schreef op vrijdag 28 maart 2008 @ 16:12:
Voor een nieuwe database die wij aan het ontwerpen zijn willen we gebruik maken van globale primary keys, die allemaal gebruik maken van dezelfde generator.

Bijvoorbeeld:
Bedrijf heeft ID 1 en de bijbehorende contactpersonen ID 2 en 3. Er kan dan niet ook een bedrijf zijn met ID 2 (die ID is immers al aan een contactpersoon gegeven). Het volgende nieuwe bedrijf krijgt dus ID 4.

Klein vraagje..

Vervolgens heeft het nieuwe bedrijf ID 4 gekregen.
Nu krijgt bedrijf met ID1 er een contactpersoon bij.. hoe ga je dit dan oplossen ?

[Gé Brander]

Boss schreef op vrijdag 28 maart 2008 @ 16:52:

gebruikers niet nee, maar hoe wil je de logica gaan bouwen die een id krijgt, en dat je programma dan snel weet welke table deze moet hebben?

[...]

Waarom, als dat alleen maar trager is?

Omdat je ook sequentiele id's hebt inderdaad, en de guid's gegarandeerd uniek zijn.

[SPee]

Voor jouw idee, moet je 1 sequence maken, welke steeds verhoogt wordt.

Een GUID is niet in jouw voobeeld te gebruiken, aangezien het een hex. string is die uniek is en niet oplopend. Het gebruikt o.a. datum/tijd om de code te berekenen.

Echter, met een opzet zoals jij beschrijft, krijg je toch problemen.
Als je voor klant en bedrijf een nieuwe ID toevoegt, krijgt elk de volgende ID.
-bedrijf 1: 1
-klant bij bedrijf 1: 2
-klant bij bedrijf 1: 3
-bedrijf 2: 4

Echter, voeg je een nieuwe klant toe bij bedrijf 1, krijg deze de waarde 5.
Dus je kunt niet zeggen van 1 tot 4 zijn enkel voor bedrijf 1. Je mist er een paar.

En keys updaten

[Creepy]

Begrijp ik nu goed dat je 1 koppel tabel wilt hebben om verschillende n:m relaties te gaan mappen? Of dat het ID in 1 veld bepaald wat voor type relatie je hebt? Laat dat aub niet afhangen van je ID. Gebruik er of losse velden (voor 1:n relaties) of meerdere koppel tabellen (voor n:m) relaties voor. Een betekenis aan een los ID hangen is geen goed idee.

zeg nu zelf, wat is duidelijker:

"Eehh.. was ID 2334 nu een bedrijf, contactpersoon of een contract? Controleer dat ff in de verschillende tabellen om te kijken waar dat ID in bestaat"

of een veld bedrijfId, contactpersoonId of contractId waar de kolom al bepaald wat voor type het is.

Op het moment dat je algemene object aan het opslaan bent om alles in je eigen DB op te kunnen slaan zonder je DB aan te kunnen passen ben je een DB in een DB aan het bouwen en verlies je een aantal voordelen van het gebruik van een DB. In de meeste gevallen ben je dan verkeerd bezig.

Dat je nu toevallig 1 sequence gebruikt voor meerdere ID's, ok. Het enige nadeel hieraan is dat je sneller aan je maximum waarde van je sequence zit.

We zien hier eigenlijk alleen maar voordelen in: als je het ID weet van een record, weet je direct wat voor een type dat is. Zeker gezien de relatie-mogelijkheden die het bovenliggende programma moet gaan krijgen een voordeel.

Ik snap dan ook niet wat voor voordeel je hier in ziet dat je aan het ID zelf direct het type kan bepalen? Wat zie je dan nu echt als voordeel?

[ Voor 50% gewijzigd door Creepy op 28-03-2008 17:08 ]

[Boss]

gebruikers niet nee, maar hoe wil je de logica gaan bouwen die een id krijgt, en dat je programma dan snel weet welke table deze moet hebben?

Er wordt een nieuwe contactpersoon gemaakt: GetNewID (van de globale ID generator). Die wordt als PK gebruikt in de conactpersonentabel. Geen probleem, lijkt me.

Echter, voeg je een nieuwe klant toe bij bedrijf 1, krijg deze de waarde 5.
Dus je kunt niet zeggen van 1 tot 4 zijn enkel voor bedrijf 1. Je mist er een paar.

En keys updaten

Je kunt wel zeggen: alle contactpersonen met een BedrijfID 1 horen bij bedrijf 1. En alle contactpersonen met BedrijfID 2 horen bij bedrijf 2. Keys hoef je dan helemaal niet te updaten, mocht dat al een probleem zijn.

Misschien nog een stukje verduidelijking:
Er is een aantal redelijk harde relaties, zoals tussen contactpersonen en bedrijfid. Iedere contactpersoon is bij precies 1 bedrijf werkzaam, en heeft dus netjes een BedrijfID in de tabel staan. Hiervoor heeft het gebruik van globale ID's geen voordeel of nut.

Er zijn ook gegevens die dus wel met alle mogelijke andere gegevens gekoppeld kunnen worden. Dat is vooral het geval bij de communicatietabel die ik hierboven heb beschreven. Daar komt een 1-n relatie tussen het communicatie-item en alle gerelateerde items. Die gerelateerde items kunnen dus van alles zijn: contactpersonen, bedrijven, xxxx
Hiervoor heeft het gebruik van globale ID's een dudelijk voordeel, omdat in de koppeltabel niet voor iedere mogelijke koppeling een aparte kolom gemaakt hoeft te worden om aan te geven naar welke tabel de koppeling zou moeten lopen.

[Boss]

We zien hier eigenlijk alleen maar voordelen in: als je het ID weet van een record, weet je direct wat voor een type dat is.

Dat heb ik misschien niet zo handig opgeschreven: je weet het niet direct. Je kan het uitzoeken door in alle tabellen te kijken.

[curry684]

Boss schreef op vrijdag 28 maart 2008 @ 16:12:
Zeker gezien de relatie-mogelijkheden die het bovenliggende programma moet gaan krijgen een voordeel.

Kun je me dit eens langzaam in Jip&Janneke taal uitleggen want ik kan me er verbazend weinig bij voorstellen.

[Boss]

Kun je me dit eens langzaam in Jip&Janneke taal uitleggen want ik kan me er verbazend weinig bij voorstellen.

Een voorbeeld. We hebben:
- groentes
- dieren
- kleuren
- auto's

Die staan allemaal in een eigen tabel. Nu gaan we een logboek bijhouden waarin we vastleggen dat jij en ik hebben gesproken.
We kunnen over verschillende dingen praten: 2 kleuren en een dier. Of over 1 auto. Of over een kleur, een auto en een dier. Of over iedere andere willekeurige combinatie.

En over een tijdje voegen we nog wat toe: muziekstukken. Ook daar kunnen we dan over gaan praten.

Dat is wat we willen opslaan, en wat we met gebruik van globaal unieke ID's goed denken te realiseren.

[Gomez12]

Boss schreef op vrijdag 28 maart 2008 @ 17:19:
[...]

Dat heb ik misschien niet zo handig opgeschreven: je weet het niet direct. Je kan het uitzoeken door in alle tabellen te kijken.

Ehm, dus het programma wordt een succes, je krijgt 200 miljoen regels verspreid over allemaal tabellen, je hebt een grote kans dat je binnenkort tegen je max veldwaarde van je key aanloopt ( en dan hernummeren??? ), en als je ergens iets zoekt dan ploeg je de hele dbase maar eventjes door???

Boss schreef op vrijdag 28 maart 2008 @ 17:27:
[...]

Een voorbeeld. We hebben:
...
Die staan allemaal in een eigen tabel. Nu gaan we een logboek bijhouden waarin we vastleggen dat jij en ik hebben gesproken.
We kunnen over verschillende dingen praten: 2 kleuren en een dier. Of over 1 auto. Of over een kleur, een auto en een dier. Of over iedere andere willekeurige combinatie.

En over een tijdje voegen we nog wat toe: muziekstukken. Ook daar kunnen we dan over gaan praten.

Dat is wat we willen opslaan, en wat we met gebruik van globaal unieke ID's goed denken te realiseren.

Het voorbeeld zal wel verkeerd zijn, maar is het niet handiger om een tabel gesprek op te zetten met daarin gesprekspartners (n:m) en gespreksonderwerpen. Een gespreksonderwerp duidt een object x aan dat bestaat uit een aantal andere tabellen.

[curry684]

Boss schreef op vrijdag 28 maart 2008 @ 17:27:
[...]

Dat is wat we willen opslaan, en wat we met gebruik van globaal unieke ID's goed denken te realiseren.

En is het niet stukken handiger om in deze logtabel heel verbose in een text-field op te slaan 'Prei van het type groente' dan een nietszeggende GUID waarvoor je alle tabellen in je database op basis van metadata door te spitten?

[dusty]

Boss schreef op vrijdag 28 maart 2008 @ 16:12:
[..]
als je het ID weet van een record, weet je direct wat voor een type dat is. Zeker gezien de relatie-mogelijkheden die het bovenliggende programma moet gaan krijgen een voordeel.

De gebruiker krijgt zelf nooit het ID van een record te zien, dus vragen over vreemde hoog oplopende ID's hebben we niet.
[..]

De gebruiker ziet de ID niet, dus wie weet dan de ID van een record en hoe komt die eraan? Juist die moet dus opgezocht worden in de database, waar je dus moet weten WAT je al zoekt.

De gebruiker ziet de ID niet, dus wat die ID zegt maakt ook niets uit, waardoor je makkelijk een bedrijf met ID 2 kan hebben EN een persoon met het ID 2.

Uiteraard kan je wel een generieke ID hebben voor alle objecten, maar dan zal je een tabel moeten hebben met dat generieke ID en dan een column "Type" waarin je aangeeft wat voor object het is. ( Bedrijf, Persoon, Plaatje, Link, Bericht, Communicatie, Werkorder, Vakantie aanvraag etc.) Immers waarom zou je stoppen met alleen Bedrijven en Personen, immers als je Werkorders er ook in zet kan daar ook geen verwarring over ontstaan immers kan je dan meteen zien dat een bepaalde ID niet een bedrijf of persoon is maar bijvoorbeeld een werkorder..

In dat geval kan je uiteraard drie extra columns erbij zetten een "Value" en een "parent-ID" en een "Type-Parent-ID" die naar dezelfde tabel verwijst, daardoor kan je de properties van een bepaald object ( bijvoorbeeld Geboorte Datum, adres, naam) als een property-type in dezelfde tabel gooien, met de value van het adres. Waardoor je met een Type weet dat het een property is, de type-parent-id zal aangeven dat het om een adres gaat, (want de value waarde van de ID is "Adres" gedefinieerd door de type-property, de parent-ID geeft aan bij welke ID deze property behoort. Als je dan een ID hebt kan je je ook niet vergissen dat de ID een persoon of bedrijf is maar dat het uiteindelijk een adres is. Dit betekent dus dan ook meteen dat je je hele database design binnen een tabel hebt opgelost.

[JaQ]

dusty schreef op vrijdag 28 maart 2008 @ 20:11:
[...]
Dit betekent dus dan ook meteen dat je je hele database design binnen een tabel hebt opgelost.

Praktijk wijst uit dat je het uiteindelijk in 5 tabellen moet doen, maar goed.. je verwoordt het goed. Buiten de performanceproblemen qua queries geeft het ook enorme contentie op je ene sequence, locking problemen van hier tot tokio etc.

1 sequence voor alle betekenisloze sleutels is niet fout, maar ik zou het persoonlijk nooit doen.

[Boss]

curry684 schreef op vrijdag 28 maart 2008 @ 17:52:
[...]

En is het niet stukken handiger om in deze logtabel heel verbose in een text-field op te slaan 'Prei van het type groente' dan een nietszeggende GUID waarvoor je alle tabellen in je database op basis van metadata door te spitten?

Dit is natuurlijk maar een voorbeeld, het gaat uiteindelijk om verschillende soorten gegevens die onder andere via de 'communicatie-tabel' relaties met elkaar hebben. En aangezien het wenselijk is om hier op te rapporteren en vanuit verschillende invalshoeken queries op te draaien is enige vorm van normalisatie wenselijk. Om maar even in hetzelfde voorbeeld te blijven: met welke groentes is over een kleur gesproken, en dat soort overzichten.

Het voorbeeld zal wel verkeerd zijn, maar is het niet handiger om een tabel gesprek op te zetten met daarin gesprekspartners (n:m) en gespreksonderwerpen. Een gespreksonderwerp duidt een object x aan dat bestaat uit een aantal andere tabellen.

En het onderwerp, object x, kan er eentje zijn van 5 verschillende types. Hoe ga je daar mee om? Voor alle 5 de mogelijke types een kolom toevoegen, waarvan er telkens maar 1 gevuld is? Dat is inderdaad het alternatief. Iedere tabel zijn eigen reeks voor de ID's zoals gebruikelijk. En waar een koppeltabel nodig is, voor alle tabellen waar mogelijk een koppeling naar gemaakt kan worden een kolom toevoegen.

Ehm, dus het programma wordt een succes, je krijgt 200 miljoen regels verspreid over allemaal tabellen, je hebt een grote kans dat je binnenkort tegen je max veldwaarde van je key aanloopt ( en dan hernummeren??? ), en als je ergens iets zoekt dan ploeg je de hele dbase maar eventjes door???

Voor de meest voorkomende relaties weten we vooraf tussen welke twee tabellen de relaties liggen (zoals contactpersoon - bedrijf). In een aantal gevallen willen we hier flexibeler mee zijn en daarom lijken de globale keys een oplossing.
Overigens denk ik dat er weinig problemen ontstaan met de max waarde van de key. Laten we het voor het gemak even op een long integer houden Als je al tegen een max waarde aanloopt is hernummeren geen noodzaak of onoverkomelijk probleem bij het aanpassen van het type van een veld.

[Gé Brander]

Nog steeds zie ik het voordeel er niet van. Kan je dat nog eens uitleggen?

edit: kom eens met een link waar je dit idee vandaan hebt.

[ Voor 29% gewijzigd door Gé Brander op 29-03-2008 10:07 ]

[Maasluip]

Ik zie het voordeel ook niet.

Als dat ID extern bekend was dan had ik me er iets bij kunnen indenken: je komt aan met een nummertje en je weet niet of het een leverancier, klant of produkt is. Dan moet je een lookuptabel hebben waar alle ID's instaan met een verwijzing naar de tabel waar dat ID instaat. Ietwat bewerkelijk, maar nog altijd sneller dan 'ik weet niet wat het is, ik zoek met de hand'.
Maar dat laatste is op te vangen: definieer voor elke tabel een sequence met een vast laatste stuk. Leveranciers eindigen op 001, klanten op 002, produkten op 003.

Maar dat ID is niet extern bekend. Je kent het alleen in het programma. En daar weet je ook altijd in welke tabel dat ID gebruikt wordt. Dus zie ik de toegevoegde waarde niet. Als je uit de leverancierstabel een ID 1 krijgt weet je dat het een leverancier is.
Het vergroot juist de onduidelijkheid voor de programmeur: die heeft nu een variabele 'ID' en weet niet wa het is. Als hij de variabelen levID, klaID en ProdID heeft ziet hij in het programma al waar het om gaat.

Dus nee: ik zie ook geen voordelen. Eerder nadelen.

[Boss]

Nog een poging:

Zoals ik eerder aangaf is in het grootste deel van de gevallen bekend met wat voor tabel de relatie gelegd moet worden. Zoals bij de contactpersonen tabel, met daarin een kolom BedrijfID. Dan is het duidelijk dat het daar om een FK naar de tabel met bedrijven gaat. Voor die relatie maakt het dan ook niets uit wat voor generator je gebruikt om de PK's te genereren voor bedrijven en contactpersonen.

Zo hebben we het altijd allemaal netjes gedaan, dat kan iedereen nog begrijpen.

Nu komt er een tabel, die FK's kan hebben naar veel andere tabellen, laten we het op 5 houden. Maar, per record in die tabel wordt er exact 1 FX gebruikt. Nu heb je twee opties:
1. In die tabel maak je voor iedere mogelijke FK een kolom aan (5 kolommen). Als er een query wordt gedaan waarbij je alle FK waardes nodig hebt, leg je dus netjes van iedere kolom een relatie naar de bijbehorende FK tabel.

2. We maken maar 1 kolom voor de FK. Vanuit die kolom leg je relaties naar alle andere tabellen. Omdat de PK in die tabellen uniek is over alle tabellen heen, zal er voor ieder ID maar 1 FK gevonden worden bij het koppelen.

Op manier 1 heb je per record een heleboel lege kolommen, omdat je telkens maar met 1 tabel een link legt. Bij 5 FK's is dat nog prima, maar wat bij 10 of 20?

[djluc]

Voor externe communicatie kan je gewoon afspreken dat deze ID's altijd geschreven worden als:
USR83 (user)
ORD89 (order)
USR89
enz.

Dan is het altijd duidelijk wat voor data het is. Niet je database op een vage manier op gaan zetten om zoiets te realiseren!

[Creepy]

Boss:

of optie 3 die al een paar keer is geprobeerd aan je uit te leggen:

Twee velden gebruiken voor de relatie: 1FK en een type veld die aangeeft vanuit welke tabel dit komt. Dit voorkomt zoeken in andere tabellen of je per ongeluk de key tegenkomt.

Een betekenis aan het ID zelf hangen is echt verkeerd. Gebruik dan minstens 1 extra veld die het type relatie aangeeft.

Of optie 4 waarvan je in elk geval mij nog niet overtuigd hebt dat je deze niet kan gebruiken: een koppel tabel voor elke losse n:m relatie die je wilt leggen. Al je koppeltabellen kun je left joinen met je hoofd tabel en met 1 query heb je al je relaties in 1 keer te pakken. Met 1 tabel waar alle relaties in staan waar het ID de relatie bepaalt zul je per relatie al je overige tabellen moeten controleren of toevallig daar het ID in voorkomt. Als je optie drie gebruikt met een type kun je in je queries waarschijnlijk wel wat trucken met een IF om maar 1 query te hoeven stellen maar je laat je database dan wel enorm veel werk meer doen voor wat in principde een standaard n:m relatie is die je met wat simpele JOIN simpel en snel kunt selecteren.

Het enige excuus (wat mij betreft) om dit niet optie 1 (een ster achtige relatievorm) of optie 4 te gebruiken is dat de gebruiker van je software zelf onbeperkt kenmerken kan aanmaken en zelf onbeperkt relaties tussen deze kenmerken moet kunnen leggen. Wat mij betreft zou optie 3 dan een keuze kunnen zijn. Optie twee zou ik nog steeds niet gebruiken omdat het id niks zegt over in welke tabel de rest van de bijbehorende gegevens nu staan.

djluc: Waarom zou je je ID gaan prefixen met een loze waarde als je hier een extra veld voor kan gebruiken dat het type aangeeft? Dan kan je nog op een redelijke manier de boel joinen.

[ Voor 51% gewijzigd door Creepy op 29-03-2008 11:52 ]

[Jan_V]

Dit idee wordt bij ons al enkele jaren toegepast en is goed te doen.
Je maakt 1 tabel met daarin de auto-id's, een identifier met wat het object is (klant, order, bedrijf, etc...), dan de velden die alle objecten hebben (zoals archief, verwijderd, creatiedd, mutatiedd, aanmaker, etc.).
Door de object identifier weet je wat voor object het is en kun je meer informatie ophalen, mocht dat nodig zijn.
Je kunt ook gewoon inner joins gebruiken met tabellen waar je een
SELECT * FROM [MainTabel] INNER JOIN [SubTabel1] ON [MainTabel].ID = [SubTabel1].ID WHERE bladiebla
Zo heb je gelijk alle informatie over de objecten die je wilt hebben. Dit is trouwens gewoon een voorbeeld query hoor. Ik zou het niet zo gebruiken in je daadwerkelijke applicatie.

Na de voordelen, welke je zelf al hebt bedacht, is er 1 enorm groot nadeel, als je met een auto-increment veld werkt.
Vaak is het zo dat klanten waar je je pakket aan verkoopt niets van computers (af willen) weten. Je sluit een SLA met ze af.
Tijdens het onderhoud ontkom je er niet aan dat jij ook content moet toevoegen. Dit is niet goed te doen naar mijn mening. Je doet je onderhoud in de ontwikkel omgeving namelijk op maandag ochtend en je wilt je update op dinsdag middernacht doen bijvoorbeeld. In de tijd van maandag ochtend t/m dinsdag middernacht zijn er records toegevoegd aan je [MainTabel]. Je kunt dus niet meer een data-compare doen van de productie- en ontwikkel omgeving, omdat de ID's niet meer kloppen.
Tot nu toe kan ik hier nog redelijk omheen werken en in goed overleg met de klanten komen we altijd tot een oplossing, maar eigenlijk zadel je dan je klant op met een design-flaw die je zelf hebt gecreeerd. Ok, ons pakket stamt nog uit de tijd dat je geen GUID's had (of in ieder geval bijna nooit werden gebruikt), dus dat is ons (enigszins slechte) excuus.

Als je echt met dit idee wilt doorgaan, zorg dan dat je als uniek veld een GUID gebruikt. Je kunt dan gewoon je data-compares doen en gewoon de ontwikkel omgeving vergelijken met productie (danwel acceptatie) en de inserts of updates doen.
Wel kan ik je aanraden om per subtabel nog wel een ander 'uniek' veld te maken, welke wordt gebruikt door de klanten, zodat je die kunt gebruiken voor navigatie in je product. GUID's voorlezen is namelijk niet echt een leuke bezigheid wanneer je die moet invoeren.

[Orphix]

Ik heb hier een systeem dat iets soortgelijks doet. Het wordt toegepast om access control te beheren. Het idee is dat je enerzijds een organisatie structuur hebt en anderzijds al je resources. Een resource is gekoppeld aan bepalde personen, bedrijven, etc. En als user heb je dus toegang tot die personen en bedrijven. Dit lijkt zeer veel op een traditioneel file system, alleen heb je dus ipv directories je organisatie structuur.

Het is dan handig om de context waarbinnen je identifier uniek is uit te breiden van een enkel type resource (meestal enkele tabel) naar alle resources (over meerdere tabellen). In OO-termen is dit gelijk aan het toevoegen van een baseclass aan alle resource classes. Het is op die manier eenvoudiger, en vaak ook eleganter, om cross-cutting aspecten als security en logging te implementeren.

In ons geval gebruiken we een O/R mapper die deze inheritance verzorgt. Oftewel er is een tabel 'Resource' met een oplopende primary key (integer), en in de 'sub' tabellen wordt het id overgenomen die in de resource tabel is gegenereerd.

Dat zeggende hebben moet je ervoor oppassen dat je niet te 'flexibel' wilt zijn door alles in die ene hoofdtabel te gooien waardoor je rare kunstjes moet uithalen om gegevens op te halen waarvoor een database juist is opgezet. Dan verval je snel in het database-in-database verhaal wat hierboven al is genoemd.

[dusty]

Boss schreef op zaterdag 29 maart 2008 @ 10:52:
[..]
Nu komt er een tabel, die FK's kan hebben naar veel andere tabellen, laten we het op 5 houden. Maar, per record in die tabel wordt er exact 1 FX gebruikt. Nu heb je twee opties:
1. In die tabel maak je voor iedere mogelijke FK een kolom aan (5 kolommen). Als er een query wordt gedaan waarbij je alle FK waardes nodig hebt, leg je dus netjes van iedere kolom een relatie naar de bijbehorende FK tabel.

2. We maken maar 1 kolom voor de FK. Vanuit die kolom leg je relaties naar alle andere tabellen. Omdat de PK in die tabellen uniek is over alle tabellen heen, zal er voor ieder ID maar 1 FK gevonden worden bij het koppelen.
[..]

Je hebt een tabel met de ID's, en jij wilt die ID's de FK laten zijn naar andere tabellen? Draai het eens om, maak dan de tabel juist de leidinggevende met de ID als PK, dan kan je in de andere tabellen de ID's FK naar deze tabel maken. En dan kan je met een TYPE zoals hierboven al meerdere malen gezegd is bijhouden wat voor type de record is.

Maar aangezien de ID afhangt van de database en een gebruiker de ID nooit zal zien, is het hele idee op zich een halfgebakken oplossing.

[MSalters]

Orphix schreef op zaterdag 29 maart 2008 @ 13:47:
Ik heb hier een systeem dat iets soortgelijks doet. Het wordt toegepast om access control te beheren. Het idee is dat je enerzijds een organisatie structuur hebt en anderzijds al je resources. Een resource is gekoppeld aan bepalde personen, bedrijven, etc. En als user heb je dus toegang tot die personen en bedrijven. Dit lijkt zeer veel op een traditioneel file system, alleen heb je dus ipv directories je organisatie structuur.

Het is dan handig om de context waarbinnen je identifier uniek is uit te breiden van een enkel type resource (meestal enkele tabel) naar alle resources (over meerdere tabellen). In OO-termen is dit gelijk aan het toevoegen van een baseclass aan alle resource classes. Het is op die manier eenvoudiger, en vaak ook eleganter, om cross-cutting aspecten als security en logging te implementeren.

Dat is nou juist niet wat de TS wil. De TS wil objecten uit verschillende logische domeinen niet-overlappende IDs geven. In jouw voorbeeld wil hij maar 1 ID-range definieren voor personen en resources. Dat is in "handig" omdat je dan resources toegang kunt geven tot personen.

In jouw voorbeeld is het dus wel verstandig om alle resources in 1 ID-range op te nemen, omdat je maar 1 koppeltabel persoon-resource wil hebben, etcetera. Ik zou zelf wel overwegen om de ID-range van personen te delen met groepen, zodat je ook een groep access kunt geven tot een resource.

[Hydra]

Creepy schreef op vrijdag 28 maart 2008 @ 17:04:
"Eehh.. was ID 2334 nu een bedrijf, contactpersoon of een contract? Controleer dat ff in de verschillende tabellen om te kijken waar dat ID in bestaat"

Met dit argument komen wel meer mensen, en ik vind dit nogal onzinnig. Je 'weet' in geen enkele applicatie aan de hand van alleen de ID wat dat ID precies bevat. Een dergelijk getalletje op het forum hier kan ook een user-, thread- of postid zijn.

De applicatie weet aan de hand van de context wel waarvan dat nummertje nu precies het ID is, en als je echt een 'generiek' systeem wilt maken, maak je een tabel met alle IDs en daaraan gekoppeld het objecttype.

Dat je nu toevallig 1 sequence gebruikt voor meerdere ID's, ok. Het enige nadeel hieraan is dat je sneller aan je maximum waarde van je sequence zit.

Je kiest sowieso je datatype op het aantal IDs dat je verwacht. Als je een 64-bits uint gebruikt ga je niet uit je addressspace lopen.

djluc schreef op zaterdag 29 maart 2008 @ 10:56:
Voor externe communicatie kan je gewoon afspreken dat deze ID's altijd geschreven worden als:
USR83 (user)
ORD89 (order)
USR89
enz.

Dan is het altijd duidelijk wat voor data het is. Niet je database op een vage manier op gaan zetten om zoiets te realiseren!

Vind het enorm ranzig dergelijke logica in je IDs op te nemen.

Ik snap nog steeds niet wat mensen zo 'vaag' vinden aan de voorgestelde structuur. Het is gewoon een soort OO-model. Je hebt als basis een tabel met 'objecten' met een ID en een type.

[curry684]

Hydra schreef op maandag 31 maart 2008 @ 12:07:
[...]

Met dit argument komen wel meer mensen, en ik vind dit nogal onzinnig. Je 'weet' in geen enkele applicatie aan de hand van alleen de ID wat dat ID precies bevat. Een dergelijk getalletje op het forum hier kan ook een user-, thread- of postid zijn.

En dat is ook exact het punt. Vrijwel iedere databaseprofessional zal je vertellen dat natural keys in de praktijk een slecht idee zijn, omdat je altijd uiteindelijk situaties gaat tegenkomen waarbij de candidate natural toch niet zo uniek is als werd gedacht. Daarom worden in de meeste situaties, met name met veel arbitrary data zoals posts en threads, surrogate keys gebruikt, oftewel primary keys per definitie zonder enige inhoudelijke betekenis. Wat TS nu wil doen is aan surrogates alsnog een semantische betekenis hangen, en ja dat is imho A Bad Idea^tm.

[Creepy]

Hydra schreef op maandag 31 maart 2008 @ 12:07:
[...]

De applicatie weet aan de hand van de context wel waarvan dat nummertje nu precies het ID is, en als je echt een 'generiek' systeem wilt maken, maak je een tabel met alle IDs en daaraan gekoppeld het objecttype.


Ik snap nog steeds niet wat mensen zo 'vaag' vinden aan de voorgestelde structuur. Het is gewoon een soort OO-model. Je hebt als basis een tabel met 'objecten' met een ID en een type.

Het voorstel hier is om geen gebruik te maken van een kolom die het type aangeeft of van een kolom per "relatie type". Naar mijn idee niet zo heel gek dat veel mensen dit wel gek vinden. Dus ook de applicatie weet niks over dat ene ID en kan dat niet zomaar achterhalen behalve door in verschillende tabellen het betreffende ID op te gaan zoeken.....

Daarnaast gaat het hier om een stuk meta data, iets wat een DB zelf ook al opslaat. Dus om dat nu zelf in een DB te gaan moddelen is 99 van de 100 keer een fout idee. Ja, je kan prima met een tabel of 5 in totaal alle soorten objecten opslaan wat je ooit in een DB zou willen opslaan, dat je de het gros van de voordelen van een RDMBS op dat moment overboord gooit vergeet men vaak gemakshalve..... tuurlijk moet je rekeninghouden met uitbreidbaarheid waar ik snap echt niet waar het idee vandaan komt dat dat betekent dat er nooit extra tabellen of kolommen in een DB aangemaakt mogen worden hiervoor.

[ Voor 35% gewijzigd door Creepy op 31-03-2008 12:55 ]

[MicroWhale]

Boss schreef op vrijdag 28 maart 2008 @ 16:52:
Het programma gaat uiteindelijk gebruikt worden om communicatiegegevens bij te houden. Hier zijn nogal wat mogelijkheden in: een medewerker (persoon id) praat met een contactpersoon (persoon id) over een bedrijf (bedrijf id). Dit gesprek gaat inhoudelijk over een contract (contract ID) of over een xxx (xxx ID) en zo is er nog een aantal entiteiten.

Klinkt als requirement management voor agreements. Voor "requirements management" zijn standaard pakketten voor. Hierin kun je bijhouden welke afspraken/uitspraken, wanneer door wie gedaan zijn. Kijk eens of één van deze pakketten voldoet aan de reqs. voor de te bouwen software.

[Hydra]

Creepy schreef op maandag 31 maart 2008 @ 12:52:
Het voorstel hier is om geen gebruik te maken van een kolom die het type aangeeft of van een kolom per "relatie type".

Ah, nevermind, dat is wel vreemd. Ik ging er vanuit dat er sowieso een kolom voor het 'type' was, net zoals je in OO omgevingen van elk object op kan vragen van welke class hij is.

MrWilliams schreef op maandag 31 maart 2008 @ 13:05:
Klinkt als requirement management voor agreements. Voor "requirements management" zijn standaard pakketten voor. Hierin kun je bijhouden welke afspraken/uitspraken, wanneer door wie gedaan zijn. Kijk eens of één van deze pakketten voldoet aan de reqs. voor de te bouwen software.

Als de TS voor een door een klant ingehuurde softwareontikkelaar werkt is het helemaal niet interessant voor hun of er bestaande software is die dat ook kan. Het wiel opnieuw uitvinden levert meer geld op

[ Voor 42% gewijzigd door Hydra op 31-03-2008 13:31 ]

[MicroWhale]

Hydra schreef op maandag 31 maart 2008 @ 13:29:
[...]
Als de TS voor een door een klant ingehuurde softwareontikkelaar werkt is het helemaal niet interessant voor hun of er bestaande software is die dat ook kan. Het wiel opnieuw uitvinden levert meer geld op

Wat een belabberde en kortzichtige instelling!

Het kan ook zo zijn dat de softwareontwikkelaar door dit "meedenken" meer opdrachten bij deze klant krijgt. Misschien hebben ze wel duurbetaalde experts op het gebied van requirements engineering.

[Boss]

Het gaat om een heel andere toepassing, ik heb hier voornamelijk voorbeelden aangehaald die niet op het echte probleem lijken om te voorkomen dat ik eerst een hele datastructuur moet uitleggen.

[Hydra]

MrWilliams schreef op maandag 31 maart 2008 @ 15:30:
Wat een belabberde en kortzichtige instelling!

Wat cynisch misschien, maar niet onrealistisch.

[Verwijderd]

curry684 schreef op maandag 31 maart 2008 @ 12:45:
Vrijwel iedere databaseprofessional zal je vertellen dat natural keys in de praktijk een slecht idee zijn, omdat je altijd uiteindelijk situaties gaat tegenkomen waarbij de candidate natural toch niet zo uniek is als werd gedacht.

Als je natural key niet uniek is, is je data model niet goed ontworpen. Een synthetische PK is voor de database misschien wel zo prettig, maar als je daarnaast nog een unique constraint nodig hebt op de velden die je anders in je PK had opgenomen, schiet je er niks mee op.

Er zijn wel practische redenen om synthetische keys te gebruiken, bv. bij MSSQL: die heeft 't liefst dat de PK index clustered is (records in de tabel staan fysiek in dezelfde volgorde als in de index), en omdat een natural PK niet per definitie oplopend is kan dat voor reshuffles van de tabel zorgen. Ook een reden overigens om geen GUIDs als PK te gebruiken, maar dat was al gemeld.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 97% gewijzigd door Ruudjah op 01-12-2009 22:48 ]

[curry684]

Verwijderd schreef op maandag 31 maart 2008 @ 22:41:
[...]
Als je natural key niet uniek is, is je data model niet goed ontworpen. Een synthetische PK is voor de database misschien wel zo prettig, maar als je daarnaast nog een unique constraint nodig hebt op de velden die je anders in je PK had opgenomen, schiet je er niks mee op.

Je hebt het al over velden. Wel eens multicolumn foreign keys toegepast? Enne, de gemiddelde varchar(255) haalt het qua performance in joins echt niet tegen identities of GUIDs.

Er zijn wel practische redenen om synthetische keys te gebruiken, bv. bij MSSQL: die heeft 't liefst dat de PK index clustered is (records in de tabel staan fysiek in dezelfde volgorde als in de index)

Hoezo heeft ie dat het liefst? Dat het een imho extreem stupide default is betekent nog niet dat het per definitie een goed idee is of dat ie ervoor geoptimaliseerd is of zo. In veel gevallen zet ik 'm oftewel bij ontwerp oftewel bij optimalisatie terug op non-clustered.

[Verwijderd]

curry684 schreef op maandag 31 maart 2008 @ 23:13:
Je hebt het al over velden. Wel eens multicolumn foreign keys toegepast? Enne, de gemiddelde varchar(255) haalt het qua performance in joins echt niet tegen identities of GUIDs.

Jep, velden. En dependencies op die columns is vaak prima met triggers op te lossen.
En dat een varchar 't beroerd doet als index is logisch, maar bv. een char(8) + int + datetime kan prima performen...

Hoezo heeft ie dat het liefst? Dat het een imho extreem stupide default is betekent nog niet dat het per definitie een goed idee is of dat ie ervoor geoptimaliseerd is of zo. In veel gevallen zet ik 'm oftewel bij ontwerp oftewel bij optimalisatie terug op non-clustered.

Idem hierzo, maar 't op non-clustered zetten heeft vooral voordelen bij natural keys...

[curry684]

Verwijderd schreef op dinsdag 01 april 2008 @ 00:13:
[...]
Jep, velden. En dependencies op die columns is vaak prima met triggers op te lossen.

Triggers Sorry, ik heb een hekel aan alles wat niet declarative is, van SP's tot triggers

En dat een varchar 't beroerd doet als index is logisch, maar bv. een char(8) + int + datetime kan prima performen...

Waarbij ik me meteen afvraag waarom je dan niet die 4 bytes per row extra in een identity steekt die nog beter performt en minder gezeik met foreign keys oplevert. Bovendien zijn in de praktijk natural keys vaak namen die anders toch een unique constraint zouden krijgen in mijn ervaring, en dus toch snel varchars. En dan moet je weer aan de performancewise prijzige cascading updates zodra je een rename ergens op uitvoert, waarbij je er weer specifiek aan moet denken dat je die cascading updates wel zet omdat je anders ernstige bugs krijgt.

[...]
Idem hierzo, maar 't op non-clustered zetten heeft vooral voordelen bij natural keys...

Waarom? Iedere tabel die op regelmatige basis deletes (of PK-updates) te verwerken krijgt is gevoelig voor dure page splits en merges indien er een clustered index in staat. Vaak moet je op dat soort tabellen stomweg geen clustered index zetten voor de beste performance (zeg maar "MySQL mode" ).

[akakiwi]

Oplossing op de volgende manier werkt al 4 jaar in de praktijk bij een klant van me:
1 tabel waarin je bijhoud welke sleutel vandaag als laatste is uitgegeven. Deze tabel bevat:
Date (datetime)
LastKey (int)

Alle ID's in de andere tabellen zijn van het type BIGINT.
Er is 1 stored procedure (Common.GenerateNewKey) die de datum van vandaag pakt yyyymmddxxxxxxxxx, waarbij de 9 x-en een nieuw getal zijn, welke uit de eerstgenoemde tabel komen (LastKey) het getal 1 wordt gestuffed met 8 0-en aan de voorkant. Piece of cake.
Echter, de enige reden waarom we dit gebruiken is omdat er 1 vertaaltabel is waar elke ID uniek in voorkomt. We hadden ook kunnen kiezen voor ID + tabelnaam, maar dat vonden we toendertijd een stukje omslachtiger.
Deze oplossing werkt nog steeds prima en snel.

Succes ermee.

[Grijze Vos]

akakiwi schreef op donderdag 03 april 2008 @ 06:27:
Oplossing op de volgende manier werkt al 4 jaar in de praktijk bij een klant van me:
1 tabel waarin je bijhoud welke sleutel vandaag als laatste is uitgegeven. Deze tabel bevat:
Date (datetime)
LastKey (int)

Alle ID's in de andere tabellen zijn van het type BIGINT.
Er is 1 stored procedure (Common.GenerateNewKey) die de datum van vandaag pakt yyyymmddxxxxxxxxx, waarbij de 9 x-en een nieuw getal zijn, welke uit de eerstgenoemde tabel komen (LastKey) het getal 1 wordt gestuffed met 8 0-en aan de voorkant. Piece of cake.
Echter, de enige reden waarom we dit gebruiken is omdat er 1 vertaaltabel is waar elke ID uniek in voorkomt. We hadden ook kunnen kiezen voor ID + tabelnaam, maar dat vonden we toendertijd een stukje omslachtiger.
Deze oplossing werkt nog steeds prima en snel.

Succes ermee.

Tijd om TDWTF te mailen... Serieus, wat bezielt jullie om het zo aan te pakken.

[EfBe]

Boss schreef op zaterdag 29 maart 2008 @ 10:52:
Nog een poging:

Zoals ik eerder aangaf is in het grootste deel van de gevallen bekend met wat voor tabel de relatie gelegd moet worden. Zoals bij de contactpersonen tabel, met daarin een kolom BedrijfID. Dan is het duidelijk dat het daar om een FK naar de tabel met bedrijven gaat. Voor die relatie maakt het dan ook niets uit wat voor generator je gebruikt om de PK's te genereren voor bedrijven en contactpersonen.

Zo hebben we het altijd allemaal netjes gedaan, dat kan iedereen nog begrijpen.

Nu komt er een tabel, die FK's kan hebben naar veel andere tabellen, laten we het op 5 houden. Maar, per record in die tabel wordt er exact 1 FX gebruikt. Nu heb je twee opties:
1. In die tabel maak je voor iedere mogelijke FK een kolom aan (5 kolommen). Als er een query wordt gedaan waarbij je alle FK waardes nodig hebt, leg je dus netjes van iedere kolom een relatie naar de bijbehorende FK tabel.

2. We maken maar 1 kolom voor de FK. Vanuit die kolom leg je relaties naar alle andere tabellen. Omdat de PK in die tabellen uniek is over alle tabellen heen, zal er voor ieder ID maar 1 FK gevonden worden bij het koppelen.

Op manier 1 heb je per record een heleboel lege kolommen, omdat je telkens maar met 1 tabel een link legt. Bij 5 FK's is dat nog prima, maar wat bij 10 of 20?

Je moet niet in tabellen denken, maar in abstract entity definitions. Wanneer je je entities gaat definieren in een modellingstechniek als NIAM/ORM kom je er achter dat je model niet matcht.

Het punt is dat wat jij wilt maken inhoudt dat ieder van die 5 entities eigenlijk een relatie heeft met al die andere 4 entities en combinaties, en omdat jij in tabellen denkt wil je maar 1 plek maken waar al die mogelijkheden worden opgeslagen.

Het is een veel voorkomend probleem. Stel je maakt fietsen. Fietsen hebben onderdelen. Jij wilt nu een fiets opslaan met al zn onderdelen in 1 tabel. Ieder onderdeel heeft een ID. Die onderdelen zijn dan weer onderverdeeld in allerlei typen onderdelen: banden, zadels, sturen, frames etc.

Stel je hebt:
Fiets 1:n orderdeel.
Die relatie heeft een attribute: aantal. Onderdeel is het supertype van alle andere onderdelen. In NIAM/ORM kun je dit prima definieren: onderdeel neemt de gedeelde attributes voor zn rekening, dus leverancier, naam, prijs etc. En per onderdeel type, dus frames, banden, zadels etc., maak je een nieuw entity aan: Band, Zadel, Frame, Wiel etc. met de specifieke attributes van dat entity en die erven van Onderdeel (zijn dus subtypes van Onderdeel).

Nadat je dat gedaan hebt, sta je voor de keuze: OF je slaat de onderdeel hierarchie plat in 1 tabel met een discriminator attribute OF je maakt per entity type in de hierarchie een tabel aan met een 1:1 PK -PK relatie van subtype naar supertype. (Nijssen-Halpin: Conceptual Schema and Relational Database Design, chapter 10 e.v.)

Wanneer je dan een Fiets met zn onderdelen uit de database wilt halen, merk je dus dat je werkt met meerdere tabellen dan 2: je werkt met net zoveel tabellen als er onderdeel types zijn, + 1 voor onderdeel als supertype + 1 voor fiets-onderdeel + 1 voor fiets.

Je ziet dat je met het prutsen op tabelniveau hier niet toe komt: je gaat dan mieren met 1 tabel, global keys terwijl je geen theoretische basis hebt waarom je dat doet. Ook bij deze thread gaat het weer op: wanneer men op tabel niveau zn relationele database gaat zitten ontwerpen, dan komt men onherroepelijk in de problemen, want: _waarom_ is die tabel zo en niet anders? Is het niet zo dat een tabel definitie niets anders is dan de projectie van een entity definitie op een relationeel model ?

Met een o/r mapper die inheritance ondersteunt haal je dan die fiets met zn onderdelen in de juiste entity types zo uit je database en zet je die er ook weer zo in terug: de "Fiets.Orderdelen" collection zal bv Band, Frame etc. instances hebben, met de data uit 'Onderdeel', maar ook de data uit de entity specifieke tabel.

Je ziet NADAT je zo'n model hebt gemaakt meteen WAAROM je een global key nodig hebt, maar niet voor ALLE tabels. Alleen voor de tabellen in de Onderdeel hierarchie: Onderdeel heeft een PK, bv sequenced, en alle subtypes erven die PK, je hebt als het ware de entity 'Band' of 'Wiel' gedefinieerd over 2 tabellen: 'Onderdeel' en 'Band'. De subtype tables hebben NIET een eigen PK die sequenced is maar een PK die ook een FK is, naar de PK van Onderdeel.

Daarom is prutsen op tabelniveau ook niet echt handig, en toont het, sorry, aan dat je niet snapt waarom je op entity niveau dingen moet definieren en niet op tabelniveau: wat stelt een tabel definitie voor? Hint: het heeft niets te maken met kolommen en rijen.

(Het fietsvoorbeeld is niet verzonnen overigens: http://www.wrenchscience.com/ werkt hiermee. )

Overigens voor de goede orde: wanneer je denkt: "oei, dat zijn veel tabellen, dat wil ik niet, want dat is vast traag", even deze wijze raad: EERST je model op orde, DAN optimaliseren dmv denormalisatie. Wanneer je denormaliseert TIJDENS het modelleren van je model is het project ten dode opgeschreven.

MSalters schreef op zondag 30 maart 2008 @ 00:39:
[...]
Dat is nou juist niet wat de TS wil. De TS wil objecten uit verschillende logische domeinen niet-overlappende IDs geven. In jouw voorbeeld wil hij maar 1 ID-range definieren voor personen en resources. Dat is in "handig" omdat je dan resources toegang kunt geven tot personen.

Als DAT is wat TS wil dan heeft hij vage posts getikt. Waarom zou je in vredesnaam 1 ID range willen voor niet-gerelateerde entities (i.e. entities die niet in dezelfde inheritance hierarchie zitten?). Ik maak echt niet op uit TS's posts dat hij wilt wat jij beschrijft.

In jouw voorbeeld is het dus wel verstandig om alle resources in 1 ID-range op te nemen, omdat je maar 1 koppeltabel persoon-resource wil hebben, etcetera. Ik zou zelf wel overwegen om de ID-range van personen te delen met groepen, zodat je ook een groep access kunt geven tot een resource.

je hebt geen koppeltabel nodig. Resource's PK is een FK naar Person.ID, resource heeft zelf geen sequenced PK, dat komt omdat Resource zn attributes in een subtype entity zitten.

Niet op tabelniveau dit soort dingen willen oplossen, dan kom je op kromme zaken als 'koppeltabellen', en dat wil je echt niet.

Boss schreef op maandag 31 maart 2008 @ 16:19:
Het gaat om een heel andere toepassing, ik heb hier voornamelijk voorbeelden aangehaald die niet op het echte probleem lijken om te voorkomen dat ik eerst een hele datastructuur moet uitleggen.

Wat is het nou: voorbeelden die lijken op het feitelijke probleem, of voorbeelden die leuk zijn voor de discussie maar geen reet te maken hebben met het feitelijke probleem?

[ Voor 18% gewijzigd door EfBe op 03-04-2008 11:32 ]

[Boss]

EfBe, bedankt voor de inhoudelijke reactie. Als ik je website zou lees zie ik waar je inspiratie vandaan komt Ziet er interessant uit, die tool. De methodes die je beschrijft zijn dan ook heel erg van toepassing als je je database gebruikt om een OO model te voeden, en specifiek als je met objecten werkt die van dezelfde klasse zijn afgeleid.

Als DAT is wat TS wil dan heeft hij vage posts getikt. Waarom zou je in vredesnaam 1 ID range willen voor niet-gerelateerde entities (i.e. entities die niet in dezelfde inheritance hierarchie zitten?). Ik maak echt niet op uit TS's posts dat hij wilt wat jij beschrijft.

Dat is het nu juist. Bij het fietsvoorbeeld hebben alle onderdelen inderdaad een leverancier, productnummer, etc. etc. Wij willen dus een koppeltabel gebruiken om entities te linken die niet van dezelfde klasse zijn afgeleid. Volgens mij waren mijn posts wat dat betreft niet heel vaag, het is toch wel duidelijk dat in mijn voorbeeld een kleur en een dier niet uit dezelfde inheritance hierarchie komen?

[curry684]

Maar hoeveel situaties heb je in godesnaam dat je vanuit 1 <whatever> naar een kleur of een dier wil linken? Vul eens in wat ik me voor wil stellen bij die <whatever> want ik mis gewoon de real-world case, ik kan me daar weinig bij voorstellen behalve heel specifieke gevallen of logtabellen, en die zijn allebei geen excuus om heel je DB zo te verneubouwen.

[Boss]

In dit geval hebben wij een situatie, en dat is dus inderdaad een logtabel.

Op wat voor manier denk je een DB ermee te verneuken? Of het nu wel of geen goed idee is, wij denken er een voordeel in te zien. Ik heb nog geen concrete nadelen gelezen in dit topic, oftewel: onafhankelijk van wat wij ermee willen doen: is het een probleem om een globale generator te gebruiken?

[EfBe]

Als dat je plan is dan ben je niet goed bezig, want die entities hebben geen relatie. Probeer het eens op een hoger niveau te modelleren dan op tabel niveau.

[Creepy]

Het voordeel dat je hebt genoemd wordt door meerdere mensen afgedaan als zijnde geen voordeel en in een aantal gevallen zelfs als een nadeel. Er zijn ook al meerdere keren zaken geopperd om zo niet een globaal ID te hebben. Leg je dit nu volledig naast je neer, heb je hier compleet overheen gekeken of heb je iets bedacht dat bijna niemand hier lijkt te begrijpen?

Even voor mezelf: kan je je voorbeeld nu eens concreet uitleggen ("een logtabel" is echt veel te vaag, kom eens met een use case, opzet van je DB, etc.) en het daadwerkelijke voordeel benoemen van het hebben van 1 globale ID over je DB heen?

[ Voor 5% gewijzigd door Creepy op 04-04-2008 13:18 ]

[curry684]

Boss schreef op vrijdag 04 april 2008 @ 12:50:
In dit geval hebben wij een situatie, en dat is dus inderdaad een logtabel.

Waarom zou een logtabel of all things in godesnaam realtime moeten kunnen joinen naar 300 dingen? Waarom zet je je logtabel niet als volgt op:

LogEntryId	Message	Source	SourceType	SourceId
1	New entry 'Pizza' added	Products	tblProduct	1
2	User 'curry' modified with new email	Users	tblUser	1

Dan ben je er ook, je hebt zowel toonbare data voor je logtabel, als de mogelijkheid om 'dieper te tunnelen' als een gebruiker details opvraagt doordat je de sourcetabel en z'n ID opslaat.

Op wat voor manier denk je een DB ermee te verneuken? Of het nu wel of geen goed idee is, wij denken er een voordeel in te zien. Ik heb nog geen concrete nadelen gelezen in dit topic, oftewel: onafhankelijk van wat wij ermee willen doen: is het een probleem om een globale generator te gebruiken?

Performance, manageability en integrity zijn toch al heel vaak genoemd als zeer zwaarwegende concrete nadelen.

[Gomez12]

Boss schreef op vrijdag 04 april 2008 @ 12:50:
In dit geval hebben wij een situatie, en dat is dus inderdaad een logtabel.

Op wat voor manier denk je een DB ermee te verneuken? Of het nu wel of geen goed idee is, wij denken er een voordeel in te zien. Ik heb nog geen concrete nadelen gelezen in dit topic, oftewel: onafhankelijk van wat wij ermee willen doen: is het een probleem om een globale generator te gebruiken?

Simpel gezegd, het is geen probleem om een globale generator te hebben, alleen als je hem wilt gebruiken om iets op te zoeken/joinen dan krijg je een rampscenario, en heb je opeens toch meer info nodig dan alleen je globale id.
En als je hem niet gebruikt om te zoeken / joinen is hij nutteloos en dus overbodig.

Vergelijk het eens dat je alles wat je in je huis hebt liggen een id geeft.
Is het dan makkelijker als ik een lijst raadpleeg, dan zeg dat ik id 975 wil lenen is dat dan makkelijker dan wanneer ik zeg dat ik cd 10 wil lenen? met een globaal id heb je geen idee of ik nou een postzegel bedoel of je auto.