..
Das Problem ist aber das es möglichst auch auf kleinen, virtuellen Servern laufen soll.
Mit der Integer Filterung sollte doch eigentlich jede
DB klarkommen,
Ich hoffe auch effizient genug.
..
StoredProcedures wären auch eine Option, z.B.
Spricht denn generell etwas gegen eine eigene, kleine Filtersuche, wie unten ?
Selbst wenn TabZiel im GB Bereich liegt sollte das flott rüberkommen,
..
In erster Linie wollte ich checken wie man
SQL und Parameter dafür optimieren könnte.
Klein?
RAM, Platte, CPU? Eine Postgres Installation hat ca. 90MB glaub ich, weit weg von GB Datenfiles, trotzdem natürlich viel mehr als SQLite. Postgres läuft problemlos auf einem Raspberry. Es gibt fertige Dockerimages dafür (und andere
DB natürlich). Kommt vom Nutzeffekt (Plattenverbrauch) stark auf die Konstellation an. Eine Virtualisierung über ein VM Image in VBOX oder VMware benötigt selbst mit Linux ohne X Oberfläche >1-2Gb plus Nutzdaten. Ein winziges Dockerimage (nur
DB) ist natürlich toll, wenn es denn zum Host passt. Unter Windows ist es sehr wahrscheinlich nicht besser. Eine SQLite Lib ist natürlich winzig, aber kein Performance Brüller.
Das Prinzip nach vorbestimmten ID zu suchen ist eben das simple Prinzip solch einer Volltextsuche, da sehe ich kein Problem.
StoredProc werden häufig missverstanden als pauschale Beschleunigung, die alles schneller machen. Das ist nicht richtig, SP sind schnell, weil sie per Definition auf Server-lokale Daten zugreifen. Lässt man funktional identischen Code auf einem Client laufen, muss er viele Daten herunterladen. Das ist das, was Du vermeiden willst. Sehr häufig sind normale
SQL Statements genauso schnell, so lange sie auch nur ein auf dem Server ausgewertetes (kleines) Ergebnis runterladen. SP bieten allerdings meist viel mehr Möglichkeiten, als reines
SQL.
SQL Optimierung ist m.E. sehr Hersteller spezifisch. Zumindest wenn man ordentlich normalisiert hat und keine logischen Fehler im Modell stecken. Performance Optimierung bedeutet u.U. dann ab da auch, eine ordentliche Normalisierung gezielt zurückzunehmen. Der Preis für mehr Geschwindigkeit ist häufig redundante Datenhaltung. Die muss halt trotzdem wasserdicht sein, damit keine Artefakte entstehen. Parameternutzung empfiehlt sich immer, ein
SQL, das im Client gemäß Suchanfrage dynamisch Kriterien eingepflanzt bekommt, muss auch dynamisch mit Parametern versorgt werden. Wenn Du Dir dagegen ein Fulltext Search Beispiel mit ts_vektor in PG anschaust, stellst Du fest, hier kann bereits ein Parameter mehrere Suchbegriffe enthalten.