Firebird Feld mit foreign key "0" anstelle von NULL

[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.

[Delphi.Narium]

Du sagst prizipiell in etwas krasserer Form das, was ich weiter oben meinte

Zitat:

verarscht

ist quasi der Klartext für:

Zitat:

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

[p80286]

Also wenn ich #1 richtig verstanden habe, gibt es Detail-Datensätze ohne Verbindung zum Haupt-Datensatz, was ja eher suboptimal ist. Da sollte wohl mal massiv aufgeräumt werden.

Gruß
K-H

P.s
Fehler machen wir alle, aber diese zukleistern ist nur wenig schlechter als Garnichts zu tun.

[jobo]

Wenn Du nicht willst, dass der Datensatz gelöscht wird, lege ein Feld an, dass diesen Status (und vielleicht andere Lifecycle Zustände des Datensatz definiert) und nutze einen Trigger, der das überwacht.

Die Referenz auf eine andere Tabelle dafür zu verwenden, ist besonders in Deinem Fall nicht möglich, außer Du legst eben den Datensatz mit Key 0 in der Fremdtabelle an.

Funktionsbasierte Indices würde ich für den Zweck auch nicht einsetzen- selbst wenn es ginge, was ich bezweifele- weil ein Index nichts mit dem Modell zu tun haben sollte.