Immobilienportal
-
BlackJack
@meego: Das ist so ein bisschen wie die Frage welche Programmiersprache sich dafür eignen würde. Halt jede mit der man Webanwendungen schreiben kann. Genau so kann man Dir hier jetzt fast jede erdenkliche SQL- und NoSQL-Datenbanksoftware aufzählen.
@meego: für Umgebungssuchen wäre es gut, wenn die Datenbank irgendeine Form von Geo-Index unterstützt. Aber in Deinem Stadium kannst Du irgendeine Datenbank nehmen, denn Du wirst zuerst an die Grenzen Deiner Programmierkünste stoßen, bevor Du an die Grenzen der Datenbank stößt. Und wenn Du diese Grenze immer weiter hinausschiebst und tatsächlich die Datenbank limitierend wird, dann hast Du schon sehr viel gelernt und kannst mit diesem Wissen die für Dich passende Datenbank suchen.
@meego: natürlich ist SQL noch zeitgemäß. Oft sind auch documentbasierten Datenbestände besser in einer relationalen Datenbank aufgehoben. MongoDB ist für Anfänger leichter, weil man sich nicht so viele Gedanken über die Struktur der Daten machen muß, was aber später sicher Probleme macht, weil man sich am Anfang nicht genug Gedanken über die Struktur der Daten gemacht hat.
SQLite taugt nicht für Webanwendungen. MongoDB ist als Datenbank äußerst problematisch, afaik verliert es immernoch Writes in der Standardkonfiguration. Abgesehen davon sind relationelle Datenbanken flexibler einsetzbar als dokumentenbasierte. Wenn man also keine Erfahrung mit MongoDB hat und Anfänger ist sollte man davon ganz großen Abstand nehmen.
Ich würde PostgreSQL empfehlen. Damit kann man grundsätzlich nichts falsch machen und es bietet mit PostGIS auch den von Sirius3 angesprochenen Geo-Index.
Ich würde PostgreSQL empfehlen. Damit kann man grundsätzlich nichts falsch machen und es bietet mit PostGIS auch den von Sirius3 angesprochenen Geo-Index.
-
BlackJack
@meego: Im Tutorial wird es verwendet weil es bei Python schon dabei ist und sich jemand der das Tutorial durcharbeitet deshalb nicht noch extra eine grosse Datenbanksoftware installieren und konfigurieren muss.
So ganz grundsätzlich würde ich auch nicht sagen das SQLite nicht für Webanwendungen taugt. Man muss halt die Grenzen von dieser Datenbank kennen und es gibt auch Webanwendungen für die das dann ausreicht. Wenn es beispielsweise hauptsächlich Lesezugriffe gibt und nur wenige Schreibzugriffe die selten bis gar nicht parallel passieren, kann SQLite durchaus brauchbar sein. Also zum Beispiel eine dynamische Webseite bei der nur ein oder zwei Autoren ab und zu mal Daten einpflegen oder wo das zu festen Zeitpunkten automatisch geschieht. Ein kleines Blog, Terminkalender für eine Firma oder einen Verein, Messdaten die nach verschiedenen Kriterien dynamisch durchsucht werden können und nur einmal am Tag aktualisiert/ergänzt werden. Und natürlich auch für Prototypen wo man eine kleine Datenbank mit Beispieldaten braucht und nicht den kompletten Betrieb mit zig Besuchern gleichzeitig abbilden muss.
So ganz grundsätzlich würde ich auch nicht sagen das SQLite nicht für Webanwendungen taugt. Man muss halt die Grenzen von dieser Datenbank kennen und es gibt auch Webanwendungen für die das dann ausreicht. Wenn es beispielsweise hauptsächlich Lesezugriffe gibt und nur wenige Schreibzugriffe die selten bis gar nicht parallel passieren, kann SQLite durchaus brauchbar sein. Also zum Beispiel eine dynamische Webseite bei der nur ein oder zwei Autoren ab und zu mal Daten einpflegen oder wo das zu festen Zeitpunkten automatisch geschieht. Ein kleines Blog, Terminkalender für eine Firma oder einen Verein, Messdaten die nach verschiedenen Kriterien dynamisch durchsucht werden können und nur einmal am Tag aktualisiert/ergänzt werden. Und natürlich auch für Prototypen wo man eine kleine Datenbank mit Beispieldaten braucht und nicht den kompletten Betrieb mit zig Besuchern gleichzeitig abbilden muss.
-
BlackJack
@DasIch: Unveränderbar ja aber auch nur in dem Sinn dass es nicht so einfach geht wie bei anderen DBMS. Man muss halt die Tabelle umbenennen, eine neue Veränderte anlegen, und die Daten dann kopieren. Macht etwas mehr Arbeit.
Sicherlich kann man dies tun aber das kopieren kostet Zeit, Zeit in der die Datenbank nicht erreichbar ist. Das spielt bei kleinen Datenbanken vielleicht keine große Rolle aber Datenbanken haben die Tendenz größer zu werden und früher oder später stört es dann schon.
-
BlackJack
@DasIch: Naja für richtig grosse Datenbestände die wirklich ständig verfügbar sein müssen würde ich SQLite natürlich nicht verwenden. Und bei Datenbeständen die mit der Zeit grösser werden: Man muss dann ja nicht bei SQLite bleiben.
@DasIch: das schöne, wenn man ein ORM wie SQLAlchemy nimmt, ist ja, dass man einfach eine Datenbank austauschen kann. Man nimmt SQLite zur Entwicklung, und wenn man dann wirklich ein Produktivsystem mit x-tausend Anfragen pro Sekunde aufbaut, wechselt man zu einer dafür besser geeigneten Datenbank.