[SQL Server 2000] Referentie naar zichzelf

[Verwijderd]

Hoi ik ben bezig met het schrijven van een database voor een producten index. Daarbij worden de producten ingedeeld in categorieen.
Deze categorieen moeten geindexeerd worden in een boom structuur. Je moet dus aankunnen geven wie de parent is van een type.

Daardoor zou een boom te genereren zijn. De code werkt goed (geeft alle relaties weer, maar het ON UPDATE CASCADE gooit SQL server de volgende error omhoog:

code:

Server: Msg 1785, Level 16, State 1, Line 2
Introducing FOREIGN KEY constraint 'FK__ProductTy__Paren__77B5A9F0' on table 'ProductType' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Server: Msg 1750, Level 16, State 1, Line 2
Could not create constraint. See previous errors.

Hoe krijg ik het voor mekaar dat SQL server Update on Cascade goed doet.... Dit zou toch moeten werken

SQL:

/* Table For Product Types */
CREATE TABLE ProductType (
ProductTypeID           VARCHAR(30)     NOT NULL,
TypeName            VARCHAR(30)     NOT NULL,
Parent              VARCHAR(30)     ,
[Description]           VARCHAR(255)        ,
FreeTxt             VARCHAR(255)        ,

PRIMARY KEY(ProductTypeID),
FOREIGN KEY(Parent)     REFERENCES      ProductType(ProductTypeID) ON UPDATE CASCADE
);

[whoami]

Hmmm, er is hier onlangs nog een topic over geweest:

[rml][ SQL Server/SQL]Cascade Delete Foreign Keys[/rml]

[Verwijderd]

mmm dit gaat om een koppelings tabel. dit probleem gaat om een tabel die naarzichzelf linkt....

Maar die van de koppleings tabel is idd ook wel usefull, omdat dat een andere fout in me DB is.... Daar moeten verschillende releases aanmekaar worden gehangen!

[EfBe]

Update CASCADE geeft aan dat je PK values aan het modificeren bent. Dat is semantisch incorrect. PK values kun je semantisch niet wijzigen. Dat ben jij wel aan het doen.

Relaties met self is veelal een oplossing die de 'tree' initieel storable maakt, maar je kunt er geen reet mee. Ik heb in een andere thread (hier: [rml]EfBe in "[ MSSQL] N:N query"[/rml]) een betere oplossing gegeven hoe je trees moet opslaan. Lost meteen je cascading probleem op. (maar nogmaals: update cascade is een 'doodzonde'. )

[Verwijderd]

EfBe schreef op 30 oktober 2003 @ 09:59:
Update CASCADE geeft aan dat je PK values aan het modificeren bent. Dat is semantisch incorrect. PK values kun je semantisch niet wijzigen. Dat ben jij wel aan het doen.

Relaties met self is veelal een oplossing die de 'tree' initieel storable maakt, maar je kunt er geen reet mee. Ik heb in een andere thread (hier: [rml]EfBe in "[ MSSQL] N:N query"[/rml]) een betere oplossing gegeven hoe je trees moet opslaan. Lost meteen je cascading probleem op. (maar nogmaals: update cascade is een 'doodzonde'. )

TNX 4 the tip... Maar mijn idee achter die update cascade is dat men de category name nog moet kunnen wijzigen... Deze is namelijk PK. Indien iemand een foute key aanmakt moet deze namelijk gewijzigd kunne worden, anders krijg jekromme namen....

[whoami]

Tjah, ik vind eigenlijk dat je geen velden als PK moet gebruiken die een bepaalde betekenis hebben, en dus ook gewijzigd kunnen worden.

Je gebruikt imo best numerieke (identity) velden als PK. Je geeft als waarde gewoon een nummertje aan die PK die verder eigenlijk niks betekent. Dan hoef je die PK nooit te wijzigen.
Daarnaast zijn PK's in SQL Server standaard clustered indexes.
Die (clustered) indexen bepalen dus ook de fysieke volgorde van je records in je tabel. Als je zo'n veld dus aanpast, dan moet de volgorde van je tabel ook weer aangepast worden.

De stelregel is dat je PK's dus nooit wijzigt, en dat je enkel een clustered index legt op velden die (bijna) nooit wijzigen. (Je kan ook maar 1 clustered index per tabel hebben).

[Verwijderd]

whoami schreef op 30 oktober 2003 @ 10:30:
Tjah, ik vind eigenlijk dat je geen velden als PK moet gebruiken die een bepaalde betekenis hebben, en dus ook gewijzigd kunnen worden.

Je gebruikt imo best numerieke (identity) velden als PK. Je geeft als waarde gewoon een nummertje aan die PK die verder eigenlijk niks betekent. Dan hoef je die PK nooit te wijzigen.
Daarnaast zijn PK's in SQL Server standaard clustered indexes.
Die (clustered) indexen bepalen dus ook de fysieke volgorde van je records in je tabel. Als je zo'n veld dus aanpast, dan moet de volgorde van je tabel ook weer aangepast worden.

De stelregel is dat je PK's dus nooit wijzigt, en dat je enkel een clustered index legt op velden die (bijna) nooit wijzigen. (Je kan ook maar 1 clustered index per tabel hebben).

Totaly Agree.... Ben zelf ook niet zo kapot van het feit om PK dynamish en veranderbaar tehouden. MAar mijn stagebegeleider en de rest van de groep waarvoor ik de opdracht bouw wilde afkortingen als key hebben.... Ze wilde zelfs op bepaalde punte samengestelde keys maken....

Heb net me model aangepast door a\overal gewoon id nummers te nemen als NUMERIC en die dan te koppelen. Na wat uitleg aan mijn begeleider snapte hij het probleem en ging akkoord!

Bedankt voor de hulp allemaal!

[Jaspertje]

Verwijderd schreef op 30 oktober 2003 @ 13:35:
[...]


Totaly Agree.... Ben zelf ook niet zo kapot van het feit om PK dynamish en veranderbaar tehouden. MAar mijn stagebegeleider en de rest van de groep waarvoor ik de opdracht bouw wilde afkortingen als key hebben.... Ze wilde zelfs op bepaalde punte samengestelde keys maken....

Heb net me model aangepast door a\overal gewoon id nummers te nemen als NUMERIC en die dan te koppelen. Na wat uitleg aan mijn begeleider snapte hij het probleem en ging akkoord!

Bedankt voor de hulp allemaal!

Maar afkortingen als ID kunnen best, dan moet je alleen wel ervoor zorgen dat ze niet veranderd mogen worden. Het nadeel van een IDENTITY is dat het alleen een nummer is, Als je binnen de rest van een systeem een andere unieke code gebruikt, dan mag dit ook je ID zijn..

En met samengestelde keys is ook helemaal niks mis, sterker nog, als je een veel op veel relatie hebt is soms zelfs nodig

[ Voor 7% gewijzigd door Jaspertje op 30-10-2003 13:42 ]

[EfBe]

Lekkere stagebegeleider... als deze zelf nauwelijks niveau 1 databases is ontgroeid.