IBDAC: In der DB sind Leerstrings statt Null. Alternativen?

[Int3g3r]

Zitat:

Zitat von Uwe Raabe (Beitrag 1445904)

Es gibt noch eine Möglichkeit: Wert bekannt und kein Leerstring, besteht aber nur aus Leerzeichen.

So wie ich das verstanden habe, ist diese Vorgabe <Leerstring> => NULL hier anwendungsspezifisch.

Genau genommen ist ja ein ("Leerstring" != NULL). Nur möchte ich solche Felder in der DB nicht haben. Es sieht einfach schäusslich wenn man Felder hat bei denen ist NULL eingetragen bei anderen wiederum sind "Leerstrings" drin. Am Benutzer ein "Leerstring" anzuzeigen oder einen "Leerstring" auszuwerden ergibt für mich keinen Sinn. Entweder hat ein Feld für mich erkennbare Daten oder es ist LEER = NULL.

Sicherlich kann es für andere Anwendungen Sinn machen wenn man wissen will ob je ein Eintrag gemacht wurde oder nicht. Für meine Anwendung ist dies aber nicht relevant.

[hoika]

Hallo,

Zitat:

bei denen ist NULL eingetragen bei anderen wiederum sind "Leerstrings" drin

Das liegt aber am Programmierer ;)

[MyRealName]

Man kann das Feld in Firebird ja auch mit einem Default belegen, der dann ein Leerstring ist.

[haentschman]

Moin...8-)

Zitat:

Ich möchte keine Leerstrings in meiner DB

...so scheiden sich die Geister. :P Ich mag NULL Werte in der Datenbank nicht. Für mich ist ein Datensatz eine "Einheit" ... und da gibt es keine "Null = Wert nicht bekannt" Felder. Ein Feld hat einen Wert, und wenn es '' ist. Zum Anderen hat man auch die Kontrolle, ob der Datensatz auch komplett geschrieben wurde. :wink:

[mkinzler]

Zitat:

Zitat von MyRealName (Beitrag 1445965)

Man kann das Feld in Firebird ja auch mit einem Default belegen, der dann ein Leerstring ist.

Das wäre dann geanu das Gegenteil von dem, was der TE will.

(Betreff des Threads ist etwas missverständlich)

[Int3g3r]

Ich versuche nun gerade auf der Datenbankseite dies zu realisieren.
Mir ist folgendes Beispiel zu umständlich, ich möchte nicht jedes Feld manuell im Trigger eintragen müssen:

SQL-Code:

SET TERM ^^ ;
CREATE TRIGGER <TABELLE>_BI FOR <TABELLE> ACTIVE BEFORE INSERT or UPDATE POSITION 0 AS
begin
  if ( new.<Feld> = '') then new.<Feld> = NULL;
end ^^
SET TERM ; ^^

Momentan habe ich im IBExpert einen "Parsing Error" den ich nicht weg bekomme.
Ich möchte das er automatisch die Felder der Tabelle holt und alle kontrolliert:

SQL-Code:

CREATE OR ALTER trigger "_TBTEST_BI0" for "_TBTEST"
active before insert position 0
AS
    declare variable field_name varchar(255);
begin
    for select rdb$field_name from rdb$relation_fields where rdb$relation_name=upper('_TBTEST') into :field_name
  do
  begin
    if (new.:field_name = '') then new.:field_name = NULL; --new.:field_name (Parsing error!)
  end
end

Gruss Int3g3r

[dataspider]

Der Doppelpunkt ist nicht so universell einsetzbar wie sich das mancher wünscht.
Der ist halt für Parameter - nicht zum Basteln eines Statements.

Du kannst IMO nur eine SP (als Beispiel: sp_check_emty_strings) schreiben, welche als Parameter den Tabellenname und den PrimaryKey-Wert bekommt.
In des SP baust du das Statement als string und führst das Statement mit execute statement ... aus.

In der Tabelle benötigst du dann einen AFTER INSERT OR UPDATE Trigger.

Im Trigger steht dann nur noch: execute procedure sp_check_emty_strings('TABELLENNAME', new.id)

Frank

[jobo]

Also, ich weiß nicht, ob es eine gute Idee ist, einen solchen generalisierten Trigger so einzusetzen.

Dynamisch alle Felder auf Null abzuklappern bedeutet in der Praxis:
- ignorieren von Key field Definitionen?
- schlechtere Performance
- Intransparenz

Die Verwendung optionaler Fremdschlüssel oder auch die Verwendung von PK und nicht optionalen FK erfolgt auf Basis allgemein verwendeter und notwendiger Vorgehen bei Modelierung und Datenverarbeitnug. NULL/ Not NULL ist fester Bestandteil im Umgabng mit Schlüsselfeldern und Fremdschlüsseln. Das sollte man nicht überformen.
Jedes Insert oder Update muss die Felder aus dem Dictionary auslesen, darüber loopen und mit den Eingangsdaten abgleichen. Das kostet Zeit.
Insertanweisungen werden intransparent "verbogen". Das ist mit Triggern leider immer so und man sieht es einem Tabellenfeld nicht an.

Wenn man sowas trotzdem machen möchte, wäre es vielleicht sinnvoller, statische Trigger herzunehmen, deren Code man meinetwegen anhand des Models generiert. Hier würde man gezielt alle Keyfields ausnehmen und auch alle Zahlenfelder, sowie alle not null Felder.
Außerdem könnte man Constraints einsetzen, die Leerstrings als Inhalt verbieten.

[Frickler]

Zitat:

Zitat von haentschman (Beitrag 1445966)

Moin...8-)

Zitat:

Ich möchte keine Leerstrings in meiner DB

...so scheiden sich die Geister. :P Ich mag NULL Werte in der Datenbank nicht. Für mich ist ein Datensatz eine "Einheit" ... und da gibt es keine "Null = Wert nicht bekannt" Felder. Ein Feld hat einen Wert, und wenn es '' ist. Zum Anderen hat man auch die Kontrolle, ob der Datensatz auch komplett geschrieben wurde. :wink:

Trotzdem muss man immer mit NULL rechnen. Jeder JOIN der kein INNER ist, kann NULL-Werte produzieren. Beispielsweise als Ergebnis eines Views oder einer Selectable Stored Procedure, das im Programm dann wie ein "Datensatz" aussieht - mit NULL-Werten drin.

Btw. Für

Code:

IF (feld = '') feld = NULL;

gibt es eine eigene Anweisung

Code:

feld = NULLIF(feld, '');

Ist quasi das Gegenstück zu COALESCE.