[SQL] Constraints PK - FK verwijzing

[Anoniem: 94519]

Nu lukt het normaliseren, en ben ik ook in staat om een ERD te maken. Ook het maken van een SQL script lukt, maar heb ik nog een twijfel bij een iets, namelijk:

Wanneer je bijvoorbeeld de volgende tabellen hebt:

Reservering, met daarin de attributen:

-lezernr
-isbn
-datum

Waarbij deze 3 items een gecombineerde sleutel vormen.

Lezer, met daarin de attributen:

lezernr
naam
adres
postcode
woonplaats
filnr

En hier alleen lezernr de pk vormt.

Dan maak ik de SQL code als volgt:

create table lezer(
lezernr int4,
naam varchar(20),
adres varchar(25),
postcode varchar(6),
woonplaats varchar(25),
filnr int4,
constraint lezer_pk primary key (lezernr));

create table reservering (
lezernr int4,
ISBN number(10),
datum varchar(,
constraint reservering_pk primary key (lezernr, ISBN, datum),
constraint lezer_fk foreign key (lezernr) references lezer(lezernr));

Maar wat ik me dus afvraag of dit bovenstaande mag? Mag ik in de tabel een gecombineerde sleutel zo weergeven. En delen van die gecombineerde sleutel (zoals lezernr aan tabel lezer: lezernr) ook gelijk als foreign key zoals hierboven zo verwijzen?

Dit is het enigste waar ik nog mee zit, voor de rest lukt het wel, als iemand me misschien ff wat duidelijkheid kan geven, graag.

[whoami]

Ik zou nooit een primaire sleutel maken , door een combinatie te maken van velden. OK, die combinatie van velden zorgt wel voor een unieke identificatie van dat record, en zou dus in principe geschikt zijn voor een PK, maar dan heb je een probleem met je foreign keys.

Een primaire sleutel mag van mij nooit veranderen, en daarom maak ik altijd een extra column die de primaire sleutel is (een autonumber of een guid, 't is te zien wat de noden zijn).
Dit lost heel wat hoofdbrekens op.

Wat je dan natuurlijk wel kunt doen, is een unique constraint leggen op die 3 velden.

[NMe]

Om het verhaal van whoami maar even samen te vatten: het kan wel, maar wordt in de praktijk liever niet toegepast.

Dit probleem ziet er trouwens uit als een van de meest standaard schoolopdrachtjes (databasestructuur maken voor een bibliotheek), en ik weet uit ervaring dat ze je dit op school wel willen zien doen. Als het dus echt voor school is, dan kun je dus beter even je leraar vragen of hij liever een gecombineerde sleutel ziet, of een apart ID/autonummer-veld.

[Anoniem: 94519]

Hm ok dus in feite kan dit ook:

create table reservering (
lezernr int4,
ISBN number(10),
datum varchar(,
constraint reservering_unique unique (lezernr, isbn, datum),
constraint lezer_fk foreign key (lezernr) references lezer(lezernr));

Is idd voor school, en die leraar ziet het liefst een gecombineerde sleutel. Maar het is wel makkelijk als ik 2 methodes kan hanteren, kan ik altijd nog een andere optie voorstellen. Maar als íe dus het liefst een gecombineerde methode ziet, kan dat wat ik in m'n eerste post neergezet had wel?

[Anoniem: 94519]

Maar kan/mag hetgeen, wat ik in mijn eerste post gedaan heb? Dus wanneer je uitgaat van het feit dat de leraar een gecombineerde sleutel wilt in zo'n situatie, dat je dat in je sql code zo verwoord?

[whoami]

Als je dat in je schema zo verwoord (niet in je databank zelf dus); en je vermeld dat duidelijk in je schema, dan kan het.
Schema's zijn een manier om iets weer te geven, het is niet iets dat perfect aan alle richtlijnen moet voldoen imo. Een schema is iets waarmee je iemand anders iets kunt duidelijk maken.

[Anoniem: 94519]

Hm ok maar het moet zeg maar niet in een schema. We moeten zeg maar normaliseren, een erd maken en daarvan weer sql code. Met databank bedoel je de sql code toch? Want wil het dan als sql code opschrijven, maar is dus niet aan te raden?

[TheekAzzaBreek]

Het kan en mag zo (beetje afhankelijk van de syntax van je DB, natuurlijk). Whoami heeft een goed punt met PK's die niet mogen wijzigen. Als die datum b.v. bijgewerkt wordt bij verlenging, kan (wil) je hem niet in de PK gebruiken. Dat je foreign keys wat ingewikkelder en groter worden hoeft niet zo'n punt te zijn als je het over bescheiden aantallen hebt, tot enkele tienduizende records.

[RobIII]

offtopic:
Waarom gebruik je een varchar voor datum
Er zijn "soms" wel redenen voor, daar niet van. Maar waarom niet gewoon een DateTime ofzo?

[whoami]

RobIII schreef op vrijdag 10 juni 2005 @ 14:52:

offtopic:
Waarom gebruik je een varchar voor datum
Er zijn "soms" wel redenen voor, daar niet van. Maar waarom niet gewoon een DateTime ofzo?

Dat had ik nog niet gezien.

Een VARCHAR gebruiken voor een datum-veld is idd een grove fout imo. Als je dat doet, zal het je zeker nog hoofdbrekens bezorgen.
Met een datetime veld, kan je bv 'rekenen', en die functionaliteit verlies je als je 'm in een varchar stopt.
Daarbij kan je in een varchar dus alles stoppen:

code:

14/12/1978
12/14/1978

[Anoniem: 94519]

Dat van die datum was wel een grote fout idd. Maar goed ben blij dat ik nu weet hoe het zit, dan moet het wel goedkomen. Had ook nog ff een vraag over het type datatype dat je voor prijzen kunt gebruiken? Ik gebruik op dit moment decimal, bijvoorbeeld:

- Prijs decimal (7,2)

Is dit handig, of is er nog een beter methode? En weet iemand misschien hoe je cascade on update/delete e.d in een tabel toepast? Wanneer ik zeg maar een aantal FK constraints gedefineerd heb en op de volgende regel cascade on delete zet krijg ik een foutmelding. Wanneer ik een FK constraint definieer en ik zet op de volgende regel cascade on delete, wordt deze wel opgepakt.

[Jaspertje]

volgens mij is de Cascade delete "on Cascade Delete"

Check het ff

Zorg er voor dat je database dan wel al "op orde is"

SQL:

ALTER TABLE [dbo].[PouleUitslagVoorspellingen] ADD 
    CONSTRAINT [FK_PouleUitslagVoorspellingen_Landen] FOREIGN KEY 
    (
        [LandID]
    ) REFERENCES [dbo].[Landen] (
        [LandID]
    ) ON DELETE CASCADE

[ Voor 91% gewijzigd door Jaspertje op 13-06-2005 19:45 ]

[Anoniem: 94519]

create table uitlening(
lezernr int(4) NOT NULL,
exemplaarnr int(255) NOT NULL,
huurdatum date NOT NULL,
filnr int(4),
isbn int(10),
retourdatum date,
constraint uitlening_pk primary key (lezernr, exemplaarnr, huurdatum),
constraint uitlening_fk foreign key (lezernr) references
lezer (lezernr),
constraint uitlening_fk foreign key (exemplaarnr) references
exemplaar (exemplaarnr),
constraint uitlening_fk foreign key (filnr) references
filiaal (filnr),
constraint uitlening_fk foreign key (isbn) references
uitgave (isbn)
on Cascade Delete);

On cascade delete werkt niet, maar on delete cascade werkt wel.

[Anoniem: 94519]

Om nog even met het bibliotheek verhaal verder te gaan, had ik nog een vraag over het uitlezen van bepaalde dingen. Ben al een tijdje met de select statement aan het worstelen. Zo moet ik een overzicht krijgen van de namen van alle lezers die een boek geleend hebben. Daarnaast ook de titel, uitleendatum en het filiaaladres, in volgorde van filiaal. Ik kom vervolgens tot het volgende resultaat, maar heb het idee dat íe niet helemaal goed is:

Select lezer.naam, count(*), uitgave.titel, uitlening.huurdatum, filiaal.filadres
From lezers l, uitlening u, uitgave ui, filiaal f, exemplaar e
where l.filnr = f.filnr
And l.lezernr = u.lezernr
And ui.isbn = e.isbn
ORDER BY filiaal;

Iemand misschien een aanvulling, of een id?

[curry684]

Anoniem: 94519 schreef op woensdag 08 juni 2005 @ 15:47:
Is idd voor school, en die leraar ziet het liefst een gecombineerde sleutel. Maar het is wel makkelijk als ik 2 methodes kan hanteren, kan ik altijd nog een andere optie voorstellen. Maar als íe dus het liefst een gecombineerde methode ziet, kan dat wat ik in m'n eerste post neergezet had wel?

Die leraar moet z'n mond houden en advies aannemen van de mensen die de praktijk wel kennen Een zogenaamde 'surrogate key', oftewel een losse column die geen enkel ander doel dient dan het uniek identificeren van de row (autonumber of GUID zoals whoami al zegt) is vrijwel altijd het beste idee vanuit performance, manageability en maintenance perspectieven. Het feit dat data nu uniek is maakt het nog niet tot een goede key: deze 'natural keys' die feitelijke data representeren hebben een neiging dat niet te zijn. Een goed voorbeeld is de Amerikaanse variant op onze SOFI-nummers, dit lijkt een volstrekt uniek nummer dat daardoor kwalificeert als primary key om een persoon te identifieren, maar in de praktijk blijkt het nummer niet uniek te zijn.

Voorkom gezeik, pak een surrogate key. Je database wordt er vrijwel altijd performanter van en je ondervangt er iedere situatie mee. Stel dat de bibliotheek hetzelfde boek meerdere keren heeft (komt vaak voor), dan mag in jouw tabel dezelfde abonnee dat boek dus niet 2 keer op 1 dag reserveren. Waarom zou je in godesnaam die restrictie opleggen op databaseniveau?

Interessant voer on the subject trouwens: klik

[ Voor 6% gewijzigd door curry684 op 19-06-2005 03:27 ]

[NMe]

curry684 schreef op zondag 19 juni 2005 @ 02:51:
Voorkom gezeik, pak een surrogate key. Je database wordt er vrijwel altijd performanter van en je ondervangt er iedere situatie mee. Stel dat de bibliotheek hetzelfde boek meerdere keren heeft (komt vaak voor), dan mag in jouw tabel dezelfde abonnee dat boek dus niet 2 keer op 1 dag reserveren. Waarom zou je in godesnaam die restrictie opleggen op databaseniveau?

offtopic:
Daarom is het meestal voor dit soort opdrachten te bedoeling dat je met een "abstracte" tabel komt om boeken in op te slaan, en een andere tabel voor de fysieke exemplaren.

Zo veel verschillende scholen, zo weinig verschillende opdrachten.

[Anoniem: 94519]

Ja zit ook wel wat in, maar dat hanteer ik dan wel wanneer ik voor mezelf normaliseer. Toch een hele mooie link, thnx. Alleen weet iemand of hetgeen wat ik hierboven probeer (select statement)goed is?

Zo moet ik een overzicht krijgen van de namen van alle lezers die een boek geleend hebben. Daarnaast ook de titel, uitleendatum en het filiaaladres, in volgorde van filiaal. Ik kom vervolgens tot het volgende resultaat, maar heb het idee dat íe niet helemaal goed is:

Select lezer.naam, count(*), uitgave.titel, uitlening.huurdatum, filiaal.filadres
From lezers l, uitlening u, uitgave ui, filiaal f, exemplaar e
where l.filnr = f.filnr
And l.lezernr = u.lezernr
And ui.isbn = e.isbn
ORDER BY filiaal;

[ Voor 75% gewijzigd door Anoniem: 94519 op 19-06-2005 22:31 ]

[hemaworst]

curry684 schreef op zondag 19 juni 2005 @ 02:51:
[...]

Die leraar moet z'n mond houden en advies aannemen van de mensen die de praktijk wel kennen Een zogenaamde 'surrogate key', oftewel een losse column die geen enkel ander doel dient dan het uniek identificeren van de row (autonumber of GUID zoals whoami al zegt) is vrijwel altijd het beste idee vanuit performance, manageability en maintenance perspectieven.

Stel dat de bibliotheek hetzelfde boek meerdere keren heeft (komt vaak voor), dan mag in jouw tabel dezelfde abonnee dat boek dus niet 2 keer op 1 dag reserveren. Waarom zou je in godesnaam die restrictie opleggen op databaseniveau?

Aangezien TS moet leren wat normaliseren is, ERD kunnen tekenen etc, lijkt het me nogal kort door de bocht om surrogaat keys te gaan introduceren. Wanneer je dit doet zal je later als de db groter wordt voor veel problemen komen te staan. Vooral op het gebied van juistheid van gegevens lijkt het me nogal gevaarlijk om alleen surrogaat sleutels te gebruiken! Data zal binnen now time vervuilen.

Dat bibliotheek probleem lijkt me nogal raar. Het klopt dat een bibliotheek meerdere exemplaren heeft van een boek. Die zullen echter nooit geindentificeerd worden door alleen een ISBN nummer. Eerder door iets van ISBN+exemplaarnummer.

Daarnaast zou ik voorzichtig zijn met het geven van tips zoals: een primaire sleutel mag nooit veranderen. Dat is niet waar, maar wordt soms aangehouden omdat het makkelijker programmeren is/onderhouden is(ook niet altijd waar).

Dus voorkom gezeik, krijg een mooi cijfer door samengestelde PK's te gebruiken(zoals het hoort volgens de databaseontwerp technieken) en gebruik geen surrogaat keys!!

[Anoniem: 94519]

Ja idd hemaworst, daar zit ook wat in. Ga gewoon gebruik maken van samengestelde sleutels, want dat is toch hetgeen wat ze van je vragen. Zie dat niet zo zitten om een surog. key te gaan gebruiken. Verder klopt het idd, zo'n exemplaar is uniek door een gecombineerde sleutel: exemplaarnr, filiaalnr en isbn.

[hemaworst]

whoami schreef op woensdag 08 juni 2005 @ 15:23:
Ik zou nooit een primaire sleutel maken , door een combinatie te maken van velden. OK, die combinatie van velden zorgt wel voor een unieke identificatie van dat record, en zou dus in principe geschikt zijn voor een PK, maar dan heb je een probleem met je foreign keys.

Ik denk dat heel veel database architecten zich een aap schrikken als bovenstaand lezen:
Mijn gedachte:
ik zou een primaire sleutel maken , door een combinatie te maken van velden die samen het record kunnen identificeren. Ga na met een domeindeskundige of de gekozen velden daadwerkelijk een object uit zijn domein kunnen identificeren . die combinatie van velden zorgt wel voor een unieke identificatie van dat record, en zijn uitermate geschikt zijn voor een PK, en leid niet tot problemen met je foreign keys.

Waarom whoami zegt dat het problemen geeft snap ik niet. inderdaad zijn de join conditities wat lastiger, maar niet veel moeilijker.
Qua performance zijn niet-surrogaat-keys bij inserten trager. Surrogaat keys zijn dan sneller, maar leggen geen enkele restrictie op de gegevens, dit moet je dan weer uitprogrammeren.

Business keys kunnen ook een goed effect hebben op performance! Bij surrogaat keys moet je altijd joinen om foreign keys informatie op te halen. Bij business keys is die informatie al te vinden in het foreign key veld.

Ik heb het gevoel dat de anderen correct geimplementeerde sleutels moeilijk vinden en business rules liever uitprogrammeren. Als je een correct database maakt(dus met natuurlijke sleutels) dan voorkom je dat je later heel veel in code moet bijsturen.
Zoals je ziet kan er hevig over gediscusseerd worden, maar ik raad je aan om eerst bij je leraar te gaan vragen voordat je database modelling concessies gaat doen

[ Voor 8% gewijzigd door hemaworst op 19-06-2005 23:56 ]

[GambitRS]

Ik ken het probleem.... zelf gebruik ik zo vaak mogelijk toch samengestelde sleutels tenzij die tabel toevallig een koppeling heeft met een andere tabel, zodat alle sleutelvelden plots moeten worden overgenomen.

dus dat niet iets als dit voorkomt:

Tabel 1:
PK A
PK B
PK C

Tabel 2:
PK ID
FK A
FK B
FK C

In zo'n geval maak ik er van:

Tabel 1:
PK ID2
A
B
C

Tabel 2:
PK ID
FK ID2

Snap je?

[curry684]

hemaworst schreef op zondag 19 juni 2005 @ 23:36:
[...]

Aangezien TS moet leren wat normaliseren is, ERD kunnen tekenen etc, lijkt het me nogal kort door de bocht om surrogaat keys te gaan introduceren.

En waarom? Zijn je ERD's of normalisaties van lagere kwaliteit met surrogate keys? Zoals gezegd: leuk wat die docent wil, maar als je bij mij in het team werkt en het lef hebt om met een clustered primary key van 3 fields aan te komen heb je wat uit te leggen

Wanneer je dit doet zal je later als de db groter wordt voor veel problemen komen te staan. Vooral op het gebied van juistheid van gegevens lijkt het me nogal gevaarlijk om alleen surrogaat sleutels te gebruiken! Data zal binnen now time vervuilen.

Uh nee, surrogate keys zijn juist het belangrijkste wapen tegen datavervuiling, omdat je relationships altijd correct blijven ongeacht wat je ook veranderd. In het voorbeeld van de reservering heb je al cascading updates nodig als je de datum van de reservering moet wijzigen, iets wat in real world niet geheel onwaarschijnlijk is, en wat een probleem is dat het merendeel van de natural keys heeft.

Dat bibliotheek probleem lijkt me nogal raar. Het klopt dat een bibliotheek meerdere exemplaren heeft van een boek. Die zullen echter nooit geindentificeerd worden door alleen een ISBN nummer. Eerder door iets van ISBN+exemplaarnummer.

In de TS staat het als (ISBN, datum, lezernr), daar ageerde ik tegen

Zoals in het voorbeeld met de Amerikaanse SOFI-nummers al gegeven overigens heb je ook geen garantie dat een ISBN uniek blijft. In dat geval gaat jouw key dus ook al de mist in. Bovendien heb je dubbele informatie in je key, omdat exemplaarnummer als het goed is al een unieke surrogate primary key is in de exemplaartabel, en bij correcte normalisatie naar een boek zal refereren al dan niet via ISBN. Het ISBN in deze key gebruiken voegt dus niets toe.

Daarnaast zou ik voorzichtig zijn met het geven van tips zoals: een primaire sleutel mag nooit veranderen. Dat is niet waar, maar wordt soms aangehouden omdat het makkelijker programmeren is/onderhouden is(ook niet altijd waar).

Dus voorkom gezeik, krijg een mooi cijfer door samengestelde PK's te gebruiken(zoals het hoort volgens de databaseontwerp technieken) en gebruik geen surrogaat keys!!

Alsof het cijfer altijd heilig is. Iemand die zweert bij natural keys heeft nul komma nul kans op een baan bij mij of een goeie plek binnen m'n ontwikkelteam waar ie feitelijk schade kan doen. Krijg een leuke baan door goede databaseontwerpen te maken waarbij je natural keys vermijd

GambitRS schreef op zondag 19 juni 2005 @ 23:57:
Ik ken het probleem.... zelf gebruik ik zo vaak mogelijk toch samengestelde sleutels tenzij die tabel toevallig een koppeling heeft met een andere tabel, zodat alle sleutelvelden plots moeten worden overgenomen.
[...]
Snap je?

Uh nee ik snap je niet. Je gebruikt dus alleen clustered primary keys indien deze niet als foreign key gebruikt worden, anders pak je wel een foreign key. Mag ik vragen wat dan in godesnaam het nut is van de clustered primary key behalve dat je de DAL complexer maakt en je DB-model door inconsistentie moeilijker leesbaar en uitbreidbaar?

[ Voor 12% gewijzigd door curry684 op 20-06-2005 00:16 ]

[hemaworst]

GambitRS schreef op zondag 19 juni 2005 @ 23:57:

In zo'n geval maak ik er van:

Tabel 1:
PK ID2
A
B
C

Tabel 2:
PK ID
FK ID2

Snap je?

dat kan ja, maar dan moet je wel een alternative key toevoegen op tabel1.a+tabel1.b+tabel1.c
Nog steeds voor de school opdracht niet echt de bedoeling

curry684 schreef op maandag 20 juni 2005 @ 00:15:
[...]

En waarom? Zijn je ERD's of normalisaties van lagere kwaliteit met surrogate keys? Zoals gezegd: leuk wat die docent wil, maar als je bij mij in het team werkt en het lef hebt om met een clustered primary key van 3 fields aan te komen heb je wat uit te leggen
Alsof het cijfer altijd heilig is. Iemand die zweert bij natural keys heeft nul komma nul kans op een baan bij mij of een goeie plek binnen m'n ontwikkelteam waar ie feitelijk schade kan doen. Krijg een leuke baan door goede databaseontwerpen te maken waarbij je natural keys vermijd

Natuurlijk moet een database ontwerper kunnen afwijken van "de boekjes", maar eerst moet hij volledig begrijpen hoe het "hoort".
Ik hang altijd de gedachte aan: Modeleer zoals het geleerd word. Wijk af zodra dat nodig is(voor jouw wisselende keys)
Wat ik bedoel is dat iemand moet eerst weten hoe het modeleren hoort voordat hij/zij uberhaupt concessies kan doen. Ik neem aan dat iedereen in jouw team weet hoe het moet volgens de boeken en dan "concessies" doet. Dat is iets heel anders dan luk raak overal surogaat keys te gebruiken.

[ Voor 72% gewijzigd door hemaworst op 20-06-2005 00:38 ]

[Anoniem: 94519]

. Bovendien heb je dubbele informatie in je key, omdat exemplaarnummer als het goed is al een unieke surrogate primary key is in de exemplaartabel, en bij correcte normalisatie naar een boek zal refereren al dan niet via ISBN. Het ISBN in deze key gebruiken voegt dus niets toe.

Zal dat ff uitleggen, ik heb zeg maar een tabel uitgave waar dingen als titel, schrijver en ISBN in zijn opgenomen, en daarnaast een tabel voor het uitlenen van boeken, waar ook weer een isbn is opgenomen. Tevens zit er in die tabel uitlening een 3 tal FK's die verwijzen naar 3 PK's in de tabel exemplaar, namelijk exemplaarnr, filnr en isbn.

[whoami]

hemaworst schreef op zondag 19 juni 2005 @ 23:51:
[...]

Ik denk dat heel veel database architecten zich een aap schrikken als bovenstaand lezen.
Waarom whoami zegt dat het problemen geeft snap ik niet.

Ik denk dat ik wel een beetje kan zeggen dat ik uit ervaring spreek.

Qua performance zijn niet-surrogaat-keys bij inserten trager.

Die performance - hit is miniem.

Surrogaat keys zijn dan sneller, maar leggen geen enkele restrictie op de gegevens, dit moet je dan weer uitprogrammeren.

Dat hoeft niet, je kan evengoed een unique constraint op die velden leggen.

curry684 schreef op maandag 20 juni 2005 @ 00:15:
[...]

Volledig eens met jouw verhaal, maar, waar jij 'clustered key' zegt, bedoel je waarschijnlijk 'composite key' denk ik.
Een composite key is voor mij een samengestelde sleutel, terwijl een clustered key (in SQL Server) weer heel wat anders betekent. (maar dat weet jij ook wel).

[ Voor 24% gewijzigd door whoami op 20-06-2005 09:38 ]

[curry684]

whoami schreef op maandag 20 juni 2005 @ 09:36:
[...]

Volledig eens met jouw verhaal, maar, waar jij 'clustered key' zegt, bedoel je waarschijnlijk 'composite key' denk ik.
Een composite key is voor mij een samengestelde sleutel, terwijl een clustered key (in SQL Server) weer heel wat anders betekent. (maar dat weet jij ook wel).

Twas laat

Tis ook geen handige spraakverwarring, clustered en composite betekenen in principe woordtechnisch zowat hetzelfde maar bij clustered gaan de meeste mensen idd direct aan het achterliggende index-type denken

[hobbit_be]

een primary key waardat de velden eigenlijk gewoon pure data is toch de waanzin???

dan kun je net zo goed ALLE velden tot 1 massive PK doen want dan ben je pas echt zeker...
een autoinc, unique PK is gewoon lekker een nummer dat op niets slaagt maar het is wel 100% uniek (zoals voorbeeld er kunnen best toch dezelfde overeenkomsten komen als je echt data gaat gebruiken om maar te zwijgen van foute user input). Die primary Key (eerste keer dat ik surrogate key tegenkom, maar tja heb dan ook alleen maar pratische ervaring op vercshillde DB's) is ALTIJD unique. als je wil ga zoeken kun je nog wel indexeren op een paar velden... Ik heb nog nooit een tabel gezien ZONDER een 'surrogate PK' ZELFS al wordt er NIETS mee gedaan.

Soms vraag je je toch af waarom een mens zoiets aangeleerd krijgt... Beetje teveel in boekjes gelezen en nooit iets gedaan je tutor. Ze zouden eigenlijk een reeks boeken moeten uitgeven: X for beginners by professionals...

En ik neem toch aan dat je je argumenten toch mag onderbouwen ook al doe je dan niet wat hij voorschrijft: het gaat er in education toch om om kritisch te zijn?

Net zoals bijna alles in computer world: keep it abstract... keep it numbers..

[P_de_B]

Hoewel ik het in principe eens ben met het feit dat een surrogate key in veel gevallen de juiste oplossing is, is het niet zo zwart/wit als curry wil laten geloven imho. Er zijn best situaties waarin een niet identity sleutel goed zou kunnen.Ik hanteer het liefst het principe: "Ik gebruik een surrogate key, behalve als er een natural key is die aan alle criteria van een PK voldoet"

[hemaworst]

hobbit_be schreef op maandag 20 juni 2005 @ 14:36:
een primary key waardat de velden eigenlijk gewoon pure data is toch de waanzin???

dan kun je net zo goed ALLE velden tot 1 massive PK doen want dan ben je pas echt zeker...
een autoinc, unique PK is gewoon lekker een nummer dat op niets slaagt maar het is wel 100% uniek (zoals voorbeeld er kunnen best toch dezelfde overeenkomsten komen als je echt data gaat gebruiken om maar te zwijgen van foute user input). Die primary Key (eerste keer dat ik surrogate key tegenkom, maar tja heb dan ook alleen maar pratische ervaring op vercshillde DB's) is ALTIJD unique. als je wil ga zoeken kun je nog wel indexeren op een paar velden... Ik heb nog nooit een tabel gezien ZONDER een 'surrogate PK' ZELFS al wordt er NIETS mee gedaan.

Soms vraag je je toch af waarom een mens zoiets aangeleerd krijgt... Beetje teveel in boekjes gelezen en nooit iets gedaan je tutor. Ze zouden eigenlijk een reeks boeken moeten uitgeven: X for beginners by professionals...

En ik neem toch aan dat je je argumenten toch mag onderbouwen ook al doe je dan niet wat hij voorschrijft: het gaat er in education toch om om kritisch te zijn?

Net zoals bijna alles in computer world: keep it abstract... keep it numbers..

Lekker vaag, wat jij zegt is dat je foute user input toe laat in de database??!?!?
Dat kan je juist uitstekend ondervangen met een juist gemodeleerde database.
Gegevens die overeenkomen? Ja dat kan, maar wanneer je 2 of meerdere records in de database kan opslaan met alleen de surrogaat key die verschilt dan ben je toch echt super fout bezig. Je slaat dan namelijk meerdere malen hetzelfde feit op???

Alle velden onder 1 pk omdat je dan echt zeker bent? Sorry hoor, maar als jij van te voren niet weet welke waarden samen uniek moeten zijn dan durf ik echt jou database niet te gebruiken.

Waarom mensen dit aangeleerd krijgen? Zodat gebruikers NOOIT dubbele gegevens kunnen invullen, Geen foute user input kunnen invullen.

Ik kan me wel voorstellen dat je surrogaat keys in combinatie met AK's gebruikt (voor performance ofzo), maar jij stelt voor om AK's alleen bij uitzondering toe te voegen?

[ Voor 5% gewijzigd door hemaworst op 21-06-2005 11:58 ]

[curry684]

hemaworst schreef op dinsdag 21 juni 2005 @ 11:54:
[...]

Alle velden onder 1 pk omdat je dan echt zeker bent? Sorry hoor, maar als jij van te voren niet weet welke waarden samen uniek moeten zijn dan durf ik echt jou database niet te gebruiken.

Nou, jij hebt volgens mij weinig praktijkervaring

Zie wederom de voorbeelden over SOFI-nummers en ISBN-nummers. Ze lijken uniek en de ideale primary key, maar vallen buiten jouw verantwoordelijkheid en dus kun je niets garanderen.

Waarom mensen dit aangeleerd krijgen? Zodat gebruikers NOOIT dubbele gegevens kunnen invullen, Geen foute user input kunnen invullen.

Daar heb je check constraints, unique constraints en declarative referential integrity voor. De primary key zelf is nooit of te nimmer een validatiemethode, en het is enkel om technische redenen dat het impliciet en per definitie een unique constraint omvat.

[wzard]

Ik heb toch sterk het idee dat we hier met een ietwat gestresste databaseontwikkelaar te maken hebben...

hobbit_be schreef op maandag 20 juni 2005 @ 14:36:
een primary key waardat de velden eigenlijk gewoon pure data is toch de waanzin???
dan kun je net zo goed ALLE velden tot 1 massive PK doen want dan ben je pas echt zeker...
een autoinc, unique PK is gewoon lekker een nummer dat op niets slaagt maar het is wel 100% uniek (zoals voorbeeld er kunnen best toch dezelfde overeenkomsten komen als je echt data gaat gebruiken om maar te zwijgen van foute user input).

Alle velden onder de PK is normaal gesproken natuurlijk klink-klare onzin (sommige gevallen uitgezonderd natuurlijk). Een auto-incremental number is echt geen garantie voor foute user input.
Juist het tegenovergestelde! Gebruik je PK's van niet surrogate keys, dan wordt je data meteen gevalideerd (voor zover het al user input moet zijn hier, omdat het binnen FK's 9 van de 10 keer door parent-child vensters binnen de userinterface wordt afgehandeld) Is de UI toch niet zo super, dan worden de FK's tenminste meteen gechecked door het RDBMS, wat niet zo is (of via code moet gebeuren) bij surrogate keys. Ik ben het daarom zeker met Hemaworst eens dat ook niet-surrogate PK's goed werken.

Ik heb nog nooit een tabel gezien ZONDER een 'surrogate PK' ZELFS al wordt er NIETS mee gedaan.

Raar, ik kom bijna dagelijks voorbeelden tegen!

Soms vraag je je toch af waarom een mens zoiets aangeleerd krijgt... Beetje teveel in boekjes gelezen en nooit iets gedaan je tutor.
[...]
Net zoals bijna alles in computer world: keep it abstract... keep it numbers..

Bij het ontwikkelen van systemen moet in eerste instantie gedacht worden aan de gebruiker achter het systeem, iets dat door vele informatici vaak voor het gemak maar even wordt vergeten.

Als een gebruiker zegt:
"Klant Janssen bestelt 100 dozen van product 12345"
dan bedoelt hij dat hij de klant identificeert met Janssen en niet met nummer 1!!!
Het product wordt in dit geval wel geidentificeerd met een nummer

Nummers maken de boel ongelofelijk onoverzichtelijk, en geven binnen zeer grote systemen ook nog eens de nodige performance-problemen doordat alles gejoined dient te worden. Ookal is het performanceverlies per query te verwaarlozen, kijk eens naar een multiuser-systeem met een paar honderd gebruikers of meer, dan wordt die verwaarloosbaarheid ineens toch iets anders...

[hemaworst]

curry684 schreef op dinsdag 21 juni 2005 @ 11:58:
[...]

Nou, jij hebt volgens mij weinig praktijkervaring

Zie wederom de voorbeelden over SOFI-nummers en ISBN-nummers. Ze lijken uniek en de ideale primary key, maar vallen buiten jouw verantwoordelijkheid en dus kun je niets garanderen.

[...]

Daar heb je check constraints, unique constraints en declarative referential integrity voor. De primary key zelf is nooit of te nimmer een validatiemethode, en het is enkel om technische redenen dat het impliciet en per definitie een unique constraint omvat.

Zoals ik al eerder zei kan ik me wel voorstellen dat voor implementatie technische zaken(performance) of uitzonderingen(wisselende keys) je kies voor surrogaat keys in combinatie met AK's(checks oid). MAAR een modeleerder dient altijd te modeleren zoals het volgens "de boekjes" moet(dus PK's over meerder kolommenetc). Als het ontwikkelteam wil afwijken daarvan dan is dan hun zaak(en verantwoordelijkheid) niet die van de modeleerder.(Natuurlijk kan de modeleerder helpen daarbij, maar de basis moet goed zijn)

[ Voor 9% gewijzigd door hemaworst op 21-06-2005 12:16 ]

[curry684]

wzard schreef op dinsdag 21 juni 2005 @ 12:06:
Als een gebruiker zegt:
"Klant Janssen bestelt 100 dozen van product 12345"
dan bedoelt hij dat hij de klant identificeert met Janssen en niet met nummer 1!!!
Het product wordt in dit geval wel geidentificeerd met een nummer

Dan moet de gebruiker optiefen en met een nummertje terugkomen, we kunnen wel 300 meneren Janssen hebben in de database

Nummers maken de boel ongelofelijk onoverzichtelijk, en geven binnen zeer grote systemen ook nog eens de nodige performance-problemen doordat alles gejoined dient te worden.

Bliep Een join op integers gaat wel een stukje sneller dan een join op varchars (understatement), dus dit is quatsch tenzij je alle benodigde velden in de PK hebt staan, waardoor je enorm lange datavelden in iedere tabel repliceert onder het excuus van een foreign key. Was basisprincipe 1 van normalisatie niet juist het elimineren van redundante data in plaats van ze onder het mom van DRI overal herhalen?

Ookal is het performanceverlies per query te verwaarlozen, kijk eens naar een multiuser-systeem met een paar honderd gebruikers of meer, dan wordt die verwaarloosbaarheid ineens toch iets anders...

Uhuh, en wat ben je dan blij als je op integers joint ipv 5 varchar(255) velden

[D4Skunk]

Hmmz, er zijn hier al zoveel replies dat ik het ook niet kan laten

Persoonlijk gebruik ik altijd een surrogate key, en gebruik ik constraints om de 'uniqueness' aan te duiden. Enkele voorbeelden :

Een applicatie wordt ontworpen, en men identificeert een uniek contact alszijnde iemand die een bepaalde naam op een welbepaald adres heeft. We gaan hier ook uit van extreme normalisatie, waarbij een aparte tabel bestaat voor de Namen, en een aparte tabel voor Adressen ( wordt soms toegepast bij crm-systemen, waar men dubbele input probeert te vermijden ).

Wanneer ik dan bijvoorbeeld een tabel ContactActies heb, dan zou die er als volgt uitzien zonder surrogate key :

code:

Tabel ContactActies :
  DomeinActieOmschrijvingId
  NaamId
  AdresId
  [meta-velden]
  [...]

edit:


hmmz eigenlijk verwijzen de id's ook terug naar een surrogate, kijk liever eens naar het voorbeeld dat ik hier enkele posts onder geef

Wat blijkt er na het opzetten in de praktijk ? Men heeft niet altijd het adres ter beschikking, maar wel bv een email-adres of telefoonnummer. Dus het is mogelijk dat een contact uniek geïdentificeerd wordt adhv andere velden. Dit wil dan zeggen dat alle tabellen waarin een verwijzing zit naar de tabel contacten, dus ook ContactActies, moeten worden aangepast. Ik kan je verzekeren dat dit in productieomgevingen soms een kleine ramp is...
Wanneer je dus je unieke velden gaat gebruiken om te linken ipv een surrogate key, ga je dus een constraint van 1 tabel in een andere gaan opnemen. Je neemt als het ware functionaliteit op van de ene tabel in de andere, en iedereen weet dat je de functionaliteit zoveel mogelijk moet scheiden om onderhoudsnachtmerries te vermijden.

Een tweede voordeel : uniformiteit. Wanneer je altijd een surrogate gebruikt, dan weet je dat tabel.id altijd het unieke id bevat. Persoonlijk vind ik dit, tesamen met enkele andere velden (createdby, updatedby, deletedby, createdon, ...) een ware must-have, waardoor je veel uniforme functionaliteit in je app eenvoudig kan implementeren. (logging etc)

Een derde voordeel : wanneer ik een app omvorm naar een offline app, ben ik zeker dat mijn keys nog steeds zullen matchen, en hoef ik geen extra vgl te doen, behalve met de timestamp column.

* D4Skunk gebruikt ALTIJD surrogate keys !!

Leg dit maar eens uit aan je leraar, en laat hem daar eens een deftig antwoord op formuleren

offtopic:
Dat is imho het probleem in het onderwijs : duidelijk gebrek aan praktijkervaring, waardoor zaken op de verkeerde manier aangeleerd worden, en men het later zelf moet leren 'the hard way'

[ Voor 4% gewijzigd door D4Skunk op 21-06-2005 13:57 ]

[P_de_B]

wzard schreef op dinsdag 21 juni 2005 @ 12:06:
Nummers maken de boel ongelofelijk onoverzichtelijk, en geven binnen zeer grote systemen ook nog eens de nodige performance-problemen doordat alles gejoined dient te worden. Ookal is het performanceverlies per query te verwaarlozen, kijk eens naar een multiuser-systeem met een paar honderd gebruikers of meer, dan wordt die verwaarloosbaarheid ineens toch iets anders...

Dat is onzin. Dat de data in de tabellen in eerste instantie niet duidelijk is als je de kale tabel bekijkt (bijvoorbeeld een koppeltabel met alleen id's) is een onzinargument. Dan zou je in elke tabel de alle informatie (dubbel) moeten opslaan. Je zegt dat je tegen JOINs bent in een relationele database? Het spijt me, maar dan heb je het niet begrepen volgens mij. Verschillende tabellen met elkaar koppelen is juist het idee achter, en de kracht van een RDBMS.

[D4Skunk]

Een bijkomende opmerking : cascaded updates; een aanpassing aan 1 van de velden die als key gebruikt wordt, zorgt voor een update in al de tabellen die naar deze tabel verwijzen.
How's that for performance impact ? Denk maar aan een tabel die logging doet, en miljoenen lijnen bevat die verwijzen naar een contact...

Een bijkomend probleem :
Sommige queries zouden wel zeer onoverzichtelijk worden.
Veronderstel dat ik bovenstaand voorbeeld nog wat verder uitwerk, en we bv ook een geboortedatum en -locatie erbij gaan betrekken, alsook de adressen doorgedreven ga normaliseren :

code:

Tabel ContactActies :
  DomeinActieOmschrijvingDomeinNaam
  DomeinActieOmschrijvingNaam
  ContactVoornaam
  ContactAchternaam
  ContactGeboorteDatum
  ContactGeboorteStadPostcode
  ContactGeboorteStadLand
  ContactWoonplaatsStraatNaam
  ContactWoonplaatsStraatNummer
  ContactWoonplaatsStadPostcode
  ContactWoonplaatsStadLand
  [meta-velden]
  [...]

Dat zal imho zorgen voor prachtige joins 9 join clauses voor 1 join.

Veronderstel dat je zo'n 8 a 9 tabellen moet koppelen (neem o.a. usersecurity in rekening) , dan zou ik toch liever hebben dat iemand anders instaat voor het onderhoud van de db. Je neemt als het ware alle nodes mee naar je leaf wanneer je zo'n aanpak gebruikt, en in een serieus datamodel kan ik je garanderen dat je zoiets absoluut wilt vermijden.

Een bijkomen nadeel : in een join kan je velden vergeten, terwijl er moeilijk iets kan misgaan met

code:

xxx_id = xxx.id

imho

Het feit dat je om velden met een surrogaat key te bekijken steeds moet joinen is imho eerder goed dan slecht. Wat doe je bv bij meertaligheid van je app ?


En zo kunnen we blijven doorgaan ...

[ Voor 14% gewijzigd door D4Skunk op 21-06-2005 14:03 ]

[whoami]

Een primary key die kan veranderen, of die een betekenisvolle waarde heeft binnen het 'probleemdomein', is per definitie evil.
Maar dat had ik al eens gezegd geloof ik.

Stel je een foreign key voor die bestaat uit 2 of meer velden. Da's toch gewoon waanzin ? Wat is dat dan van duplicatie ?
Stel dat één van die velden van waarde moet veranderen, etc....

Natural Primary Keys are the root of all evil.

[ Voor 54% gewijzigd door whoami op 21-06-2005 14:45 ]

[D4Skunk]

whoami schreef op dinsdag 21 juni 2005 @ 14:44:
[...]

Natural Primary Keys are the root of all evil.

* D4Skunk couldn't agree more

[P_de_B]

Stel een artikeltabel,

ArtikelNr, omschrijving, prijs

Zouden jullie hier een een autonummer surrogate key aan toevoegen, of gebruik je gewoon artikelnummer?

[curry684]

P_de_B schreef op dinsdag 21 juni 2005 @ 14:52:
Stel een artikeltabel,

ArtikelNr, omschrijving, prijs

Zouden jullie hier een een autonummer surrogate key aan toevoegen, of gebruik je gewoon artikelnummer?

Nu kan het aan mij liggen maar is dat niet gewoon een surrogate identity key? Waar zou je 'm anders vandaan willen halen, door users on the fly laten bedenken als ze een produkt toevoegen?

[ Voor 4% gewijzigd door curry684 op 21-06-2005 15:02 ]

[P_de_B]

Ja, zou kunnen, maar laten we even aannemen dat het artikelnummer niet een dom volgnummer is.

Overigens ben ik voor domme oplopende artikelnummers, degene die het niet doen moeten worden afgeschoten vermanend toe worden gesproken, maar in onze exact administratie is jaren geleden helaas voor een andere oplossing gekozen. De eerste 3 cijfers in ons artikelnummer staan voor het product, de tweede 3 cijfers staan voor de verpakking.

[curry684]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:05:
Ja, zou kunnen, maar laten we even aannemen dat het artikelnummer niet een dom volgnummer is.

Overigens ben ik voor domme oplopende artikelnummers, degene die het niet doen moeten worden afgeschoten vermanend toe worden gesproken, maar in onze exact administratie is jaren geleden helaas voor een andere oplossing gekozen. De eerste 3 cijfers in ons artikelnummer staan voor het product, de tweede 3 cijfers staan voor de verpakking.

Hier bij Philips is het nog erger, een product wordt geidentificeerd door een 12-cijferig nummers, waarvan de laatste 3 verpakking zijn, de 3 ervoor het specifieke produkt, de 2 ervoor de produktgroep en de eerste 4 de fab (uit het blote hoofd ). Binnen de businessapplicaties waar productdata middels DTS gerepliceerd wordt naar lokale databases wordt consequent een surrogate autonumber toegevoegd indien er relationeel met de tabel wordt gewerkt. Binnen de originele datawarehouse wordt er wel op gejoind, maar dat vind ik binnen OLAP-situaties vergeefbaar (komt bovendien direct uit een SAP-feed). Binnen de afgeleide OLTP-applicaties is dat hoogst onpraktisch (past niet in een int tenslotte) en zit je bovendien in de schijt bij de scheduled update-rondes als er produkten afgevoerd zijn en je er nog wel referenties naar hebt in de DB. Dan ben je blij met je surrogates waardoor je outdated produkten gewoon kunt markeren en issues die ernaar verwijzen gewoon in het archief kunnen blijven.

[P_de_B]

Je kunt producten waarvan het artikelnummer de PK is, en niet een identity, natuurlijk wel gewoon inactive markeren. Sowieso ben ik voorstander van soft-deleten. Ik zie niet in wat de keuze van een PK daar mee te maken heeft.

De artikelnummers bij ons passen makkelijk in een int, zijn uniek, identificeren de rij voldoende, wijzigen niet. Kortom een goede kandidaat voor een PK.

[D4Skunk]

Eerlijk gezegd, gebruik altijd een surrogate key
Wat zou je bv doen, mocht je een historiek v/d prijzen willen bijhouden ? (een aparte tabel bijhouden is imho nogal rommelig)

edit:

Een telefoontje ertussen, en voor je het weet is je antwoord al achterhaald

[ Voor 22% gewijzigd door D4Skunk op 21-06-2005 15:25 ]

[P_de_B]

D4Skunk schreef op dinsdag 21 juni 2005 @ 15:24:
Eerlijk gezegd, gebruik altijd een surrogate key
Wat zou je bv doen, mocht je een historiek v/d prijzen willen bijhouden ? (een aparte tabel bijhouden is imho nogal rommelig)

Kun je dit iets duidelijk uitleggen? Ik begrijp niet wat je bedoeld.

[whoami]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:19:
Je kunt producten waarvan het artikelnummer de PK is, en niet een identity, natuurlijk wel gewoon inactive markeren. Sowieso ben ik voorstander van soft-deleten. Ik zie niet in wat de keuze van een PK daar mee te maken heeft.

De artikelnummers bij ons passen makkelijk in een int, zijn uniek, identificeren de rij voldoende, wijzigen niet. Kortom een goede kandidaat voor een PK.

En wat heeft dat artikelnummer verder nog van 'functionele waarde' ?

[P_de_B]

whoami schreef op dinsdag 21 juni 2005 @ 15:29:
[...]


En wat heeft dat artikelnummer verder nog van 'functionele waarde' ?

Het identificeert het artikel. Hoe bedoel je verder?

Denk dat ik je wel snap, of het verder -buiten de database om zo maar te zeggen- nog een 'betekenis' heeft?

Dat is niet echt relevant denk ik, mijn vraag komt neer op het volgende: Een van de business eisen is dat het artikelnummer opgebouwd is zoals ik hierboven heb beschreven. Voeg je dan nog handmatig een identity waarde toe die als PK gaat dienen, of gebruik je het artikelnummer als PK?

[ Voor 47% gewijzigd door P_de_B op 21-06-2005 15:33 ]

[whoami]

Dat artikelnr is dan gewoon je surrogate key, aangezien het binnen jouw domain toch van geen enkel nut is.
Een 'natural key' is voor mij een sleutel die op een veld ligt dat een bepaalde betekenis heeft binnen het probleemdomein.

[Janoz]

curry684 schreef op zondag 19 juni 2005 @ 02:51:
Stel dat de bibliotheek hetzelfde boek meerdere keren heeft (komt vaak voor), dan mag in jouw tabel dezelfde abonnee dat boek dus niet 2 keer op 1 dag reserveren. Waarom zou je in godesnaam die restrictie opleggen op databaseniveau?

Op dit moment heeft de bieb juist van elk boek minimaal evenveel exemplaren als er gebruikers zijn. elke lezer zou in principe op dezelfde dag hetzelfde boek kunnen reserveren.

[P_de_B]

whoami schreef op dinsdag 21 juni 2005 @ 15:38:
Dat artikelnr is dan gewoon je surrogate key, aangezien het binnen jouw domain toch van geen enkel nut is.
Een 'natural key' is voor mij een sleutel die op een veld ligt dat een bepaalde betekenis heeft binnen het probleemdomein.

Hmm, daar heb je wel gelijk in inderdaad. Ik heb een beetje het verhaal tussen een surrogate key en een 'identity' key door elkaar gehaald. In dit geval is artikelnummer inderdaad een surrogate key. Je zou nu dus niet een identity toevoegen?

[whoami]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:43:
[...]


Hmm, daar heb je wel gelijk in inderdaad. Ik heb een beetje het verhaal tussen een surrogate key en een 'identity' key door elkaar gehaald. In dit geval is artikelnummer inderdaad een surrogate key. Je zou nu dus niet een identity toevoegen?

Een surrogate key hoeft geen identity te zijn. Het kan een identity zijn, het kan een GUID zijn, zolang het maar geen betekenis heeft binnen het domein.
En waarom zou die key in jouw voorbeeld geen identity kunnen zijn ?

[ Voor 7% gewijzigd door whoami op 21-06-2005 15:45 ]

[P_de_B]

whoami schreef op dinsdag 21 juni 2005 @ 15:45:
[...]


Een surrogate key hoeft geen identity te zijn. Het kan een identity zijn, het kan een GUID zijn, zolang het maar geen betekenis heeft binnen het domein.

Weet ik ik had dus begrepen dat men ervoor pleitte altijd een identity te gebruiken. Ik denk dat we het in principe wel eens zijn allemaal. ( )

[P_de_B]

whoami schreef op dinsdag 21 juni 2005 @ 15:45:
[...]

En waarom zou die key in jouw voorbeeld geen identity kunnen zijn ?

Omdat de business rules een duidelijk omschrijving van het artikelnummer geven, dat dient op een bepaalde manier opgebouwd te worden, en wordt door een client applicatie gegenereert.

[D4Skunk]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:25:
[...]


Kun je dit iets duidelijk uitleggen? Ik begrijp niet wat je bedoeld.

is misschien beter met een ander voorbeeld ipv prijshistoriek, want prijshistoriek hoort imho sowieso niet thuis in die tabel. Ik kan moeilijk voorbeelden verzinnen met zo'n aanpak

Voor zover ik het begrepen heb, is het artikelnr een interne ref die iedereen gebruikt :
"Hey Peter, is de 750123 nog in voorraad ?"

Instinkertje :

In de online db is artikel "750123" toegevoegd, alszijnde "750123","Airco 3KW","499 €"

Veronderstel dat Peter werkt met een offline db, en dit artikel is niet in de database aanwezig. Peter voegt dit toe : artikel "750123", "Lucht in Pakjes", "20 €"

Wanneer je dan synchroniseert met je online db, en je hebt geen uniek id, wordt die insert als een update waargenomen, en zal die waarschijnlijk voor correct aangenomen worden.

In de situatie van een surrogate zal dit duidelijk worden dat dit een insert is, en zal je een conflict krijgen op Artikels_UC_ArtikelRef.

Ik heb liever de 2de situatie dan de 1ste

[P_de_B]

D4Skunk schreef op dinsdag 21 juni 2005 @ 15:49:
[...]


is misschien beter met een ander voorbeeld ipv prijshistoriek, want prijshistoriek hoort imho sowieso niet thuis in die tabel. Ik kan moeilijk voorbeelden verzinnen met zo'n aanpak

Voor zover ik het begrepen heb, is het artikelnr een interne ref die iedereen gebruikt :
"Hey Peter, is de 750123 nog in voorraad ?"

Instinkertje :

In de online db is artikel "750123" toegevoegd, alszijnde "750123","Airco 3KW","499 €"

Veronderstel dat Peter werkt met een offline db, en dit artikel is niet in de database aanwezig. Peter voegt dit toe : artikel "750123", "Lucht in Pakjes", "20 €"

Wanneer je dan synchroniseert met je online db, en je hebt geen uniek id, wordt die insert als een update waargenomen, en zal die waarschijnlijk voor correct aangenomen worden.

In de situatie van een surrogate zal dit duidelijk worden dat dit een insert is, en zal je een conflict krijgen op Artikels_UC_ArtikelRef.

Ik heb liever de 2de situatie dan de 1ste

Volgens mij beschrijf jij de situatie die zou onstaan zonder een PK. Daar kunnen we het wel over eens zijn, een PK moet natuurlijk. Waar we het over hebben is de keuze voor een PK.

[D4Skunk]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:47:
[...]


Omdat de business rules een duidelijk omschrijving van het artikelnummer geven, dat dient op een bepaalde manier opgebouwd te worden, en wordt door een client applicatie gegenereert.

En wie geeft jou de garantie dat die rules nooit zullen veranderen ? Wat als er bv een leveranciersid bij moet komen ?
Dat is net het voordeel van surrogates, ze zijn totaal niet afhankelijk van je model.

[ Voor 1% gewijzigd door D4Skunk op 21-06-2005 15:56 . Reden: zelfs 2 zinnen kan ik niet zonder fouten typen :p ]

[P_de_B]

D4Skunk schreef op dinsdag 21 juni 2005 @ 15:55:
[...]


En wie geeft jou de garantie dat die rules nooit zullen veranderen ? Wat als er bv een leveranciersid bij moet komen ?
Dat is net het voordeel van surrogates, ze zijn totaal niet afhankeleijk van je model

Dat moet je goed in overweging nemen inderdaad. Ik ben ook in de meeste gevallen een voorstander van een identity column die de PK is.

[ Voor 1% gewijzigd door P_de_B op 21-06-2005 15:58 . Reden: ik ook niet :( ]

[D4Skunk]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:52:
[...]


Volgens mij beschrijf jij de situatie die zou onstaan zonder een PK. Daar kunnen we het wel over eens zijn, een PK moet natuurlijk. Waar we het over hebben is de keuze voor een PK.

Daar gaat het hem net over; als jij je artikelreferentie als pk gebruikt, heb je geen garantie mbt de identity...

omg, het posten gaat hier hard

[P_de_B]

D4Skunk schreef op dinsdag 21 juni 2005 @ 16:00:
[...]


Daar gaat het hem net over; als jij je artikelreferentie als pk gebruikt, heb je geen garantie mbt de identity...

en weer snap ik je niet. (ligt aan mij hoor, zeer slecht geslapen)

[Janoz]

mwah, als je twee databases hebt waarop aan beide kanten aanpassingen en toevoegingen gedaan worden, en je laat het synchroniseren enkel van het ID afhangen dan zijn er wel meer dingen die je niet kunt garanderen .

[whoami]

P_de_B schreef op dinsdag 21 juni 2005 @ 15:47:
[...]


Omdat de business rules een duidelijk omschrijving van het artikelnummer geven, dat dient op een bepaalde manier opgebouwd te worden, en wordt door een client applicatie gegenereert.

Aangezien het door business rules gedefinieerd wordt, heeft het dan stiekem toch geen betekenis ?

Janoz schreef op dinsdag 21 juni 2005 @ 16:04:
mwah, als je twee databases hebt waarop aan beide kanten aanpassingen en toevoegingen gedaan worden, en je laat het synchroniseren enkel van het ID afhangen dan zijn er wel meer dingen die je niet kunt garanderen .

Dan moet je een GUID gebruiken, om op basis daarvan te synchen.

[ Voor 33% gewijzigd door whoami op 21-06-2005 16:07 ]

[P_de_B]

whoami schreef op dinsdag 21 juni 2005 @ 16:07:
[...]


Aangezien het door business rules gedefinieerd wordt, heeft het dan stiekem toch geen betekenis ?


[...]
.

Ja en nee, het nummer an sich heeft een betekenis in de rest van het bedrijf. Mensen weten wat voor artikel het is, slechts op basis van het nummer omdat het op een bepaalde manier is opgebouwd.. Binnen de database is het echter een dom nummer. Met business rules bedoel ik in dit geval niet zozeer de regels waaraan de db/de applicatie moet voldoen, maar meer wat 'men' in het bedrijf ooit besloten heeft.

[Janoz]

In dat geval heb je nog steeds wel 1 of andere communicatie mogenlijkheid (eventueel via een 3e uitgiftepunt) )tussen beide DB's . Daarnaast lost dat het probleem niet op wanneer een veld in beide versies anders aangepast is ... Maar goed.. Dat is een heel ander onderwerp.

[D4Skunk]

Janoz schreef op dinsdag 21 juni 2005 @ 16:04:
mwah, als je twee databases hebt waarop aan beide kanten aanpassingen en toevoegingen gedaan worden, en je laat het synchroniseren enkel van het ID afhangen dan zijn er wel meer dingen die je niet kunt garanderen .

Dit bedoelde ik dus. Een identity zou een record moeten uniek identificeren, zelfs over verschillende instanties van databases.

Wat gebeurt er bv wanneer ik in het bovenstaande voorbeeld van die factuur een synchronisatie doe ?
Na synchronisatie merkt de productverantwoordelijke dat artikel "750123" niet klopt, en corrigeert de gegevens :
"Airco","499€" -> "Lucht in pakjes","20€"
Peter weet niet dat de productverantwoordelijke dit aangepast heeft, en gezien de facturatielijn nog steeds artikel "750123" bevat, zal de facturatiedienst een factuur sturen voor "Gebakken lucht","20 €" ipv "Airco","499€"
Dan zal je imho al een zeer eerlijke klant moeten hebben...

edit:

En terug ingehaald...

[ Voor 16% gewijzigd door D4Skunk op 21-06-2005 16:17 ]

[P_de_B]

D4Skunk schreef op dinsdag 21 juni 2005 @ 16:14:
[...]

Dit bedoelde ik dus. Een identity zou een record moeten uniek identificeren, zelfs over verschillende instanties van databases.

Wat gebeurt er bv wanneer ik in het bovenstaande voorbeeld van die factuur een synchronisatie doe ?
Na synchronisatie markt de productverantwoordelijke dat artikel "750123" niet klopt, en corrigeert de gegevens :
"Airco","499€" -> "Lucht in pakjes","20€"
Peter weet niet dat de productverantwoordelijke dit aangepast heeft, en gezien de facturatielijn nog steeds artikel "750123" bevat, zal de facturatiedienst een factuur sturen voor "Gebakken lucht","20 €" ipv "Airco","499€"
Dan zal je imho al een zeer eerlijke klant moeten hebben...

Ik begrijp nog niet hoe een identity key dit probleem zal ondervangen. Bij synchronisatie zul je sowieso moeten beslissen wat te doen bij 'botsingen' etc.

[whoami]

Synchen moet je doen op basis van global unique id's.
Dat zie je ook bij replication. Dat gebeurt ook op basis van een guid (rowcolguid). (Bij SQL Server althans).

[pjonk]

Interessante discussie. Een paar jaar geleden stelde ik een soortgelijke vraag
[rml][ Algemeen] Database normaliseren vraagje[/rml]

Daar werd mij afgeraden om een surrogate key te gebruiken, maar in dit geval ging het dan ook om een simpele koppel tabel.

[whoami]

Voor een simpele koppeltabel, gebruik ik ook geen surrogate key.
Maar da's dan weer iets anders...

[D4Skunk]

P_de_B schreef op dinsdag 21 juni 2005 @ 16:16:
[...]


Ik begrijp nog niet hoe een identity key dit probleem zal ondervangen. Bij synchronisatie zul je sowieso moeten beslissen wat te doen bij 'botsingen' etc.

Onder identity versta ik idd een guid - of iets gelijkaardigs - zoals whoami hierboven meldt, en je hebt natuurlijk ook je timestamp etc, maar dat is misschien inderdaad iets te veel offtopic, zoals janoz al vermeld heeft.

Los van het probleem van de meerdere databases & synchronisatie : zoals jij het artikelnr beschrijft, gaat het over een bepaalde representatie van de gegevens in je db, en ik ben persoonlijk voorstander van een uniforme (over de gehele db) en onveranderlijke key per record.

Zoals je zelf reeds vermeld hebt, is de key afhankelijk van een bepaalde 'afspraak' binnen het bedrijf, en ik ben persoonlijk nog geen enkel bedrijf tegengekomen waar die regels onveranderlijk zijn.

Ik ga uit van de veronderstelling : zo weinig mogelijk kopzorgen bij een aanpassing van het systeem.

Wanneer men bv een leveranciersid zou toevoegen aan dit nummer, of een kleur, of een ik-weet-niet-wat, mag jij onherroepelijk een update doen op je artikeltabel, en gaan automatisch al je afhankelijke records ook ge-updated worden. Dus ipv 1 recordje te updaten, kunnen het er mogelijks miljoenen zijn... (met misschien zelfs een table lock tot gevolg etc... met alle gevolgen vandien...) )

Nogmaals Peter, voor mij hoef je het niet te doen, maar ik zou het wel aanraden vanuit praktisch oogpunt.

whoami schreef op dinsdag 21 juni 2005 @ 16:32:
Voor een simpele koppeltabel, gebruik ik ook geen surrogate key.
Maar da's dan weer iets anders...

[mierenneuk-modus]
Ik wel; je weet nl nooit dat je later nog een verwijzing naar die tabel nodig hebt.
[/]
Je kan natuurlijk altijd achteraf nog een surrogate toevogen he; zolang je geen ref nodig hebt kan je zonder

[ Voor 15% gewijzigd door D4Skunk op 21-06-2005 16:44 ]

[hobbit_be]

dus om even samen tevatten: de meeste practische mensen beschouwen een autonumber PK als een tool voor:
- altijd unieke dingen (no clashes in a PK)
(als je meerdere boeken hebt van eenzelfde zou dat al direct in een andere tabel moeten staan imho:
het boek als het bestaat an-sich, ie author etc
en dan een tabel met een 'instance' van dat boek...
- data onafhankelijk (de ID heeft geen semantieke waarde op zich)
- voor intern / structureel gebruik in een database zelf ie alle links op die manier
- SPEED!(neem aan dat de PK steeds in memory staan)

zelf geef ik graag toe dat al dat gedoe met links voor alle subdata best wel unreadable is als je puur naar je kolom staat te kijken. vandaar dat je dev-environment moet weten hoe ze je kunnen doorlinken. Dat kan nu zelfs in phpMyAdmin.

Invoeren van foute data op een semantieke PK kan toch altijd als je met people bezig bent: door een autonummer (een veld waarbij nooit een mens aan te pas kont) is de uniques al direct garantueed zonder checks: de rest doe je dan met UNIQUE (over meerdere velden if you want).

Best wel interessant topiv... al die officieele namen