Firebird Feld mit foreign key "0" anstelle von NULL

[Emwykey]

Hallo zusammen,

ich habe eine einige Felder in meiner Datenbank welche ich überarbeiten möchte. Ziel ist es, dass über eine Fremdschlüssel Definition verhindert wird, dass der Master Datensatz gelöscht werden kann, sofern er in einer anderen Tabelle referenziert ist.

Das Problem ist, dass ich sofern kein Referenzdatensatz gewählt wird überall 0 anstelle von NULL gespeichert habe - warum sei jetzt mal dahin gestellt.

Jetzt will mir die Anlage der Fremdschlüssel nicht gelingen, da es keinen Datensatz mit der ID 0 in den Referenztabellen gibt.
Gibt es eine Möglichkeit die Datenbank so einzustellen, dass 0 wie auch NULL in diesem Bezug als Leer - Wert akzeptiert werden?

Danke im Vorraus und einen schönen Abend!

[himitsu]

FK zeigt auf etwas und wenn das nicht existiert, dann knallt es. (Ausnahme: NULL = nichts)
Also per se ist deine Definition falsch und alle 0 müssen NULL sein.

Ich weiß nicht ob/wie es mit ForeignKey geht, aber bei UniqueKey kann man in der Definition anstatt dem feldname auch z.B. nullif(feldname, 0) verwenden, womit der Index dort dann als NULL gespeichert wird.
Auch andersrum geht es beim UK, also z.B. coalesce(feldname, 0) und schon können auch NULL-Werte nicht mehrfach vorhanden sein. (NULL wird ja normalerweise von der Unique-Prüfung ignoriert)

[Emwykey]

Hallo,

danke für die Antwort.
In welcher Firebird Version geht das? Ich hab aktuell die 2.5 installiert und da lässt er das nicht zu.

[hoika]

Hallo,
das alles klappt aber nur (NullIf), wenn die Tabelle erzeugt wird.

Warum bereinigst Du deine Tabelle nicht vor dem Erzeugen des FK
Update Table Set FKFeld=Null Where FKFeld=0

[himitsu]

Zitat von hoika:

das alles klappt aber nur, wenn die Tabelle erzeugt wird.

Wenn der Index erzeugt (oder geändert) wird oder wenn nachfolgen Datensätze angelegt/geändert werden.

Wie gesagt, was und wie Firebird genau kann, weiß ich auch nicht, aber hier mal ein Beispiel aus PostgreSQL.
CREATE UNIQUE INDEX co_data_index ON component_options (co_item, COALESCE(co_minr, -2), COALESCE(LOWER(co_name), ''));
Aber viele andere DBMS können ebenfalls mit Funktionen in den Definitionen von Indize und Constraints umgehen und da denke ich mir, dass Firebird hier keine Ausnahme sein wird.


Aber deswegen auch zuerst der Vorschlag die Daten zu bereinigen, weil das bestimmt einfacher/besser sein wird.

[Delphi.Narium]

Einzige Krücke, die mir da so einfällt:

Mastersatz mit der ID 0 anlegen und kenntlichmachen, dokumentieren, dass dies die Referenz für die Sätze ist, für die es keine Referenz gibt und diesen vor dem Löschen (ggfls. auch Ändern) schützen, da ansonsten ggfls. mit ihm zusammen alle (eigentlich) nicht referenzierten Daten aus der Datenbank entfernt werden (was ja per Constrains durchaus umsetzbar ist).

Wenn Du dem Vorschlag die ID 0 auf Null zu setzen nicht folgen kannst, weil z. B. andere Nutzer / andere Software bei fehlender Referenz den Wert 0 für die ID vergeben und Du keine andere Lösung findest, das Problem per Constrains ... zu lösen, scheint das (erstmal) die einzig praktikable Lösung.

Prinzipiell sollte man sich aber nochmal grundlegende Gedanken über das vorhandenen Design der Datenbank und / oder der sie benutzenden Software machen. Ansonsten besteht die Gefahr, dass man bei mehr oder weniger dokumentierten oder undokumentierten Krücken zur Problembehebung bleibt.

Und sowas geht irgendwann schief, Murphy ist da geduldig und schlägt irgendwann gnadenlos zu

[mkinzler]

Ggf. anderes Programm per Trigger / View befriedigen.

Insert 0 -> NULL, Abfrage NULL -> 0.

[Neutral General]

Hab ich was verpasst oder würde ein einfaches

Code:

UPDATE
  tabelle
SET
  fk_feld = null
WHERE fk_feld = 0

nicht das Problem lösen?

[Delphi.Narium]

Wenn irgend ein Programm beim Einfügen neuer, nicht referenzierter, Sätze wieder 'ne 0 für die ID vergibt, wäre das nur 'ne Momentlösung. Und wenn es dann mit ID = Null nicht zurecht kommt, eher kontraproduktiv.

Das

Zitat von Emwykey:

- warum sei jetzt mal dahin gestellt.

aus der Threaderöffnung ist genau der Grund, weshalb man keine definitiv funktionierende Lösung vorschlagen kann.

Also benötigen wir erstmal eine Erklärung des Warum, um dann daraus eventuell eine Lösung, besteht aus einer Kombination der bisherigen Vorschläge (Update, Trigger, View, Constraint ...), entwerfen zu können.

[Neutral General]

Naja gut, dass man jegliche Trigger/Prozeduren und Programmcode dementsprechend ändern musst ist klar.
Ich meine um ehrlich zu sein gibt es keine andere ordentliche Lösung als das UPDATE + Codeänderungen (0 => null)
Alles andere wäre nur ein Workaround den man früher oder später eh wieder bereut.
Anders ist es ggf. weniger Arbeit aber man verarscht sich nur selbst.