Sqlite: Alternative für update

[Oli]

Hi,

Gibt es eine Alternative für Update?

Ich erstelle eine Datensatz:

* verkuerzte Version
$sqlq2 = "insert into $tbl(name,str,plz,ort,tel,eml,info)values('$name','$str','$plz','$ort','$tel','$eml','$info');";

Wenn ich nun etwas ändern will mache ich das mit Update.

Aber dieser Query ist mir dann zu unübersichtlich und zu lang.

UPDATE "Tabellen_Name"
SET "Spalte1" = [Wert].....
WHERE {Bedingung}

Kann man das nicht irgendwie so schreiben wie beim insert, oder einen anderen Befehl(habe mal was zu REPLACE gelesen aber versteh es nicht)?

Oli

[Ilja]

yo,

Gibt es eine Alternative für Update?
Aber dieser Query ist mir dann zu unübersichtlich und zu lang.

UPDATE "Tabellen_Name"
SET "Spalte1" = [Wert].....
WHERE {Bedingung}

nicht, wenn du nur ein update machen willst. dann ist das genau der richtige weg. was daran unübersichtlich sein soll, kann ich nicht nachvollziehen.

Ilja

[Oli]

Hi,

»» Gibt es eine Alternative für Update?

nicht, wenn du nur ein update machen willst. dann ist das genau der richtige weg. was daran unübersichtlich sein soll, kann ich nicht nachvollziehen.

bei mehr zeilen Update bietet sich demzufolge eine bessere Lösung an?

Was daran unübersichlich sein soll? Na ja ich mag kurze Querys, und jeweils set='' ist nun mal länger als tbl(feld...)values(werte...)

Noch eine andere Frage, ähm ist es eigentlich sinnvoll aus Suchgründen den Titel nun zu ändern? OK, das war nicht die Frage die kommt jetzt:

Sqlite kennt kein Concat, soweit ich das feststellen kann, bleibt da als Alternative nur zb. "select * from $tbl where name||tel||info LIKE '%345%'";?

Und, bevor ich jetzt für jeden Fehler hier nachfrage, gibt es noch mehr solcher gravierenden Unterschiede zu Mysql, also ausser concat?

Perfekt wäre eine Seite, die  Sqlite-Abfragen mit Mysql Abfragen direkt vergleicht. Also wo man sich eben umorientieren muss.

Oli

[Sven Rautenberg]

Moin!

Und, bevor ich jetzt für jeden Fehler hier nachfrage, gibt es noch mehr solcher gravierenden Unterschiede zu Mysql, also ausser concat?

SQLite unterscheidet sich von dem Leistungsvermögen größerer Datenbanken nun mal teilweise extrem.

Deshalb hat irgendwer es mal so formuliert: "SQLite is there to replace fopen(), not to replace Oracle."

Du wirst nicht umhin kommen, dich mit der Dokumentation zu SQLite auseinanderzusetzen, um jeweils herauszufinden, welche Features geboten werden, und welche fehlen.

- Sven Rautenberg

[Oli]

Moin!

»» Und, bevor ich jetzt für jeden Fehler hier nachfrage, gibt es noch mehr solcher gravierenden Unterschiede zu Mysql, also ausser concat?

SQLite unterscheidet sich von dem Leistungsvermögen größerer Datenbanken nun mal teilweise extrem.

das ist klar, mir geht es auch nur um gebräuchliche Query Konstrukte, nicht hochkomplexe interne DB Möglichkeiten.

Deshalb hat irgendwer es mal so formuliert: "SQLite is there to replace fopen(), not to replace Oracle."

So sehe ich das auch, allerdings würde ich den Satz erweitern auf "... and to replace MYSQL in many times..."

Denn ich verstehe nicht, warum noch so viele auf Mysql setzen, wenn es gar nicht notwendig ist, im Gegenteil oft Sqlite die schnellere, unkompliziertere, wartungsfreundlichere und somit bessere Wahl wäre. Wenn ich mal so durch die Scriptarchive(zb. Hotscripts, usw...) stöbere, sehe ich Mysql als DB wo Sqlite hingehören sollte. Eben immer da wo nicht mit konkurrierenden Schreibzugriffen zu rechnen ist. Aber ich glaube der Hauptgrund ist PhpMyAdmin und die damit verbundene Bequemlichkeit.

Du wirst nicht umhin kommen, dich mit der Dokumentation zu SQLite auseinanderzusetzen, um jeweils herauszufinden, welche Features geboten werden, und welche fehlen.

Die echten Problematiken ergeben sich ja doch erst beim testen und somit hatte ich hier auf ein paar Erfahrungswerte gehofft.

Oli

[Alexander (HH)]

Moin Moin!

»» Deshalb hat irgendwer es mal so formuliert: "SQLite is there to replace fopen(), not to replace Oracle."
»»

So sehe ich das auch, allerdings würde ich den Satz erweitern auf "... and to replace MYSQL in many times..."

Sobald mehrere Prozesse gleichzeitig auf einen Datenspeicher zugreifen wollen, würde ich mich hüten, fopen() einzusetzen und mich mit dem Locking herumzuschlagen. Das ist in Oracle und PostgreSQL gut gelöst, MySQL soll sich ja gebessert haben, und bei Microsoft lebt man halt mit gelegentlichen Deadlocks. Ich muß allerdings zugeben, das mein letzter Krieg mit dem MS SQL Server schon fünf Jahre her ist. Vielleicht hat Microsoft ja mittlerweile gelernt, mit konkurrierenden Zugriffen umzugehen, ohne entweder die Datenintegrität zu gefährden oder in einen Deadlock zu rennen. (Man wird ja wohl noch träumen dürfen!)

Alexander

[Ilja]

yo,

bei mehr zeilen Update bietet sich demzufolge eine bessere Lösung an?

wievielen zeilen von einem update betroffen sind, das steuert man über die entsprechende WHERE klausel. im besonderen fall kannst du mit einem einzigen update alle zeilen einer tabelle verändern.

Was daran unübersichlich sein soll? Na ja ich mag kurze Querys, und jeweils set='' ist nun mal länger als tbl(feld...)values(werte...)

das ist so nicht ganz richtig. das SET schlüsselwort brauchst du nur einmal pro update anweisung und danach kommt ja auch eine liste von wertepaare zwischen spaltenname und wert. es ist sogar eigentlich übersichtlicher, weil sich die spalte und der werte direkt gegenüber stehen. bei einem INSERT muss ich genau auf die reihenfolge achten. und dort kann ich in aller regel nur einen Datensatz pro INSERT anweisung einfügen, wenn man mal von sonderfällen absieht, die Daten mit einem SELECT aus einer anderen tabelle zu befüllen.

Ilja