Lebenslauf eines(! -jeden) Datensatzes
a) 1 x <insert>
b) N x <update|select> *
c) [1 x <delete>]
Du kannst die angegebenen Befehle insert, select, update, delete aktiv durch Dein Programm aufrufen, jederzeit.
Ebenso ist es bei sehr vielen DB so, dass Du Trigger definieren kannst, die abhängig von a), b) oder c) weitere Operationen durchführen, die wiederum aus a,b,c bestehen, Trigger arbeiten dabei unahbängig vom Code im Clientprogramm, sie werden nur durch den Clientbefehl ausgelöst.
Defaultwert
Arbeitest Du mit einem Defaultwert einer Tabellenspalte, so wird der je Datensatz nur ein einziges Mal wirksam, beim Fall a) Insert. Weiter gibt es keine Unterschiede zu anderen Spalten/Werten.
Der Defaultwert garantiert eine gewünschte Initialisierung. Aber ..
Timing
Bei diesem Thema gibt es noch (wiederum etwas abhängig von der DB) einen Zeitaspekt oder Reihenfolge.
Einerseits sind Trigger meist unterteilt in Before und After, Before Insert, After Insert usw., damit kann man recht filigran auf Datenänderungen reagieren.
Irrtierend ist aber für Dein Problem, dass ein Defaultwert zwar nur bei einem Insert greift, genau durch das Insert aber auch sofort überschrieben werden kann und der Defaultwert damit von Fall zu Fall niemals "stehen bleibt". Dein Insert aus dem Code löst also den Eintrag des Defaultwertes durch die DB aus, kann ihn aber genauso gut auch gleich überschreiben.
*
Am Rande
Trigger auf Select sind sehr exotisch. Die Erwähnung hier ergibt sich eigentlich nur durch meine Eingangsaufstellung des Lebenslaufs eines Datensatzes. Kannst Du gleich wieder vergessen.
Verständnis:
Ich weiß nicht welche Vorkenntnisse Du hast, aber eine Anmerkung zu DB allgemein, die vielleicht hilft.
DB (RDBMS) sind ursprünglich dazu gedacht, als Server undabhängig vom Zugriff verschiedenster(!) Programme eine konstistente Datenhaltung zu garantieren(!). Ja, garantieren, nicht versuchen oder zu 99% oder so. Die DB war sozusagen vor Java da und kam auch gut ohne aus, z.B. mittels Defaultwerten und vielen anderen Konstrukten.
Heute gibt es eine große Vielfalt an DB Systemen mit ganz unterschiedlicher Leistungsfähigkeit. Die Basics sollten sie aber unterstützen (ACID Konformität).
Diese Basics werden heute allerdings via Hibernate / JPA gar nicht mehr unbedingt im ursprünglichen Sinne eingesetzt/genutzt. Eine Persistenzschicht gemeinsam mit dem (Java) Programm bestimmt, welche Daten wie in die Tabellen kommen. Business Logik und Konsistenz werden also vom Programm geliefert bzw. definiert.
Ein Spaltendefaultwert liegt außerhalb Deines Programmes.
Wenn Du also einen bestimmten logischen Ablauf entwickelst in Deinem Programm, der u.U. eben auf diesen Spaltendefaultwert angewiesen ist, sollte Dir das Zusammenspiel Deiner Programmlogik und das Verhalten der Tabelle und ggF. das der Persistenzschicht (wenn Du es nutzt) klar sein.