Forum: Datenbanken
by jobo,
4. Jan 2017
Mmh, also in dem Fall hier wo PK betroffen sind, würde ich das Deaktivieren von Constraints mal ausschließen.
Generell ist beim Deaktivieren von Indizes oder Constraints ja auch zu berücksichtigen, wer/was sonst noch grad im System geschieht.
Ebenfalls können aber neben den PK Keys und sonstigen Constraints auch reine Suchindices vorhanden sein. Die wären dann m.E. geeignet, sie zu...
Forum: Datenbanken
by jobo,
4. Jan 2017
Ah, wie wirkt sich das aus?
Nur auf die Aktualisierung oder auch auf die Nutzung bei Abfragen?
Die Einschränkung auf "ohne aktive Constraints" ist natürlich hart, wäre dann aber immerhin für reine Suchindices möglich.
Die Einschränkung deutet auch darauf hin, dass der Index nicht nur für Aktualisierungen deaktiviert ist, sondern auch für Abfragen.
Forum: Datenbanken
by jobo,
4. Jan 2017
Ja, ich sprach nur davon, dass hochfrequnete Commits einen Geschwindigkeitsnachteil haben gegenüber blockweisen, also dem reinen Commit Overhead.
Indizierungseffekte bspw. sind wieder eine andere Geschichte, defferable Indices sind auch interessant, aber nicht in jedem RDBMS verfügbar.
Interessant an deinen Ausführungen auch die BLOB Thematik, die ja vielleicht das Problem des TE berührt....
Forum: Datenbanken
by jobo,
3. Jan 2017
Meinst Du eine Batchkomponente?
Mittels Transaktionshandling sollte es eigentlich wurscht sein, was an Spezialitäten da ist.
Wenn man eine Reihe von Befehlen absetzt, werden sie erst mit "Commit" commited.
Viele Commits, nach jedem insert bspw, bringen auch eine Verzögerung. Blockweise commit sind schneller, ist aber glaub ich marginal.
Forum: Datenbanken
by jobo,
3. Jan 2017
Ja, ein Schlüssel kann aus mehreren Feldern bestehen.
Am interessantesten finde ich aber ein BLOB Text(80), der in das "Upsert" involviert ist.
Wie sieht es da mit Indizierung aus? Und wenn vorhanden, greift sie?
Wenn nicht, was ich mir ganz gut vorstellen kann, bedeutet jedes einzelne "Upsert" ein Fullscan. Das dann in einer Schleife und die Performance ist im A..
