Ich habe ein paar Tutorials gelesen, wie man mit Rails 2.0 arbeitet.
(Time out: Genius Website Name Idee aus einem Tippfehler konzipiert ich gerade gemacht habe: "TutoRAILS." Sorry, zurück zu meiner Frage.)
In den meisten Tutorials, die ich gelesen habe, scheint es eher zu empfehlen, MySQL anstelle von sqlite3 zu verwenden. Gibt es einen Grund dafür, wie leistungsorientiert oder so? Ich bin gerade dabei, Rails auf meinem PC mit InstantRails zu testen, und sie sind nett genug, MySQL in ihr Setup aufzunehmen, aber ich habe meine experimentellen Anwendungen mit sqlite3 erstellt. Fehle ich eine wichtige Einschränkung von sqlite3, oder ist dies nur eine allgemeine Präferenz, die andere für MySQL haben?
SQLite ist eine gute Engine, aber es ist immer noch eine im Prozess (oder Desktop) -Stil-Engine. In-Process-Engines haben inhärente Schwächen in Bezug auf Parallelität, die sie zu einer grundsätzlich schlechten Wahl gegenüber serverbasierten Engines wie MySQL für Websites oder anderen Szenarien mit dem Potenzial für einen gleichzeitigen Schreibzugriff machen.
Siehe diese Seite auf der SQLite-Website:
Ссылка
SQLite funktioniert normalerweise gut als Datenbankmodul für Websites mit niedrigem bis mittlerem Traffic
und
Wenn ... Sie die Datenbankkomponente auf eine separate Maschine aufteilen möchten, sollten Sie definitiv eine Client / Server-Datenbank-Engine der Enterprise-Klasse anstelle von SQLite verwenden.
SQLite ist großartig, aber es gibt Leistungsprobleme mit mehreren gleichzeitigen Lesern und Schreibern.
Wie Joel sagte, wenn Ihre Site wenig Traffic hat, wird dies selten ein Problem sein, aber bei mittlerer Aktivität bekomme ich manchmal gesperrte DBs (und gehängte Abfragen). In diesem Fall ist eine DB mit besserer Unterstützung für mehrere gleichzeitige Benutzer besser.
Persönlich, wenn ich einen DB-agnostischen Layer für den Zugriff auf die DB verwende, dann ist es einfach, von einem zum anderen zu wechseln. Daher ist es einfach, mit SQLite zu beginnen und bei Bedarf zu einem anderen zu wechseln.
Ich beginne immer mit SQLite. Wenn ich ein Rails-Projekt entwickeln muss, kann ich buchstäblich im Handumdrehen laufen. Baue einige Scaffolds, laufe meine Migrationen, schreibe einige Tests und ich gehe in die Rennen.
Wenn jedoch ein Projekt den Punkt erreicht, an dem Sie es bereitstellen, würde ich MySQL oder PostgreSQL für eine bessere Leistung vorschlagen.
SQLite hat auch seine Vorteile für kleine eingebettete Anwendungen oder wenn Sie nicht den Overhead haben, um eine Datenbank für ein Tool auszuführen, das nur wenige Benutzer verwenden.
Seit Sails 2.0 ist sqlite3 die Standarddatenbank, also gibt es sicherlich keine Verzerrung dagegen. Viele Rails-Tutorials sind jedoch älter als Rails 2.0, wenn die Standarddatenbank MySQL war.
Wie einige andere bereits erwähnt haben, ist sqlite3 eine gute Datenbank, um schnell und einfach eine Anwendung zu starten. Für Ihre Rails-Entwicklungsumgebung hat es Beine - es wird wahrscheinlich gut funktionieren, auch wenn Ihre App komplex wird. Für die Rails-Testumgebung ist es auch eine sehr gute Wahl - es ist sehr schnell und die meisten Tests haben relativ einfache Datenbankanforderungen und neigen dazu, keine Nebenläufigkeit zu erfordern oder anderweitig auf die Einschränkungen von sqlite3 zu treffen.
Für viele, wenn nicht sogar für die meisten Produktionswebsites, kann eine Datenbank, die für mehr Parallelität ausgelegt ist, aufgerufen werden - MySQL, Postgres, etc ..
Für so etwas wie eine Rails-Blog-Engine wird SQLite auch bei ziemlich hohen Datenmengen sehr gut funktionieren, da es alles liest und nur sehr wenige schreibt. In der Tat wird die Mehrheit Ihrer Treffer im Cache sein - abhängig davon, ob Sie Kommentare zulassen und wie aktiv Ihre Kommentar-Threads sind - Sie könnten mit einem einzigen Rails-Prozess davonkommen, weil Ihr Webserver fast jede Anfrage bearbeiten wird.
Bei einer SQLite-Datenbank muss jeder Rails-Prozess um eine Dateisystemsperre für die Datei kämpfen, um Schreibvorgänge auszuführen, sodass Sie am Ende viel blockieren, wenn Sie viele Prozesse schreiben. Eine Möglichkeit, darüber nachzudenken, ist zu überlegen, wie viele Rails-Prozesse Sie haben werden ... wenn es mehr als 3-4 benötigt, dann ist SQLite wahrscheinlich keine gute Wahl.
Ich denke, es geht hauptsächlich darum, den Reibungspegel im Tutorial niedrig zu halten. Wenn Sie ein Newby sind, würde ich MySql nur empfehlen, weil es einfacher ist, das Tutorial zu machen. sqlite ist ansonsten eine gute Desktop-Lösung.
Beachten Sie, dass Sqlite die Standard-Engine für das Camping-Framework ist. Sinnvoll, da beide auf klein und schnell, nicht groß und enterprisey ausgerichtet sind
Tags und Links sqlite ruby-on-rails