... dann jenachdem möglichst selten commiten, am besten nur einmal am Ende.
das "am besten am Ende" kann auch kontraproduktiv sein.
Ich mache es so, daß alle 1000-2000 Datensätze ein Commit erfolgt. (Oracle, Erfahrungswert)
das ist aber wohl von der Datenbank abhängig.
Tja. Das liebe Oracle. Hatten mal ein Oracle-Installation soweit in die Knie bekommen (mit einem Import) das sich selbst der Admin nicht mehr anmelden konnte.
Normalerweise sollte man bei einem Import der nur als ganzes gültig ist auch nur am Ende ein Commit machen.
In 2015 sollten selbst "schwachbrüstige"
DB-Installationen problemlos Commits nach 100.000 Inserts verkraften.
Diese 1000-2000 Datensätze ist mehr oder minder ein fauler Kompromiss der aufgrund der schlecht Implementierung oder Konfiguration der
DB geschuldet ist.
Letztendlich führt man mit so einem Commit die elementare Eigenschaft eines
DBMS (ACID) ad absurdum.
Oh bitte Bernhard, muss das wieder mal raus? Wem nützen denn solche Aussagen?
Wenn man ein paar Millionen Inserts am Stück braucht, muss halt das Rollback entsprechend konfiguriert sein, das hat mit Implementierung nichts zu tun. Und wenn der Admin sich auch nicht anmelden kann, dann muss er halt Anmeldung, Systemkonfiguration und Rollbackverwaltung noch mal üben.
Wer lieber kleine Häppchen mag, muss sich halt selbst darum kümmern, was bei einem Fehler geschieht. Mit "soeinem commit", Du meinst wahrscheinlich diese häufigen Commits bei Masseninsert, raubst Du Dir eine Menge Komfort bei Fehlern. Ad absurdum finde ich etwas übertrieben. Vielleicht ist es wie "immer nur für 10 Euro tanken, weil man nicht weiß, wieviel Geld man dabei hat". Na auch nicht ganz, aber kommt der Sache schon nahe.