Firebird Feld mit foreign key "0" anstelle von NULL

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

[IBExpert]

Ein Foreign Key ist technisch nichts anderes als ein Systemtrigger und ein Systemindex.
Es spricht nichts dagegen, den Trigger so umzusetzen, das der deiner Logik entspricht
und zum Beispiel mit einer Exception das Löschen verhindert

Code:

CREATE OR ALTER TRIGGER CUSTOMER_BD0 FOR CUSTOMER
ACTIVE BEFORE DELETE POSITION 0
AS
begin
  if (exists (select orders.customer_id from orders where coalesce(orders.customer_id,0)=old.id)) then
  exception err 'Customer kann nicht gelöscht werden, wenn noch noch Orders existieren';
end

das ist kein konkreter Vorschlag für deine Problematik, das so mit coalesce zu lösen, sondern
einfach nur ein Hinweis, das fehlende Logik in Foreign keys problemlos selbst gebaut werden kann.

Wenn hier im Beispiel kein Index auf orders.customer_id existieren würde, bricht die Performance
ein und jeder delete auf customer würde ein Full table scan auf orders auslösen. Daher sollte man
drauf achten, das da ein Index existiert. Die Deklaration eines Foreign Keys legt Trigger und
Index automatisch an, wenn es also dir so nicht passt, wie es deklarativ geht, do it yourself.

[Emwykey]

Danke erstmal für eure Antworten.

Generell ist es schon machbar die 0 Werte in NULL Werte zu ändern, der Aufwand wäre nur zeitlich sehr groß da es doch ziemlich viele Felder betrifft, weswegen ich wissen wollte ob ich noch andere (weniger aufwändige) Möglichkeiten habe. Diese Frage scheint damit beantwortet zu sein :)

[himitsu]

Dennoch könnte man sich jetzt überlegen das zu ändern,
denn wer weiß wieviele hundert Felder die nächsten Jahre noch dazu kommen,
und dann wird es immer schwerer zu ändern.

[jobo]

Zitat:

Zitat von Emwykey (Beitrag 1409207)

..zu ändern, der Aufwand wäre nur zeitlich sehr groß da es doch ziemlich viele Felder betrifft

Mmh, "großer Aufwand " klingt jetzt irgendwie nach einer Crowd Sourcing Aktion bei der 20 unterbezahlte "Eingabekräfte" Formulare durchackern und statt Nichs "0" eintippen.

Man kann mit SQL sowohl horizontal als auch vertikal ganz viele Felder "auf einen Schlag" aktualisieren.
Bei einem verteilten System müsste das durch eine Aktualisierung, einen Remote Support o.ä. erfolgen.

Ansonsten sehe ich es wie himitsu und würde nicht unbedingt die technischen Möglichkeiten in der Richtung ausreizen und eine bereits unkonventionelle Umsetzung noch weiter verändern.

[Emwykey]

Zitat:

Zitat von jobo (Beitrag 1409220)

Man kann mit SQL sowohl horizontal als auch vertikal ganz viele Felder "auf einen Schlag" aktualisieren.
Bei einem verteilten System müsste das durch eine Aktualisierung, einen Remote Support o.ä. erfolgen.

Ansonsten sehe ich es wie himitsu und würde nicht unbedingt die technischen Möglichkeiten in der Richtung ausreizen und eine bereits unkonventionelle Umsetzung noch weiter verändern.

Den Inhalt der Felder und deren Definition zu ändern ist weniger das Thema, eher die ganzen Routinen die darauf zugreifen und 0 eben als LEER interpretieren, NULL aber garnicht prüfen, da die Felder alle als not NULL definiert sind ...

Aber scheint als ob ich da wohl nicht drum rum komme...

[mkinzler]

Einfach SP oder VIEW, der das gewünschte Format liefert.

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1409230)

Einfach SP oder VIEW, der das gewünschte Format liefert.

Da das Programm auch schreiben will, wäre das dann ein "Updatable VIEW".