Trigger für Not-null-Feld

[Robinson_1979]

Hi ich habe eine DB mit der folgenden Struktur:

id int identity
key varchar
value varchar
lastUpdate datetime


ALLE FELDER SIND NOT NULL UND MÜSSEN ES SEIN


wenn ich jetzt eine neue zeile einfüge soll das datum als last Update automatisch eingetragen werden.

CREATE TRIGGER trigger_date_Lookup
ON Lookup
FOR INSERT
AS
    UPDATE [Inserted] SET lastUpdate=getDate()
GO

Leider bekomme ich bei einem INSERT
diesen Fehler:

Server: Nachr.-Nr. 515, Schweregrad 16, Status 2, Zeile 1
Der Wert NULL kann in die lastUpdate-Spalte, Lookup-Tabelle, nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT.
Die Anweisung wurde beendet.


Wie mache ich das richtig

 

[Nico Graichen]

Hi,

in dem du den Aufruf von getdate direkt in deinem insert machst und das aktuelle Datum direkt ein fügst. Dein Trigger kann dann entfallen.
oder
Du fügst für die Spalte nur ein Dummy-Datum ein, was dann über den Trigger ersetzt wird.

Aus meiner Sicht wäre Variante 1 eigentlich sinnvoller und schneller

 

[Robinson_1979]

Das stimmt natürlich,

es soll aber genau das vermieden werden.

Der Benutzer fügt nur die Spalten ein welche er bearbeiten (einfügen) möchte.
Den Rest übernimmt die DB.

Ich habe aber auch noch einen zweiten Anwendungsfall:
Neben der DB Id (int identity) soll eine zweite Id erzeugt werden.

(Hintergrund: einzellne Datensätze kommen aus einem zweiten System mit eigener Datenbank. Damit es hier nicht zu Konflikten kommt muss eine zweite eindeutige ID generiert werden. Das mache ich über die (int) id + präfix (Systemübergreifend eindeutig).

Diese neue ID muss primary Key (not null) sein weil es foreign Key Elemente gibt.

--> Beim Insert muss diese ID besetzt werden

Ich habe da gerade was von Triggern gelesen die das ausführen des eigentlichen SQL Statements unterbinden, ich glaube damit komme ich hin.

Teste das mal

 

[Nico Graichen]

Der Benutzer fügt nur die Spalten ein welche er bearbeiten (einfügen) möchte.
Den Rest übernimmt die DB.

Wie? Der Benutzer fügt die Daten ein?
Normalerweise sollte der Benutzer seine Daten in eine Oberfläche (o.ä.) eingeben und die dahinterliegende Anwendung trägt die Daten ein.
Der Benutzer hat nicht auf der Datenbank rumzuturnen.

Was aber auch noch eine Option wäre:
Du könntest auf die Spalte einen Default-Value setzen.

 

[ishino]

Du könntest auf die Spalte einen Default-Value setzen.

IMHO die einzig sinnvolle Variante. Mit Triggern sollte man generell sparsam umgehen und in Deinem Fall ist eben dieser völlig überflüssig. Default-Werte sind genau das, was Du suchst.

 

[Robinson_1979]

Da gehen die Ansichten in unterschiedliche Richtungen.

Eine Datenbank sollte stets in sich schlüssig sein so dass es egal ist ob der Benutzer eine GUI oder einen SQL Client verwendet!


Das mit dem Trigger auf der ID hat auch einen Grund,
ich erzeuge damit Ids welche sich zwischen verschiedenen unabhängigen Datenbanken synchronisieren lassen.


Bisher ist das über stored procedures realisiert, hierbei haben sich aber einige Nachteile gezeigt weswegen der Einsatz von Triggern hier bedeutend schöner ist.

Default Werte bringen mir leider überhaupt keinen Nutzen.

Ich habe meine Architektur jetzt ein wenig Angepasst so dass ich intern mit den auto Ids arbeite und nur für die Synchronisation die eindeutigen Ids heranziehe.

Danke für die Hilfe.

 

[ishino]

Da gehen die Ansichten in unterschiedliche Richtungen.

Nicht was die Vermeidung von Triggern an Stellen, an denen sie einfach nicht gebraucht werden, angeht. Trigger sind teuer, erschweren die Wartbarkeit, etc. Das wird jeder bestätigen, der praktische Erfahrung hat.

Eine Datenbank sollte stets in sich schlüssig sein so dass es egal ist ob der Benutzer eine GUI oder einen SQL Client verwendet!

Prinzipiell ja, nur kann und sollte ich Zusatzlogik nur in begrenztem Umfang in der DB unterbringen. Das heißt, krampfhaft zu versuchen, jeden möglichen Anwendungsfall über Datenbankmechanismen abzubilden, halte ich für sinnfrei.

Das mit dem Trigger auf der ID hat auch einen Grund,
ich erzeuge damit Ids welche sich zwischen verschiedenen unabhängigen Datenbanken synchronisieren lassen.

GUID einsetzen?

Default Werte bringen mir leider überhaupt keinen Nutzen.

Im OP ging es um das automatische Einfügen eines Datums, da machen DEFAULTs sehr wohl Sinn. Sobald dafür SPs ins Spiel kommen (die den DEFAULT erzeugen sollen), machen die meisten DBMS ohnehin nicht mit.