Tabellendefiniton "Not NULL" entfernen

techassist

Neuer Benutzer
Beiträge
3
Hallo,
ich habe eine MARIADB Tabelle mit einer Spalte erzeugt, die mit dem Attribut "NOT NULL" gekennzeichnet ist.
Ich benötige dieses Attribut nicht mehr und möchte es entfernen.

Eine umständliche Lösung, die mir eingefallen ist, wäre, die Tabelle neu anzulegen (ohne NOT NULL), diese anschließend mit den Daten der alten Tabelle zu füllen, die alte Tabelle zu löschen und die neue Tabelle umzubenennen.

Geht dies auch irgendwie einfacher?

Viele Grüße und vielen Dank

Christian
 
Werbung:
Hast Du ein Backup?

Zuerst sicherstellen, dass alle Records tatsächlich ungleich NULL sind. Dann mit Alter Table den Constraint ändern
alter table <table modify <column> <type> NULL|NOT NULL;
 
Hallo dabadepdu,
vielen Dank für deinen Hinweis! Ja, ich habe ein Backup.
Gibt es noch eine elegante Möglichkeit festzustellen, ob die Änderung etwas vernichtet hat, also ob die Inhalte der geänderten Tabellen mit dem Backup übereinstimmen?
Mir würde hier nur eine händische Stichprobe einfallen...

Viele Grüße und vielen Dank

Christian
 
Wenn Du das Constraint entfernst, lockerst Du ja die Regeln. Warum sollte sich dann etwas ändern? Umgedreht wird es interessanter:

Code:
edb=*# create table techassist(a int not null, b int);
CREATE TABLE
edb=*# insert into techassist values (1, null);
INSERT 0 1
edb=*# alter table techassist alter column a drop not null;
ALTER TABLE
edb=*# alter table techassist alter column b set not null;
FEHLER:  Spalte »b« von Relation »techassist« enthält NULL-Werte
 
Gibt es noch eine elegante Möglichkeit festzustellen, ob die Änderung etwas vernichtet hat, also ob die Inhalte der geänderten Tabellen mit dem Backup übereinstimmen?
Mir würde hier nur eine händische Stichprobe einfallen...
Es ist ja schon geklärt. Ich will nur ergänzen, dass mein Beitrag irreführend ist, weil er nicht ordentlich zwischen NULL und NOT NULL unterscheidet. Du wolltest ja einen Constraint lockern bzw. entfernen. Das ist nie ein Problem, technisch. (Wenn auch dadurch die Möglichkeit besteht, dass der fehlende Konstraint ein Konstruktionsfehler im Workflow sein kann.)
Nur das Ergänzen (Verschärfen) eines Constraint kann problematisch werden(fehlschlagen), wenn vorhandene DS den neuen Constraint verletzten. Oder wenn neue DS mit den programmierten Workflows nicht mehr wie gedacht/geplant angelegt werden können.

Das ist aber alles abprüfbar durch Select-Statements mit einer Where Clause entsprechend des Constraints! Schon vor dem Setzen kann man prüfen, ob es Verletzungen geben wird. Und wie akretschmer schon gezeigt hat, treten wirklich Verletzungen ein, so schlägt die entsprechende Anweisung fehl, "folgenlos" bzw. "verlustfrei". Die Anführungsstriche deswegen, weil die letzte Anweisung natürlich trotzdem gescheitert ist, also das Setzen des Constraints, oder Insert, Update, Delete eines Datensatzes oder mehrerer produziert einen Fehler.

Das ist ein wesentliches Prinzip einer richtig funktionierenden Datenbank! Es ist umso großartiger, je vielfältiger die erstellbaren Regeln sind, die eingesetzt werden können (sofern sie auch wirklich eingehalten werden). Das ist zum Glück heute eine Selbstverständlichkeit, bei den allermeisten DB. Wenn man es berücksichtigt, kann man viel "Programmierung" sparen. Man muss nur noch entsprechende Regeln definieren. Der Lohn sind konsistente Daten.
 
P.S.
Zur Klarheit: Das Anlegen (noch weniger das Löschen) eines Constraint zerstört (oder ändert) niemals Daten, es kann höchstens fehlschlagen.
Es schärft (oder lockert) die Varianz und Konstellation der Daten. Der gezielte Einsatz von Constraints ist sehr empfehlenswert!
Das Löschen oder Lockern eines Constraints ist per se harmlos, allerdings ist es der Punkt, wo man ganz bewusst überlegen muss, ob die Logik von Programmen und Workflows da weiterhin mitspielt oder die größere Varianz an Daten auffangen muss.
Sehr gutes Beispiel dafür ist der aufgehobene NOT NULL Constraint, der durch Erlauben von NULL Werten bereits massive Auswirkungen auf normale Joined Queries haben kann. Das ergibt keinen Datenverlust, aber wirkt sich ggF. deutlich auf Reports o.ä. aus.
 
Das ist ein wesentliches Prinzip einer richtig funktionierenden Datenbank! Es ist umso großartiger, je vielfältiger die erstellbaren Regeln sind, die eingesetzt werden können (sofern sie auch wirklich eingehalten werden). Das ist zum Glück heute eine Selbstverständlichkeit, bei den allermeisten DB. Wenn man es berücksichtigt, kann man viel "Programmierung" sparen. Man muss nur noch entsprechende Regeln definieren. Der Lohn sind konsistente Daten.

So, wer MySQL im Einsatz hat, probiere folgendes und denke über das Ergebniss nach:

Code:
edb=# create table check_constraint(a int, check (a < 10));
CREATE TABLE
edb=*# insert into check_constraint values (1);
INSERT 0 1
edb=*# insert into check_constraint values (11);
FEHLER:  neue Zeile für Relation »check_constraint« verletzt Check-Constraint »check_constraint_a_check«
DETAIL:  Fehlgeschlagene Zeile enthält (11).
edb=*#
 
Werbung:
Zurück
Oben