Natürlich kannst du die Datenbankzugriffe auch verwalten und beispielsweise in eine Warteschleife einfügen. Allerdings ist es doch ein bisschen seltsam, die Datenbankleistung künstlich zu limitieren, nur weil man kein der Aufgabe angemessenes DBMS einsetzen möchte. Solange SQLite mit der Last zurecht kommt, besteht ja kein Grund zur Sorge, aber wenn die Last steigt, dann ist auch eine künstliche Verlangsamung nicht wirklich sinnvoll (zumal das ja andere Probleme, wie fehlende Persistenz und zusätzliche Komplexität mit sich bringt).
lunar hat geschrieben:Wenn du natürlich eine Abstraktionsschicht wie SQLAlchemy verwenden würdest, bräuchtest du dir darum nur bedingt Sorgen machen, da die eigentliche Datenbank austauschbar wäre.
1. Was heißt "bedingt"?
Naja, wenn du ein ineffizientes Datenmodell oder ineffiziente Ausdrücke nutzt, dann nutzt dir auch ein gutes DBMS nicht so viel
2. Denkst du, dass das problemlos in meine bestehende Architektur eingefügt werden kann (Remotezugriffe auf die DB mit Pyro).
SQLAlchemy an sich ist nicht komplex und bringt auch andere Vorteile, wie z.B. die Möglichkeit, SQL-Abfragen ohne Zeichenketten-Manipulation zusammensetzen zu können. Aber wie du das in dein Programm integrierst ... woher soll ich denn das wissen? Wenn deine Architektur den Dienst vom Datenbankzugriff sauber trennt, dann ist eine zusätzliche Schicht kein Problem, wenn du den Datenbankzugriff aber wild über den gesamten Code verstreut hast, wird das natürlich schwerer
3. Ist es sehr aufwendig, sich in SQLAlchemy einzuarbeiten, das in das Programm zu integrieren und alle SQL Statements zu ersetzen?
Sich in SQLAlchemy einzuarbeiten, ist nicht aufwendig, die Dokumentation bietet gute Tutorials. Es in eine Anwendung zu integrieren, kann dagegen sehr aufwendig sein, wenn die Anwendung schlecht strukturiert ist
