SQL Frage zu UPDATE

Hallo

Ich habe eine Tabelle mit nur einem Datensatz, diesen aktualisiere ich jede Minute mit der SQL Funktion UPDATE. Daten kommen via CronJob.

Da es aber nicht exakt jede Minute neue Daten gibt stell ich mir jetzt die Frage, was macht UPDATE wenn es ausgeführt wird aber die Daten die aktualisiert werden sollen die selben sind? findet trotzdem ein Schreibzugriff statt? werden die alten neuen Daten trotzdem über die alten neuen Daten geschrieben? falls ja, wie kann man das verhindern? also das nur dann aktualisiert/geschrieben wird wenn es sich wirklich um neue Daten handelt?

Kommt wohl auf die Datenbank an. MySQL würde in dem Fall soweit mir ist nichts tun, also, kein Schreibzugriff.

Ich würde auch sagen, dass es auf die DB ankommt. Aber für alles gibt es eine Lösung: Stichwort Trigger!

Ich habe mal kurz gegoogelt und glaube auch was gefunden zu haben: http://www.eulanda.de/inside/entwicklerhandbuch/api/sql/customizing/customtrigger.htm
Schau mal ob dir der Part "Optimierte SELECTS und UPDATES" weiterhilft. Ansonsten einfach mal nach Triggern suchen oder selbst einen schreiben...

Gruß

Alles klar danke, das hilft mir weiter.

Nochwas, ist der Primary Key hier in dem Fall eigentlich pflicht? weil, es ist wie gesagt nur ein Datensatz "5 Spalten"die ständig verändert werden. Nun frage ich mich, welchen Sinn ein Primary Key hier hätte? und wenn er doch pflicht ist, was mache ich da? für was soll ich den Key erstellen? für irgendeine Spalte?

Primary Key bzw. überhaupt irgend ein Index bringt in diesem Fall gar nix, nein. Pflicht ist es in dem Sinne auch nicht.

Gut, weil MySQL-Admin mir da nonstop Hinweise vor die Füße wirft von wegen kein Index definiert.

Naja, dein Einsatzzweck ist auch nicht wirklich normal für eine Datenbank...

Achja: Falls die Werte sowieso nur temporär sind, könntest du auch eine MEMORY (RAM) Table benutzen, dann gäbe es so oder so niemals Schreibzugriffe auf die Platte. Nicht, dass das viel bringen würde.

Naja, egal wie man es macht ist es falsch. Mache ich es über Flatfiles dann bekommt man gesagt, warum keine Datenbank, macht man es über Datenbank, dann heisst es ...wzb. jetzt... ist nicht wirklich normal
Was also gibt es noch für Alternativen für so eine Sache? ich weiß keine. Doch über Flatfiles? doch da gibt es dann das Problem, wenn ein User in dem Augeblick wo ein Schreibzugriff stattfindet die Datei lesen will, erstmal ne Pause angesagt ist bis die Datei wieder frei wird.

Und das ist sicher? weil ich lese die Werte auch aus. Nicht das dann mal garnichts drin steht - warum auch immer. Und wie greift man eigentlich darauf zu? genau wie auf einer Tabelle?

wieviel weißt du denn über datenbanken?

du kannst deine datenbankzugriffe in transaktionen durchführen.
wenn die daten beim commit dann inkonsistent geworden sind, wird ein rollback durchgeführt.
du kannst die tabellen auch für diese transaktion read/write locken, sodass andere transaktionen geblockt werden können.

Nein, viel weiß ich noch nicht.

Die Daten sind wenn maximal 5 Minuten aktuell, danach sind sie überschrieben - durch andere Daten.

Hab das jetzt auf MEMORY umgestellt und das ganze scheint auch problemlos zu laufen.
Wieviel RAM wird denn hier jetzt für diese kleine Tabelle reserviert? in MySQL-Admin steht ja nichts darüber. Dann, Ram Speicher kann und wird wohl schnell fragmentieren da ja in dieser Tabelle nonstop Daten geupdatet werden. Nun stell ich mir erneut die Frage, habe ich mit MEMORY überhaupt was gut gemacht? denn, je frangmentierter der RAM desto langsamer wird das ganze doch auch, oder?

bu1137 schrieb:

Kommt wohl auf die Datenbank an. MySQL würde in dem Fall soweit mir ist nichts tun, also, kein Schreibzugriff.

Zum Vergrößern anklicken....

korrekt

Belee schrieb:

Nochwas, ist der Primary Key hier in dem Fall eigentlich pflicht?

Zum Vergrößern anklicken....

Nein, eine gute Datenbank wird im Hintergrund sowieso unsichtbar für dich dann einen Primary Key anlegen, um die Tabelle zu verwalten.
Du solltest dir aber mal die Normalformen ansehen, wenn du keine Primärschlüssel definierst, dann wird diese Tabelle wie schon angemerkt auch sicherlich nicht im Zwecke einer Datenbank genutzt werden.

Belee schrieb:

Naja, egal wie man es macht ist es falsch. Mache ich es über Flatfiles dann bekommt man gesagt, warum keine Datenbank, macht man es über Datenbank, dann heisst es ...wzb. jetzt... ist nicht wirklich normal

Zum Vergrößern anklicken....

Da du einfach nur irgendwie Daten ohne jede Struktur abspeichern willst, darfst du gerne Flatfiles nutzen.

Belee schrieb:

Was also gibt es noch für Alternativen für so eine Sache? ich weiß keine.

Zum Vergrößern anklicken....

NoSQL-Datenbanken mit Hashtables, also einfach Key-Value-Datenbanken.
Das wäre auch die sinnvollste Änderung deiner Tabelle. Ändere die 5 Spalten einer Tabelle in eine Tabelle mit 2 Spalten: Key -> Value

Belee schrieb:

Doch über Flatfiles? doch da gibt es dann das Problem, wenn ein User in dem Augeblick wo ein Schreibzugriff stattfindet die Datei lesen will, erstmal ne Pause angesagt ist bis die Datei wieder frei wird.

Zum Vergrößern anklicken....

Auf Files darfst du auch shared Locks nutzen, also viele Personen dürfen gleichzeitig lesen, aber es darf nicht gleichzeitig ein Lese- und Schreibzugriff erfolgen.

Belee schrieb:

Und das ist sicher? weil ich lese die Werte auch aus.

Zum Vergrößern anklicken....

Nein, Memory-Tabellen sind nach einem Absturz des MySQL-Servers bzw. nach einem Neustart leer, es wird nur die Definition der Tabellen persistent gespeichert. Ein Blick in das Manual hätte dies dir aber auch offenbart.

Belee schrieb:

Wieviel RAM wird denn hier jetzt für diese kleine Tabelle reserviert? in MySQL-Admin steht ja nichts darüber. Dann, Ram Speicher kann und wird wohl schnell fragmentieren da ja in dieser Tabelle nonstop Daten geupdatet werden. Nun stell ich mir erneut die Frage, habe ich mit MEMORY überhaupt was gut gemacht? denn, je frangmentierter der RAM desto langsamer wird das ganze doch auch, oder?

Zum Vergrößern anklicken....

gefährliches Halbwissen, eigentlich war keine Aussage korrekt.
Memory-Tabellen arbeiten in-place, ein Datensatz behält also immer die gleiche Position, updatest du ihn wird nur der Inhalt überschrieben. Selbst wenn es Fragmentierung gäbe, ist ein Zugriff im Ram immernoch um eine Zehnerpotenz schneller als ein HDD-Zugriff.
Wieviel Ram du benötigst? Soviel um die Daten zu speichern plus einige Verwaltungsinfos.

Ja ich werde dann wohl das ganze wieder auf Flatfiles machen. Denn Datenbank ist ja eigentlich Blödsinn für diese Sache da die Daten sich ja nonstop ändern.

Mit Shared Lock meinst du LOCK_SH, LOCK_NB beim Schreibzugriff setzen?

::gefährliches Halbwissen, ja, besser als garkein Wissen aber man kann ja nur besser werden - hoffentlich.

Belee schrieb:

Denn Datenbank ist ja eigentlich Blödsinn für diese Sache da die Daten sich ja nonstop ändern.

Zum Vergrößern anklicken....

Diese Logik erschließt sich mir nicht

Belee schrieb:

Mit Shared Lock meinst du LOCK_SH, LOCK_NB beim Schreibzugriff setzen?

Zum Vergrößern anklicken....

LOCK_SH beim Lesen, LOCK_EX beim Schreiben. LOCK_NB bestimmt nicht, denn das führt dazu dass flock() nicht mehr blockiert wenn der gewünschte Lock-Modus nicht zu dem aktuellen Lock-Modus passt.

Das sind Antworten, da kann ich mir nicht einmal ne Erdnuss von kaufen. Ich habe vernünftig gefragt was du jetzt mit Shared Lock meinst...und ich glaube, ich werde darauf nie eine Antwort von dir bekommen, warum weißt du wohl besser als ich. Oder müssen wir euch Geld für vernünftige Antworten anbieten? es gibt ja mittlerweile Threads wo manche das ja schon quasi andeuten.
Deshalb EOT und kann zu. Mein Dank an die Jungs oben für die Antworten die mir geholfen haben.

Read Write Lock

schonmal daran gedacht, dass du einfach falsch fragst?
Du hast nur gefragt ob die Lock-Modi für flock(), die du denkst, die richtigen sind, mit keinem Wort, dass du mit Shared Locks nichts anfangen kannst.

Also komm von deinem Thron runter zu meinen jeder wolle dir nicht helfen sondern arbeite daran, Hilfe anzunehmen und ggf. konkret nachzufragen, wenn du irgendetwas nicht verstehst.