NOT NULL Attribut ändern

Hallo,
Wie kann ich bei einer firebird datenbank das NOT NULL Attribut einer Spalte im Nachhinein ändern (wenn schon datensätze in der Tabelle vorhanden sind)
geht das überhaupt

Versuch es mal so:

ALTER TABLE <Tabellenname> ALTER COLUMN <Feldname> DROP NOT NULL;

Ich weiß aber nicht, ob Firebird das so zuläßt. Vielleicht wäre auch ein vorhergehendes Backup sinnvoll.

nee das funktioniert nicht.
Ich glaube mittlerweile das das gar nicht geht!

Weil eine Spalte andersrum von NULL auf NOT NULL zu bringen ist offensichtlich in den meisten Fällen gar nicht möglich

NULL auf NOT NULL ändern wird vermutlich daran scheitern, dass es in der Tabelle NULL-Einträge gibt.

Andersherum sollte es immer gehen ABER:

Die Möglichkeit NULL-Werte zu verwenden deutet auf ein katastrophales Datenbank-Design hin.

Wer etwas Erfahrung im DB-Design hat wird keine NULL-Wert akzeptierenden Spalten verwenden.

Die Möglichkeit NULL-Werte zu verwenden deutet auf ein katastrophales Datenbank-Design hin.

Wer etwas Erfahrung im DB-Design hat wird keine NULL-Wert akzeptierenden Spalten verwenden.

Das sehe ich aber anders.

NULL-Werte haben eine wichtige Aussagekraft, nämlich, daß diese Zelle noch nie mit Werten gefüllt wurde, und damit deren richtiger Inhalt unbekannt ist.

Des weiteren gibt es verteilte Arbeitsabläufe, bei denen der eine Mitarbeiter einen DS anlegt, ein weiterer ihn vervollständigt usw.. Dann brauchst Du zwingend Spalten, die Null-Werte zulassen. Es sei denn, Du willst sie mit Default-Werten belegen, was aber auch ein Konstruktionfehler sein kann (z.B. Default auf Telefonnummer).

caspar_louis (off) schrieb:

Die Möglichkeit NULL-Werte zu verwenden deutet auf ein katastrophales Datenbank-Design hin.

Wer etwas Erfahrung im DB-Design hat wird keine NULL-Wert akzeptierenden Spalten verwenden.

Das sehe ich aber anders.

NULL-Werte haben eine wichtige Aussagekraft, nämlich, daß diese Zelle noch nie mit Werten gefüllt wurde, und damit deren richtiger Inhalt unbekannt ist.

Des weiteren gibt es verteilte Arbeitsabläufe, bei denen der eine Mitarbeiter einen DS anlegt, ein weiterer ihn vervollständigt usw.. Dann brauchst Du zwingend Spalten, die Null-Werte zulassen. Es sei denn, Du willst sie mit Default-Werten belegen, was aber auch ein Konstruktionfehler sein kann (z.B. Default auf Telefonnummer).

Wenn eine Spalte Nullwerte annehmen darf, liegt immer ein Designfehler vor. Abhilfe besthet darin, dieses Attribut in eine abhängige Tabelle auszulagern (PK/FK-Beziehung). Damit erledigt sich auch das Problem, dass einzelne Teile des Datensatzes von unterschiedlichen Leuten bearbeitet werden. Ohnehin ist es besser Telefon-Nummern in einer seperaten Tabelle zu verwalten, da eine Adresse über mehrere Telefon-Nummern verfügen kann. Ein weiterer Vorteil ist - bei Multiuserzugriffen - das Locking. Nicht alle Adressdaten werden nun gelockt, sondern nur die mit den Telefondaten.

DB-Designer, die Nullwerte verwenden würde ich sofort kicken.

DB-Guru schrieb:

Wenn eine Spalte Nullwerte annehmen darf, liegt immer ein Designfehler vor.
...
DB-Designer, die Nullwerte verwenden würde ich sofort kicken.

Da bin ich aber froh, das ich nicht für Dich arbeite(te).
Es ist nicht immer praktikabel das ganze System mit zu vielen kleinen Tabellen aufzublähen und unübersichtlich zu machen. Theoretisch hast Du vermutlich recht, aber die Praxis sieht nun einmal anders aus. Normalisierung hin oder her. Ich verwende NULL-Werte immer dort, wo eine Eigenschaft (pro Objekt) genau einmal vokommen kann, aber nicht muß.

@DB-Guru

Du hast es nicht begriffen!

Es gibt Spalten in einer Tabelle, da muß jede Zeile einen Wert enthalten (genau einen).

Die Vorbelegung mit 0 würde den entsprechenden Wert implizieren (= Fehler).
NULL zeigt an, daß bisher ein Eintrag versäumt wurde, der Workflow also noch nicht durch ist.

Das Wissen ist in UN verteilt.

Die Aufteilung auf mehrere Tabellen, würde eine not exists - Abfrage nach sich ziehen, die als Unterabfrage natürlich auf die Performance geht.

Ab gesehen, wer sagt Dir, daß das Wissen morgen nicht ganz anders verteilt ist? Willst Du jedes mal das DB-Desing ändern, wenn sich die Struktur der Wissensträger ändert oder die Prozeßkette im UN geändert wird?

Zur Normalisierung kann ich nur sagen, daß ich noch kein DB-System gesehen habe, daß bis zur Normalform 5 getrieben wurde und praktisch noch einsetzbar war.

Nun, jeder muss selber entscheiden, was ihm wichtiger ist - Wartbarkeit oder maximale Performance.

Wenn dann nach ein paar Jahren ein Redesign der Datenbank notwendig wird, wird man gewöhnlich die Entscheidung bereuen, den (scheinbar) einfacheren und schnelleren Weg gegangen zu sein.

Solange ich damit nichts zu tun habe, soll jeder machen was er will.