2016-04-13 8 views
1

ich ein einfaches Datenmodell in meiner Datenbank mit drei Tabellen:SQLServer Fremdschlüssel wird nicht lassen Sie mich Einschränkung mit Kaskade hinzufügen (auf löschen oder zu aktualisieren)

  • Staat
  • Ticket
  • SubTicket

Ein Ticket kann null bis mehrere Subtickets haben. Jedes Ticket und jedes Ticket kann einen Status haben.

So sieht meine Datenbank wie folgt aus:

my example Database

zwischen: xTicket und xState i die Einschränkung haben:

on update cascade/on delete no action (Aktualisierung der StateID in xTicket wenn geändert, probihit Löschen Sie den Eintrag in xTicket)

zwischen: xSubTicket und xTicket Ich habe die Einschränkung:

on update cascade/on delete cascade (die TicketID in xSubTicket aktualisieren und einen Eintrag zu löschen, wenn ein Eintrag in xTicket gelöscht)

aber wenn ich auf die gleiche Einschränkung will wie für xTicket und xState für:

on update cascade/on delete no action Ich bekomme die folgende Nachricht:

Fremdschlüssel Einschränkung kann cy verursachen zeuge oder mehrere Kaskadenpfade

der Fremdschlüssel mir nur die Einschränkung ON UPDATE CASCADE entweder zwischen xTicket und xState oder zwischen xSubTicket und xState setzen lassen.

bisher habe ich andere Fragen über das gleiche Problem, wo ich kennen gelernt: Entweder ändern Sie die Datenbank-Design richtig oder die Verwendung von INSTEAD OF Triggers. - Ich möchte eigentlich wissen, warum dieses Design nicht akzeptabel ist, was mache ich falsch? Wie mache ich das richtig?

Dank für jede Anregung im Voraus

Antwort

1

Ich möchte wirklich wissen, warum dieser Entwurf nicht annehmbar ist,

Warum denken Sie, ti nicht akzeptabel ist? Dies ist lediglich eine Einschränkung von SQL Server. Ein unbequemer.

Sie können frei codieren und Trigger für die Kaskadierung verwenden.

Ich würde ague Ihr Design ist kaputt, weil hartes Löschen von Zuständen nie passieren sollte und Sie versuchen, die Datenbank zu tun, Bereinigung, die möglicherweise komplexer sein kann. Ich würde für ein weiches Löschen (Markieren eines Status als nicht verfügbar für neue Objekte) gehen, so dass die Kaskadenoperationen dort keinen Sinn machen.Aber das ist eine andere Diskussion und außerhalb des Themas Ihrer Frage.

+0

Ich dachte ein einfaches Beispiel, da dies einen Fehler enthalten könnte, vor dem ich blind bin. Deshalb denke ich auch. - Ein Teilticket sollte entfernt werden, wenn sein Besitzer weg ist, richtig. Aber für Staaten möchte ich die Flexibilität, die Schlüssel zu ändern: z.B. Meine Schlüssel sind: 1: Ungelesen 2: Akzeptiert 3: Gelöst. Ich möchte jetzt einen neuen Zustand hinzufügen: Lesen Sie an der richtigen Position, die 2 ist. Daher möchte ich 3 zu 4, 2 zu 3. Am einfachsten wäre es, diese Art von Einschränkung hier hinzuzufügen. – KnusperPudding

+0

Nun, zuerst - Schlüssel und Statuscodes sollten unterschiedlich sein. 2. - Sie werden nicht "dumm" einen Staat entfernen. Stattdessen wird ein Migrationsprogramm ausgeführt, das zuerst die Zustände neu migriert. In diesem Fall brauchen Sie kein kaskadierendes Löschen, nicht in der Realität. – TomTom

+0

Ich möchte kein kaskadierendes Löschen. Eine kaskadierende Aktualisierung wäre genug genug wie der Umordnungsteil mit Lesen/Akzeptiert/Gelöst/Lesen. - Wenn es eine Möglichkeit geben würde, dies zu "reparieren", kann ich es in ein komplexeres Datenbankmodell übertragen, das ich habe. Dort habe ich eine Tabelle, wo viele Daten gelöscht und erstellt werden, also bekomme ich große Lücken zwischen IDs und ich kann die Daten mit niedrigeren IDs nicht neu anordnen. – KnusperPudding

Verwandte Themen