besser nicht vermischen, was da wo passiert oder passieren sollte
Ein PK braucht bei fast allen datenbanken not null columns, auch bei Firebird
aber
Ein PK muss aber keineswegs überhaupt existieren noch aus nur einer numerischen ganzzahligen spalte bestehen, die das Datenbanksystem mit irgendwas füllen sollte
Daher sind irgendwelche Datenbanksysteme (welche auch immer das sind), die einen PK selber mit irgendwas selbstständig initialisieren, ohne das der
SQL dazu die regel vorgibt, aus meiner sicht nur begrenzt relevant, wenn überhaupt existent.
Aber zum thema: DDL/DML Transaktionen:
Firebird kann ohne probleme im laufenden Betrieb während leute offenen Selects auf einer Tabelle mehrfach abfragen und dadurch eine bestimmte Struktur z.B. mit select * erwarten bedienen.
Ein Alter Table add column .... erzeugt ein neues Format (in rdb$formats zu finden), in der dann auch die neue spalte zu finden ist. erst bei neu geschriebenen Datensätze wird da aber bei insert oder update dieses format herangezogen und man kann was in diese spalte schreiben. In jeder Datensatzversion innerhalb der Datenpages ist auch die verwendete rdb$format version hinterlegt 8bit, daher gibt es da unten in ibexpert manchma den hinweis xxx versions left on table yyy). Pro tabelle kann es 255 formats geben, für weitere alter table muss man dann ggf backup/restore machen.
ich denke mal der Teil der Erklärung geht weit über das hinaus, was man sich so üblicherweise beim alter table add .... vorstellt, aber alte säcke wie ich kennen das auch noch von
paradox oder dbase, bei denen eine strukturänderung dadurch gemacht wurd, das die komplette Tabelle in eine komplett neue Tabelle kopiert werden musste und das dauert ewig bei großen datenmengen, geschweige denn das man das mit offenen userconnections genau auf dieser Tabelle machen konnte.