watchout
Legendundead
|
Abend... gleich zu meiner Frage:
Ich hab jetzt eine entscheidung vor mir für ein Script, und zwar kann ich mich nicht zwischen einem REPLACE oder UPDATE entscheiden...
Mein Problem liegt eigentlich darin dass ich nicht genau weiss wie mysql UPDATES handled, dh. was passiert zb. wenn ein Datensatz auf einmal grösser wird, als an der Stelle im File Platz is
Von REPLACE weiss ich dass der alte DS gelöscht und ein neuer geschrieben wird - halt mit gleichem unique Key.
Der Grund is einfach dass es möglich ist, dass sich 'zig Datensätze ständig ändern müssen und ich natürlich vermeiden will dass ich dann ein Lochsieb statt einem File hab, von Fragmentierung der Datensätze will ich garnet reden...
für meine anwendung:
-es existiert ein unique key
-ich kann recht einfach, und ohne zusätzlichen datenbankzugriff herausfinden, ob der alte record sich überhaupt geändert hat, oder ob ich updaten muss
-der table hat 3 felder:
--varchar(255) UNIQUE
--integer
--TEXT
wobei nur des text-feld sich ändern kann
das ganze is übrigens teil eines caching-systems, an dem ich gerade feile...
falls ihr weitere infos brauchts für die antwort, eh scho wissen: einfach reinposten
Bearbeitet von watchout am 09.03.2004, 17:18 (tippfehler im title | solved)
|
tomstig
OC Addicted
|
was sagt http://www.mysql.de/doc/de/index.html ??? 7.4.8 REPLACE-Syntax REPLACE [LOW_PRIORITY | DELAYED] [INTO] tabelle [(spalten_name,...)] VALUES (ausdruck,...),(...),... or REPLACE [LOW_PRIORITY | DELAYED] [INTO] tabelle [(spalten_name,...)] SELECT ... or REPLACE [LOW_PRIORITY | DELAYED]
[INTO] tabelle
SET spalten_name=ausdruck, spalten_name=ausdruck,...7.4.5 UPDATE-Syntax UPDATE [LOW_PRIORITY] [IGNORE] tabelle SET spalten_name1=ausdruck1, [spalten_name2=ausdruck2, ...] [WHERE where_definition] [LIMIT #] zwischen dem unterstrichenen und dem syntax von update ist kein unterscheid. obwohl ich nicht weiß, ob man beim replace hinten noch ein where anhängen kann... einfach testen. ich verwende lieber update, aber das ist geschmackssache... edith: Mein Problem liegt eigentlich darin dass ich nicht genau weiss wie mysql UPDATES handled, dh. was passiert zb. wenn ein Datensatz auf einmal grösser wird, als an der Stelle im File Platz is wenn deine eingabe größer als die erlaubte größe ist, dann gibt mysql einen fehler aus.... egal ob replace oder update....
|
watchout
Legendundead
|
tomstig, sorry aber das war wiedermal ein post den die welt nicht braucht...
1. ich kenn die syntax
2. mein problem ist nicht syntaktischer natur sondern performancemässiger
3. ich hab nicht geschrieben grösser als erlaubt, sondern grösser als an der stelle im file platz ist, was bei varchar/text feldern recht schnell passiert.
|
mat
AdministratorLegends never die
|
Mein Problem liegt eigentlich darin dass ich nicht genau weiss wie mysql UPDATES handled, dh. was passiert zb. wenn ein Datensatz auf einmal grösser wird, als an der Stelle im File Platz is das kommt auf den tabletyp an. hier steht ein bissi.. es sollte aber bessere beschreibungen geben. http://www.dwam.net/docs/mysqle3.23...tml#Table_typesedit: vorsicht annahmen die nicht bestätigt sind: uU wäre es am gescheitesten, wenn du fixe datentypen nimmst. also varchar(100). dann hast eine fixe rowlength und das kann wahrscheinlich von mysql optimiert werden. ich schlage ein kleines benchmarking experiment vor 
|
watchout
Legendundead
|
das kommt auf den tabletyp an.
hier steht ein bissi.. es sollte aber bessere beschreibungen geben.
http://www.dwam.net/docs/mysqle3.23...tml#Table_types
edit: vorsicht annahmen die nicht bestätigt sind: uU wäre es am gescheitesten, wenn du fixe datentypen nimmst. also char(100). dann hast eine fixe rowlength und das kann wahrscheinlich von mysql optimiert werden. ich schlage ein kleines benchmarking experiment vor jo, danke - is echt nicht viel was da steht, hab auch schon an anderen stellen vom manual ein paar andeutungen gelesen, das stimmt mich generell nicht sehr optimistisch... vor allem der teil mit der fragmentierung is eigentlich traurig... fixe tables sind in dem fall leider net möglich, da ganz einfach keine datentypen zur verfügung stehen die genug platz bieten, ausser text/blob halt und die sind beide dynamisch... edit: natürlich bin ich mit ziemlicher sicherheit an myISAM gebunden  ps: da war ein kleiner fehler bei dir (siehe rot) 
Bearbeitet von watchout am 06.03.2004, 20:36
|
mat
AdministratorLegends never die
|
sicher.. für fixed length wirds selten "var" sein  angeber
|
Ringding
Pilot
|
Fragmentierung wirst du immer haben, da kannst du gar nix dagegen machen. Also lass es lieber gleich sein und kauf dir 15K rpm Platten Wenn du aus dieser fragmentierten Tabelle nur wenige Spalten herauslesen willst, kann es auch sein, dass ein Index hilft. Wenn nämlich alle benötigten Spalten im Index sind, dann wird gar nicht auf die großen Records zugegriffen, sondern nur auf den Index (sieht man dann als using index im explain)
|
watchout
Legendundead
|
hmm, ja - das mit der fragmentierung sollte sich doch aber von selbst lösen wenn der datensatz ja komplett neu geschrieben wird und der alte gelöscht wird (REPLACE), oder? ich mein so blöd kann doch mysql net sein dass es den neuen DS gleich mal fragmentiert?
index wird mir nur schwer helfen, befürcht' ich...
|
atrox
in fairy dust... I trust!
|
nachdem du mit der "datenverarbeitungsschicht" über der "datenhaltungsschicht" sitzt, und mit erseren nur über eine (zumeist) mengenorientierte sprache miteinander kommuniziert (sql), hast du relativ wenig einfluß darüber wie deine daten wirklich abgelegt werden.
theorietisch sollte die darüberliegende schicht sich keine sorgen machen müssen, wie die darunterliegende ihre aufgabe erfüllt.
replace ist eine art zwitter zwischen insert und update, wird aber (wenn man sich die hilfeseite durchließt) mehr wie ein insert und delete behandelt. jede annahme über die internen vorgänge kann für die datenbank version n getroffen werden, kann aber bei n-1 oder n+1 ganz anderes sein. das ist das prinzip der kapselung.
ich würde mir viel mehr gedanken machen über eine ordentlich dimensionierte und parametrisierbare tabelle, mit den richtigen indezes und primary keys. wenn wirklich viel geschrieben wird, kannst du ja die tabelle hin und wieder reorganizieren.
|
watchout
Legendundead
|
nachdem du mit der "datenverarbeitungsschicht" über der "datenhaltungsschicht" sitzt, und mit erseren nur über eine (zumeist) mengenorientierte sprache miteinander kommuniziert (sql), hast du relativ wenig einfluß darüber wie deine daten wirklich abgelegt werden.
theorietisch sollte die darüberliegende schicht sich keine sorgen machen müssen, wie die darunterliegende ihre aufgabe erfüllt.
replace ist eine art zwitter zwischen insert und update, wird aber (wenn man sich die hilfeseite durchließt) mehr wie ein insert und delete behandelt. jede annahme über die internen vorgänge kann für die datenbank version n getroffen werden, kann aber bei n-1 oder n+1 ganz anderes sein. das ist das prinzip der kapselung.
ich würde mir viel mehr gedanken machen über eine ordentlich dimensionierte und parametrisierbare tabelle, mit den richtigen indezes und primary keys. wenn wirklich viel geschrieben wird, kannst du ja die tabelle hin und wieder reorganizieren. da fällt mir nix mehr ein ausser: JAWOHL!  ich schätze mir bleibt nix anderes übrig als einfach das von sinn her richtigere zu nehmen: UPDATE danke trotzdem an alle
|
Anmeldung