[DISC] Updaten van Primary Key fields, goed/slecht

[Verwijderd]

Ik ben met een data-tier generator bezig (C# classes + SQL Server stored procs) en voor het genereren van de UPDATE stored procedures stuit ik nu op een probleem: moet ik UPDATE stored procedures genereren die ook primary key fields updaten? Ikzelf vind het updaten van primary key fields niet correct, daar je dan semantisch een ander record krijgt (immers, de primary key fields identificeren het record), maar wellicht denken anderen daar anders over en hebben deze personen argumenten om wel primary key fields te updaten.

Het gaat met name om dit soort dingen:
table1 met 2 fields, Field1 en Field2. Dit zijn foreign keys in resp. table2 en table3 en tezamen vormen ze de primary key in table1. Een updatequery hiervoor zou uitkomen op:

code:

CREATE PROCEDURE [sp_Table1_update]
@OldField1 type,
@NewField1 type,
@OldField2 type,
@NewField2 type
AS
UPDATE Table1
SET Field1 = @NewField1,
    Field2 = @NewField2
WHERE 
Field1=@OldField1 AND Field2 = @OldField2

Maar eigenlijk is dit semantisch een verkapte DELETE + een INSERT van een nieuw record.

Iemand een doordachte motivatie waarom het updaten van primary key fields wel een goede zaak is?

[Feyd-Rautha]

Updaten van Primary Keys is imo een slechte zaak. Waarom zou je dat willen doen? Een PK is er om een unieke waarde te geven aan ieder record? Ik zie niet in waarom je die waarde vroeg of laat zou willen wijzigen, en dan moet je nog eens de bijhorende foreign keys ook wijzigen...

[whoami]

Ok, bovenstaande post van avalanche is dus van mij. Als je het niet eens bent met die post, moet je uw kritiek op mij spuien.

[Verwijderd]

Op vrijdag 12 april 2002 17:39 schreef whoami het volgende:
Updaten van Primary Keys is imo een slechte zaak. Waarom zou je dat willen doen? Een PK is er om een unieke waarde te geven aan ieder record? Ik zie niet in waarom je die waarde vroeg of laat zou willen wijzigen, en dan moet je nog eens de bijhorende foreign keys ook wijzigen...

Je hebt soms koppeltabellen, die relaties aangeven tussen 2 tabellen, waar louter fields in staan die ook tot de primary key behoren, zoals mn voorbeeldtable. Het wijzigen van zo'n record kan semantisch worden uitgelegd dat de relatie tussen een record in tabel 2 en een record in tabel 3 is gewijzigd. Echter krijg je IMHO een nieuw record, niet een gewijzigd record. Ik stel deze vraag voornamelijk omdat ik andere geluiden tegen ben gekomen die (niet echt onderbouwd) beweren dat het moet kunnen.

[Verwijderd]

Op vrijdag 12 april 2002 17:39 schreef -Avalanche- het volgende:
Updaten van Primary Keys is imo een slechte zaak. Waarom zou je dat willen doen? Een PK is er om een unieke waarde te geven aan ieder record? Ik zie niet in waarom je die waarde vroeg of laat zou willen wijzigen, en dan moet je nog eens de bijhorende foreign keys ook wijzigen...

Daar ben ik het ook helemaal mee eens. Primary keys, moet je gewoon laten zoals ze zijn, voor je het weet zit je te verkeerd te updaten en raakt je database corrupt. Eer de database aan z'n limiet zit van z'n pk-nummer, heb je al lang weer een andere applicatie :-)

[dusty]

PK's zijn om gegevens binnen de database te koppelen. en niet voor "schoonheid" naar buiten.

Ga je PK's aanpassen zit je met het probleem dat je in principe de fundering van je huis overnieuw gaat aanleggen terwijl het huis er al op gebouwd is. In development maakt dat niet zoveel uit, echter in productie is het uit den boze.

[Verwijderd]

Ok, ik heb de knoop doorgehakt: GEEN PK update stored proc. Bedankt allen!

Moderators: deze kan dicht.

[justmental]

IMHO geef je het antwoord zelf al.
Wat je theoretisch doet is een delete en een insert in die relatietabel.
Dat dat technisch geimplementeerd is als een update doet er niet toe.

Als die relatietabel nog childs heeft is het natuurlijk wat anders.

[RickN]

Een database bevat gegevens. Gegevens kunnen veranderen. Dus primary keys ook. Geen probleem. Als ik morgen mijn naam verander op het gemeentehuis, moet ik dan opnieuw geboren worden?

Even duidelijker. Als je een goed doordacht database model hebt, waarin toch primary keys zitten die mogelijk kunnen veranderen, dan is dat gewoon zo en blijkbaar moeten primary keys dan updatebaar zijn. Geen problemen gaan zoeken waar er geen zijn.

edit:
Het niet toestaan van PK updates is een erg kunstmatige beperking.

[Creepy]

Op vrijdag 12 april 2002 18:06 schreef RickN het volgende:
Een database bevat gegevens. Gegevens kunnen veranderen. Dus primary keys ook. Geen probleem. Als ik morgen mijn naam verander op het gemeentehuis, moet ik dan opnieuw geboren worden?

Even duidelijker. Als je een goed doordacht database model hebt, waarin toch primary keys zitten die mogelijk kunnen veranderen, dan is dat gewoon zo en blijkbaar moeten primary keys dan updatebaar zijn. Geen problemen gaan zoeken waar er geen zijn.

edit:
Het niet toestaan van PK updates is een erg kunstmatige beperking.

Geef mij eens een voorbeeld van een goed doordacht database model waarin de PK updatebaar moet zijn... dat bestaat volgens mij niet.

Dat je een record delete ok.. toevoegen ok.. updaten van gegevens ok. Maar een PK is voor IN je DB. niet voor daarbuiten. Gegevens die in overzichten staan moeten updatebaar zijn, maar wat heb je aan een updatebare PK?

[RickN]

Op vrijdag 12 april 2002 18:22 schreef Creepy het volgende:

[..]

Maar een PK is voor IN je DB. niet voor daarbuiten. Gegevens die in overzichten staan moeten updatebaar zijn, maar wat heb je aan een updatebare PK?

Weer zo'n kunstmatige beperking... Met een PK identificeer je een record, er is niets dat je verbiedt om de gegevens in de PK verder ook nog nuttig te laten zijn.

Anyway, of ik nu een voorbeeld kan gegeven is irrelevant, waar het om gaat is dat de topic starter een andere vraag moet stellen. "Is mijn DB model zo goed? Ja, oh, dan moet ik blijkbaar m'n PK's kunnen updaten."

[ACM]

Op vrijdag 12 april 2002 18:22 schreef Creepy het volgende:
Geef mij eens een voorbeeld van een goed doordacht database model waarin de PK updatebaar moet zijn... dat bestaat volgens mij niet.

Daar zijn vast wel voorbeelden van te bedenken

Of ze allemaal perfect doordacht zijn, of absoluut niet anders kunnen is wat anders..

Dat je een record delete ok.. toevoegen ok.. updaten van gegevens ok. Maar een PK is voor IN je DB. niet voor daarbuiten. Gegevens die in overzichten staan moeten updatebaar zijn, maar wat heb je aan een updatebare PK?

Een PK is niet voor strict binnen de DB hoor
Ander zouden we alle topics op GoT hier met de titel aan moeten spreken ofzo ?

Dat je een PK "in principe niet" hoort te updaten is ook geen argument om het in alle gevallen compleet te verbieden...

Juist voor die enkele uitzondering die je kan bedenken (wat nou als je een klant nummer 13 geeft en hij daar allerlei bezwaren te heeft? Ga je dan die klant verwijderen en opnieuw toevoegen? Of dmv een cascading-update het nummertje wijzige in 14 ?)

[Verwijderd]

Op vrijdag 12 april 2002 18:32 schreef RickN het volgende:

[..]

Weer zo'n kunstmatige beperking... Met een PK identificeer je een record, er is niets dat je verbiedt om de gegevens in de PK verder ook nog nuttig te laten zijn.

Het is echter zo dat bij PK's die wijzigen je in theorie dezelfde PK kunt krijgen als een al bestaand record. Dit geeft automatisch (IMHO, vandaar dit topic) de semantische flaw aan, dat je PK's niet zou moeten wijzigen. (want wil je dat wel, dan zou je de fields in de PK moeten objectificeren, dus uit de key halen en de PK fields voorzien van een enkele PK, bv een identity field).

Anyway, of ik nu een voorbeeld kan gegeven is irrelevant, waar het om gaat is dat de topic starter een andere vraag moet stellen. "Is mijn DB model zo goed? Ja, oh, dan moet ik blijkbaar m'n PK's kunnen updaten."

Het gaat om een generator, die ook door anderen dan mijzelf moet kunnen worden gebruikt, althans, daar ga ik nu van uit (het is mn C# knutselproject, maar kan voor veel mensen nuttig zijn). Als ik alleen de zaken inbouw die voormezelf voor zich spreken kunnen anderen wellicht zeggen: dit klopt van geen kanten. Vandaar mijn vraag om weerwoord, zodat het eindresultaat beter wordt.

[Creepy]

Op vrijdag 12 april 2002 18:35 schreef ACM het volgende:

[..]
Juist voor die enkele uitzondering die je kan bedenken (wat nou als je een klant nummer 13 geeft en hij daar allerlei bezwaren te heeft? Ga je dan die klant verwijderen en opnieuw toevoegen? Of dmv een cascading-update het nummertje wijzige in 14 ?)

Ik zou hem opnieuw toevoegen, en daarna verwijderen ja.. over het algemeen weet een klant z'n nummer toch niet. Klant komt aan, zegt: ik ben die en die ennuh <verhaal hier>
Figuur aan de balie/telefoon/whatever tikt naam in en zoekt klant op.
Dat jij daarna verder de klant aan z'n nummer identificeert is niet interresant voor de klant.

Hmm.. ok.. we hebben het hier over/14, maar op de frontpage staat "Programming & Webscripting". Hier wordt op geklikt, en tada... alles verschijnt.. dat er toevallig /14 in de adres bar staat.. ach.. maakt mij niet uit. Of het nummer nu /14 of /13467678 is maakt niet uit. De gebruiker klikt toch op "Programming & webscripting" (of bookmarkt em meteen)

De melding dat het nummer alleen voor intern gebruik is, daar bedoelde ik niet mee intern in de database, maar in het complete systeem.

Ok.. zo'n nummer komt ok vaak voor op een overzicht, maar het nut van die nummers op overzichten is meestal 0. Maakt het voor zo'n overzicht echt uit of het nu nummer 1 of 300 is?

Tuurlijk.. er zijn tig pasjes met een nummer er op, en als je het bedrijf van het pasje (bank, ANWB, donald duck.. whatever) belt of langsgaat, zullen ze waarschijnlijk vragen naar je nummer. Maar als je dat niet weet kunnen ze ineens ook zoeken op naam.

edit:
ff kort dan: Ik zie het nut er niet van in

[RickN]

Op vrijdag 12 april 2002 18:41 schreef Otis het volgende:

[..]

Het is echter zo dat bij PK's die wijzigen je in theorie dezelfde PK kunt krijgen als een al bestaand record. Dit geeft automatisch (IMHO, vandaar dit topic) de semantische flaw aan, dat je PK's niet zou moeten wijzigen.
[..]

Ja, maar dat risico loop je ook als je het huidige record verwijderd, en er een met een andere PK aanmaakt. PK zijn niet automatisch uniek, daar moet je wel iets voor doen (tenzij je een generator gebruikt natuurlijk) Semantisch gezien in een PK ook maar gewoon data en die kan soms veranderen.

Het gaat om een generator, die ook door anderen dan mijzelf moet kunnen worden gebruikt, althans, daar ga ik nu van uit (het is mn C# knutselproject, maar kan voor veel mensen nuttig zijn). Als ik alleen de zaken inbouw die voormezelf voor zich spreken kunnen anderen wellicht zeggen: dit klopt van geen kanten. Vandaar mijn vraag om weerwoord, zodat het eindresultaat beter wordt.

Begrijp ik, en mijn suggestie is: Als je het gevoel hebt dat je datamodel goed is, moet je er niet aan gaan sleutelen om er ook nog een of andere zeer kunstmatige beperking in te stoppen.

Ik ben geen voorstander van het updaten van PK's ofzo, en ik geloof ook best dat je het niet vaak nodig hebt, maar het vermijden ervan moet m.i. geen doel op zich worden.

[Creepy mode]
ff kort dan, ik zie het nut van het verbieden ervan niet in
[/Creepy mode]

[Creepy]

Op vrijdag 12 april 2002 18:50 schreef RickN het volgende:

[..]
[Creepy mode]
ff kort dan, ik zie het nut van het verbieden ervan niet in
[/Creepy mode]

[whoami]

Op vrijdag 12 april 2002 18:35 schreef ACM het volgende:

wat nou als je een klant nummer 13 geeft en hij daar allerlei bezwaren te heeft? Ga je dan die klant verwijderen en opnieuw toevoegen? Of dmv een cascading-update het nummertje wijzige in 14 ?

Wat weet die klant dat welk primary key zijn gegevens/record heeft in de databank. Een primary key hoef je toch niet 'openbaar' te maken, dit wordt gewoon gebruikt als 'administratie'.

[whoami]

Op vrijdag 12 april 2002 18:47 schreef Creepy het volgende:

[..]

Ik zou hem opnieuw toevoegen, en daarna verwijderen ja.. over het algemeen weet een klant z'n nummer toch niet. Klant komt aan, zegt: ik ben die en die ennuh <verhaal hier>
Figuur aan de balie/telefoon/whatever tikt naam in en zoekt klant op.
Dat jij daarna verder de klant aan z'n nummer identificeert is niet interresant voor de klant.

Ok.. zo'n nummer komt ok vaak voor op een overzicht, maar het nut van die nummers op overzichten is meestal 0. Maakt het voor zo'n overzicht echt uit of het nu nummer 1 of 300 is?

Een klantnummer ofzo hoeft toch niet hetzelfde te zijn als de PK?
Als ik al een uniek veld heb in m'n bv. klantgegevens, in dit geval 'klantnummer', dan ga ik dit meestal toch niet als PK gaan gebruiken. Ik gebruik liever geen 'gegevens' als PK, maar ik ga eerder een veld toevoegen dat dan de PK is.

[ACM]

Op zaterdag 13 april 2002 11:16 schreef whoami het volgende:
Wat weet die klant dat welk primary key zijn gegevens/record heeft in de databank. Een primary key hoef je toch niet 'openbaar' te maken, dit wordt gewoon gebruikt als 'administratie'.

klopt, je hoeft het niet openbaar te maken. Maar het is ook absoluut niet verboden.

Moraal van de postings van mij en RickN is dat je het jezelf niet moeilijker moet maken dan noodzakelijk.
Als blijkt dat het voor jouw applicatie handig is dat de PK's updateable zijn, zo zij het. Ga dan niet je complete DB-model aanpassen om dat weer te voorkomen, zeker niet als dat ook nog eens betekend dat je al je applicaties die op die DB draaien moet veranderen.

Het is niet strict verboden ze te wijzigen, anders was dat wel ingebouwd in de SQL-specs. Dat je ze in de meeste gevallen (vrijwel alle zelfs) niet hoort te of 'mag' wijzigen is weer wat anders.

Op zaterdag 13 april 2002 11:19 schreef whoami het volgende:
Een klantnummer ofzo hoeft toch niet hetzelfde te zijn als de PK?
Als ik al een uniek veld heb in m'n bv. klantgegevens, in dit geval 'klantnummer', dan ga ik dit meestal toch niet als PK gaan gebruiken. Ik gebruik liever geen 'gegevens' als PK, maar ik ga eerder een veld toevoegen dat dan de PK is.

En dus sla je redundate data op?

Het klantnummer is een voorbeeld van een identifier die niet/bijna nooit gewijzigd wordt. Ga je dan, voor die enkele keer dat het gewijzigd _zou_ kunnen worden nog een aparte PK erbij maken?

Ook het gebruik van 'gegevens' is absoluut niet verboden, dat je het liever niet doet is weer wat anders en dat je het niet de PK moet leggen op de echt wijzigende gegevens is natuurlijk algemeen bekend

Nogmaals, het zijn slechts voorbeelden die met gemak onderuit te halen zijn. Het moraal staat een stukje hoger in deze posting al

[drm]

Ik kan zo wel een voorbeeld bedenken waarbij je primary key moet kunnen wijzigen. (Natuurlijk kan je dat ook weer oplossen door verwijderen/opnieuw toevoegen, maar dat is overhead, imo).

Als je een koppeltabel hebt, met daarin een samengestelde primary key, en ik wil 1 bepaalde koppeling wijzigen (Product a moet even verplaatst worden naar productcategorie c, ipv b), waarom zou je dat dan niet gewoon door een update doen?

code:

UPDATE 
   koppeltabel 
SET 
   categorie_id=169 
WHERE 
   product_id=1 
AND 
   categorie_id=168;

Niks mis mee toch? Waarom zou je het jezelf moeilijker maken als het ook makkelijk kan