Was ist schneller einfügen oder bearbeiten

[franktron]

Was ist schneller wenn man eine Datensatz einfügt oder wenn man guckt ob einer da ist und den bearbeitet

[bate]

speed ist bei beiden der gleiche würd ich mal sagen. Der eigentliche unterschied ist die Abarbeitung im SQL Server ansich. Insert haben eine Niedrigere Priorität also Updates. Das heist wenn du Operationen machen willst die von dem Update/Insert abhängig sind dann würd ich dir vorschlagen ehr ein UPDATE zumachen. Sollte aber auf der DB eh nie was los sein ( wenig last ) dann ist es fast zu vernachlässigen.

[freak4fun]

Tja, bei fast vernachlässigbar ist die Frage wie viel Datensätze man prüft. Je mehr es sind, desto mehr wird es spürbar.
Ich weiß aber nicht ab wie viel es merkbar ist.

Vielleicht hast du ja die Zeit es mal zu testen.

MfG
freak

[alzaimar]

@bate: Einspruch! Äh..na ja...
Bei MySQL muss man es probieren, aber bei einer richtigen DB , die also die Speicheroperation sofort physikalisch auf die Platte schreibt, und erst dann zum Client zurückkehrt, ist ein INSERT i.a. wesentlich aufwändiger, als ein SELECT/UPDATE.
INSERT fügt eine neue Zeile ein, die Indizes werden allesamt überarbeitet, die Daten werden geschrieben etc. Das ist schon ein ganz schöner Verwaltungsaufwand. Natürlich nur, wenn Indizes vorhanden sind.

SELECT kostet so gut wie nix, weil die Daten eh im Cache sind (na, meistens)
UPDATE kostet nur dann fast soviel wie ein INSERT, wenn wirklich alle Spalten verändert werden. Und selbst dann ist es noch etwas flinker, weil die Erzeugung eines neuen Datensatzes wegfällt.

Aber, was soll ich lange reden: Versuchs doch einfach. Obiges gilt für o.g. für MS-SQL. MySQL benutzt, glaube ich, kein direktes I/O, sondern schreibt irgendwann, weswegen es auch recht flott ist. Und unsicher. Und damit keine 'richtige' DB.

Ich würd's ausprobieren...

[franktron]

Zitat von alzaimar:

@bate: Einspruch! Äh..na ja...
Bei MySQL muss man es probieren, aber bei einer richtigen DB , die also die Speicheroperation sofort physikalisch auf die Platte schreibt, und erst dann zum Client zurückkehrt, ist ein INSERT i.a. wesentlich aufwändiger, als ein SELECT/UPDATE.
INSERT fügt eine neue Zeile ein, die Indizes werden allesamt überarbeitet, die Daten werden geschrieben etc. Das ist schon ein ganz schöner Verwaltungsaufwand. Natürlich nur, wenn Indizes vorhanden sind.

Daher ja meine frage

[Robert_G]

Hat mySQL Bulk DML?
Wenn ja _könnten_ Inserts schneller sein. Schließlich kann die DB vorher die Werte in den Arrays inspizieren, sortieren und in einem günstigen Fall erübrigt sich ein Rebuild der Indizes.
Der Fall wären Werte, die aufsteigend sortiert eine direkte Folge ergeben und größer als bestehende Unique-Indizes sein würden.
Bei non Uniques kann bei Bulks direkt ein Update auf die nested tables hinter den Indizes gemacht werden. Solange keine neue Indizes dazwischengequetscht werden.
Ein INSERT hat nunmal keine WHERE clause.

Bei StiNo SQL werden wohl UPDATEs flotter sein, wenn die WHERE Clause nicht zu lahm ist. Schließlich ist die Wahrscheinlichkeit hoch, dass nicht alle Indizes geändert und somit neu aufgebaut werden.

Bei Bulk SELECTs spart man sich die round trips für die einzelnen Zeilen. Damit ist man oftmals 10 bis 100-mal (je nach Datenmenge) schneller als mit einem stupiden API->fetch->API->read->API->fetch->API->read->API->...


Aber wie gesagt, erst mit BULK Operationen kann die DB über mehrere Datensätzen optimieren und planen.
Mach' dich einfach mal schlau ob und wie mySQL das unterstützt.

Wobei das eine prima hypothetische Diskussion ist, die leider bezogen auf dein Problem keinerlei praktischen Hintergrund hat.
Im RL kommst du nicht drumrum zu schauen ob es etwas zum Aktualisieren gibt bzw. ob du es einfügen musst...

[franktron]

@Robert ich hab das momentan so

Löschen alles
Füge neue Datensätze hinzu
das geht auch recht schnell dauert aber abundzu bis zu 2 Sec.
und das nervt etwas und ich kann den Code leider nicht mehr weiter optemieren(ich find nix mehr was schneller ist) was soll ich da tun.

[alzaimar]

Lustig, ist GENAU das, was ich gerade programmieren darf.
Ich mache es genauso wie Du, allerdings schmeiss ich alles in ein Skript und schicke das dann zum Server:

SQL-Code:

Delete from _Members where mID = 12345
insert into _Members (mID, oID) Values (12345,1)
...
insert into _Members (mID, oID) Values (12345,999)

Das geht recht flott. Ich merk jedenfalls nichts, selbst bei 100-300 Insert-Zeilen.

Packst Du auch alles in 1(!) Skript und schickst es dann zu mySQL?

[franktron]

Zitat von alzaimar:

Lustig, ist GENAU das, was ich gerade programmieren darf.
Ich mache es genauso wie Du, allerdings schmeiss ich alles in ein Skript und schicke das dann zum Server:

SQL-Code:

Delete from _Members where mID = 12345
insert into _Members (mID, oID) Values (12345,1)
...
insert into _Members (mID, oID) Values (12345,999)

Das geht recht flott. Ich merk jedenfalls nichts, selbst bei 100-300 Insert-Zeilen.

Packst Du auch alles in 1(!) Skript und schickst es dann zu mySQL?

Ne

[RavenIV]

Zitat von alzaimar:

Das geht recht flott. Ich merk jedenfalls nichts, selbst bei 100-300 Insert-Zeilen.

100-300 Zeilen ist doch keine Arbeit für nen SQL-Server.
erweiter deinen befehl mal auf 100'000 Zeilen, dann wirst du eher einen unterschied sehen...

gruessle