Zitat von
alzaimar:
Noch heine Anekdote:
...
da würde mich schon mal die datenbank dazu interesssieren, darfst du mir gerne schicken wenn das erlaubt ist.
aber mal ganz am rand:
truncate und delete from ist was völlig anderes, bei truncate geht kein rollback und keine Einschränkung
mit where o.ä.
Wenn du ein truncate als Trick willst, dann geht das auch mit firebird. Bau deine Foreign keys um in
Trigger mit Execute statements, dann sind da keine referenzen drin und du kannst jederzeit die
komplette tabelle löschen, obwohl die im Trigger benutzt wird (wenn auch dann erst zur Laufzeit
des Triggers erkannt wird das die Tabelle ja nun mal nicht da ist und du eben dann die
Exception
bekommst). (Prozeduren müssen dann auch auf execute statement umgebaut werden.
Per prozedur solltest du dir vorher noch die Metadaten der Tabellen zusammenbauen und merken.
Dann DROP TABLE und ggf. gleich per execute statement aus dem gemerkten metadaten wieder erzeugen.
Alternativ speicherst du den Tabellen quelltext einfach in einem Blob udn holst den bei bedarf wieder
raus.
Drop table habe ich letzte woche mit einer 60GB Datenbank auf einer Tabelle darin mit ca 25 GB gemacht,
ca. dauerte weniger als 5 Sekunden. Wenn aber Referenzen da sind, dann geht das eben nicht mit Drop
Table, es sei denn man nimmt o.a. Weg.
So eine Datenbank aufzubauen ist kein erheblicher Mehraufwand, aber damit hast du dann ziemlich sicher
kraut und rüben in den Daten, weil eben die Konsistenzen der Datenbank auch mal weg sein können.
ich frag mich auch was
MSSQL beim truncate macht wenn foreign keys da sind? vielleicht weisst du das ja
(ignorieren wäre die blödeste Lösung, aber man weiss ja nie).
Ein Foreign Key ist nichts anderes als eine Systemtrigger mit Index auf der Tabelle. Wenn du das per execute
statement in deine eigenen Trigger einbaust macht das kaum einen Unterschied.
Der Vorteil ist das dann eben alles möglich ist was du in deiner Implementation haben möchtest
Der Nachteil ist das dann eben alles möglich ist was du in deiner Implementation vergessen hast zu verbieten
Sogenannte "Weiche Foreign keys" sind damit aber möglich (nur dann prüfen wenn USER<>SYSDBA ist oder was auch
immer).
Die Laufzeit vom Delete wird immer wieder bei Firebird kritisiert, aber in der Realität muss man eben wissen,
das zu jedem Record eine neue Recordversion angelegt wird, die dann das Löschkennzeichen hat und den Vermerk,
welche Transaktion das gemacht hat. Wenn irgendwas schief läuft und die Transaktion eben noch aktiv ist und
nicht committed wird die bei nächsten Öffnen der
DB auf Rollback gesetzt. Damit sind alle Records wieder da!
Weil eben der Commit auf dem Delete nicht durchlief. Und du sogar mit der lesenden Transaktion eine
Transaktionsnummer brauchst, weil die nämlich ggf erforderlich ist, um Daten, die von anderen Transaktionen
schon gelöscht wurden, trotzdem noch die für deine Transaktion weiterhin sichtbaren Records anzuzeigen und
zwar ohne Transaktionslog und anderen Schnock Schnack.
Das Verhalten ist von
DB zu
DB verschieden. Ich hab schon so manche
FB DB gesehen ohne Foreign Key, ohne
Primary key, halt nur hier und da mal einen Unique index und fertig. Keine Prozeduren, Trigger maximal
für IDs usw. Wenn du deine
DB so aufbaust wirst du auch mit drop und create keine Probleme haben, geht
schnell, leider aber auch wenn was nicht ganz zuende gedacht ist. Das povoziert eben die Fehler zur
Laufzeit und die sind am schwierigsten zu finden.
Velleicht schreib ich mal wieder genau zu dem Thema was für den Entwickler .....