"Column 'id' cannot be null" ist aber nicht NULL

[Cronosti]

Hi zusammen,

ich habe eine kleine Frage zu einer Abfrage die ich gebaut habe.

INSERT INTO categories (id,description)
SELECT
IF(ISNULL(id), 0, MAX(id) + 1),
'Test'
FROM categories

Beim ersten mal funktioniert die abfrage auch, aber wenn ich sie noch einmal ausführe kommt der Fehler: "Column 'id' cannot be null"

Die Tabelle sieht so aus:

CREATE TABLE IF NOT EXISTS `categories` (
`id` int(11) unsigned zerofill NOT NULL,
`description` text DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Wenn ich den Primary Key raus nehme, dann kann ich den befehl auch ohne Probleme ausführen ohne Fehler und alles funktioniert auch.

LG
Cronosti

 

[Cronosti]

Hallo zusammen,

hab meinen fehler gefunden. ICh ahbe die abfrage war einfach falsch.

INSERT INTO categories (id,description)
SELECT
IF(MAX(id) IS NULL, 0, MAX(id) + 1),
'Test'
FROM categories;

so klappt es immer

 

[dabadepdu]

hab meinen fehler gefunden

Ok, Du hast selbst eine Lösung gefunden, während ich geschrieben habe.
Ich lass mal ein paar Sachen stehen, die ich geschrieben habe.

Was Du dort aufrufst, sieht eher nach einer Variante von Oracle decode() aus. MySQL isnull() hat nur einen Parameter. (Hast Du ja geändert)

Dann müsste man sich fragen, was diese Abfrage bewirken soll?
Nehmen wir an, Du hast bereits 10 Datensätze (oder jeder andere Zahl größer 1) in der Tabelle categories, was würde die (reparierte) Abfrage machen?

Um ID zu befüllen, die sehr wahrscheinlich ein Primär Schlüssel ist, würde man den Wert über eine Automatik erzeugen, z.B. auto_increment. Die Insert Abfrage von Dir würde den Wert überhaupt nicht mehr betrachten.
Dann gibt es ein weiteres, "verstecktes" Problem mit Deinem Modell. Zumindest lässt Tabellenaufbau und Benennung darauf schließen:
Es fehlt ein Unique Constraint auf die Spalte description. Ohne diesen Constraint produzierst Du zwar eindeutige ID, aber niemand interessiert es, wenn Du hinter den eindeutigen ID identische Beschreibungen verwendest.

 

[akretschmer]

so klappt es immer

Nein, das fällt dir irendwann schmerzhaft auf die Füße. Wenn z.B. mehrere solcher INSERTs gleichzeitig erfolgen sollen, wenn Transaktionen länger dauern, wenn die Tabelle größer wird, ...

Selbst so katastrophal schlechte Datenbanksysteme wie MySQL haben dafür bessere Lösungen.

 

[dabadepdu]

Nein, das fällt dir irendwann schmerzhaft auf die Füße

Wie gesagt, der Sinn dieser Abfrage bleibt im Dunkeln. Es kann in der Form nicht produktiv verwendet werden. Zumindest fällt mir keine Einsatzzeck ein, außer einmal auszuprobieren, wie man diese Tabelle schnell und bequem mit x beliebigen Werten befüllen kann. Aber vielleicht habe ich auch irgendetwas übersehen.

Oder diese Abfrage ist einfach nur ein Vehikel, um das Generieren eine eindeutigen ID zu testen, um es an anderer Stelle produktiv zu übernehmen. Dann trifft das zu, was Du schreibst und man könnte wie vorgeschlagen z.B. mit auto_increment arbeiten.

 

[akretschmer]

einfach nur ein Vehikel, um das Generieren eine eindeutigen ID zu testen

so sieht es für mich aus, kombiniert mit der Unwissenheit über automatisch generierte Keys.