35. Wispri: Hochskalierbare Datenbanken mit MongoDB

In den letzten Jahren formiert sich eine immer größere Entwickler-Gruppe rund um den „NoSQL“-Hype. Hier wird versucht, von den traditionellen relationalen Datenbanken weg zu dokumentorienteren und schemalosen Datenbanken zu gehen.

MongoDB (der Name kommt von humongous (dt.: gigantisch)) ist der momentan wohl populärste Vertreter dieser neuen Art von Datenbanken. Sie sind hochskalierbar (horizontal und vertikal), sehr leichtgewichtig und im Falle von MongoDB auch OpenSource.

Wir zeigen die Vor- und Nachteile von MongoDB im Vergleich zu relationalen Datenbanken, einige Tips und Tricks, die nicht so leicht online zu finden sind, und wie wir MongoDB in unseren Projekten einsetzen.

Vorheriger Beitrag
34. Wispri: Programmierwettbewerbe – Fit mach mit!
Nächster Beitrag
36. Wispri: Vom 3D EgoShooter zum Super-Computer

Related Posts

5. Wispri: Die verlorene Einfachheit

Der typische Produkt-Entwickler kennt den Endbenutzer normalerweise nicht. Deshalb werden Produkte nach persönlichen Vorstellungen gestaltet und bestmöglich umgesetzt. Dass das nicht zur angestrebten einfachen Bedienbarkeit führen kann, zeigt die Wissensspritze humorvoll am Beispiel Mikrowelle.
Dabei geht es um die Frage wie man Fehlentwicklungen anhand einer kleinen Zielgruppe für die große Masse an Nutzern entwickeln kann. Und wie eine solche „Persona“ hilft, ein Produkt zu entwirren.

Weiterlesen

6. Wispri: Fragen als Projektkatalysator

Das war alles nur ein Missverständnis – aber wie hätte man es vermeiden können? Ganz einfach: Eine simple Frage hätte ausgereicht! Überhaupt sind Fragen ein bislang viel zu selten genutzter Motor im Entwicklungsprozess.

Unsere Wissensspritze belegt gleich zu Beginn auf eindrucksvolle Weise die „Macht der Fragen“. Im Anschluss werden Fragetechniken vorgestellt und über unsere Erfahrungen mit Lateralen in Software-Entwicklungsprojekten berichtet.

Weiterlesen

15. Wispri: Automatische Prüfungen im Build-Prozess

Diese Wissensspritze befasst sich damit, wie man automatisch die Testabdeckung ermitteln kann (zur Steuerung der Testaufwände), wie man statische Code-Analysen durchfhren kann (zur Identifikation von Fehlern und zur Steuerung des Refactoring), wie man Architektur-Verletzungen erkennen kann (zur Korrektur von Fehlern bzw. zur Verbesserung der Architektur). Wir besprechen, welche Werkzeuge es für diese Zwecke gibt.

Weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren

Menü