datenbank

wiki.dbpedia.org : About. Auch interessant - hier wird die Wikipedia durchforstet und nach strukturierten Informationen ausgewertet. Also sozusagen aus der Wikipedia für Menschen eine Wikipedia für Maschinen gemacht. Dem ganzen vorgepackt ist dann eine Abfragesprache und ein passender Webservice.

GT.M. Und weil ich dabei bin, hier gleich die dritte open source Mumps Implementierung. Die hier war mal kommerziell und ist dann in 2000 frei geworden. Hat also einiges auf dem Puckel an Jahren und ist nicht so ein Bastelprojekt von irgendwelchen Enthusiasten, sondern wird durchaus kommerziell weiterbetrieben (z.B. für Lizenzen auf anderen Systemen als Linux und OpenVMS). Wenn man sich so die Beschreibung durchliest, dann haben sie gleich mit der ganzen Sammlung von Buzzwords nach dem Tool geworfen. Ok, bei einer Sprache die ihre Datenbank einfach als globale Variablen in die Programme mapped ist STM ja sozusagen schon eingebaut. Auch wenn das vielleicht etwas gemogelt ist.

mumps. Ja, noch eine Implementierung, die scheint sogar einiges der altertümlichen Jobcontrols und anderer obskurer Artefakte zu implementieren. Naja, seit NoSQL wird wahrscheinlich auch Mumps wieder hoffähig. Die hier muss man allerdings selber kompilieren, da sind keine Binaries direkt für OSX verfügbar.

Mumps/II MultiDimensional and Hierarchical Toolkit. Ja, ich bin mal wieder in Sachen absurder Programmiersprachen unterwegs und hab hier ein Mumps aufgestöbert, das open source ist und unter verschiedenen Systemen läuft. Keine Ahnung was ich damit machen werde, aber irgendwas schmerzhaftes wird es sein müssen.

storm-gen - Lightweight DAO generator for Android SQLite - Google Project Hosting. Hmm, könnte ich mir mal angucken, ein weiterer ORM für SQLite unter Android.

The SQLite RTree Module. Und noch eine Erweiterung für SQLite, diese hier eine Standarderweiterung. R-Trees sind Baumstrukturen die optimiert sind für Range-Abfragen - also Wertebereichabfragen wie z.B. "ist dieses gegebene Rechteck in der Liste der Rechtecke enthalten".

The Gaia-SINS federated project home-page. Nur schnell markiert, falls ich es mal brauchen könnte - spatiale Daten (GIS-Daten) in SQLite mit einer Erweiterung effizient indizieren und abfragen können. Da ich erklärter Fan von SQLite bin, durchaus interessant. Und es ist als dynamisch ladbare Erweiterung realisiert (tuts natürlich nur wenn das SQLite das man benutzt auch für Erweiterungen freigeschaltet ist - leider oft nicht der Fall, Installation könnte also eigene Neukompilation von SQLite erfordern, aber so schrecklich ist das nicht).

ActiveAndroid | Active record style SQLite persistence for Android. Hmm, mal angucken - ein weiterer ORM für Android, aber einer mit recht interessanter Syntax. Der Source verspricht auch noch ein paar mehr Sachen wie z.B. Joins. Wenn dann auch noch Migrations brauchbar abgebildet werden (daran krankt es erschreckend oft), könnte mich das Projekt durchaus motivieren mal mein kleines Bastelprojekt umzustellen.

couchbase/Android-Couchbase. Als Alternative zu SQLite unter Umständen interessant - vor allem, wenn man weniger mit strukturierten Daten sondern mehr mit Dokumenten arbeitet. Denn CouchDB bietet da echte Vorteile. Zusätzlich bekommt man damit eine Sync-Infrastruktur zur automatischen Replikation von Datenbankänderungen auf einen zentralen Server. Und zwar ohne wie bei SQLite Lösungen dafür Textexporte mit Dropbox-Sync zu bauen. Wobei letzteres erstaunlich gut funktioniert in den Situationen in denen ich das brauche.

Postgres-XC project Page. Multi-Master (Read und Write) Cluster für PostgreSQL. Unterstützt replicated Setups genauso wie partitioned Setups (oder Mischformen).

mitmel/SimpleContentProvider. Sieht aus wie ein einfacher ORM der automatisch einen Android Content Provider generiert. Dadurch wird das Erstellen deutlich schlanker im Code.

OrmLite - Lightweight Object Relational Mapping ORM Java Package. Mal genauer angucken, ein ORM der auch in Android benutzbar ist. Die nackte Programmierung von SQLite mit SQLiteDatabaseHelper macht mir irgendwie nicht so richtig viel Spaß. Das ist mir dann doch etwas zu low-level.

SQLite4: The Design Of SQLite4. Das klingt sehr interessant. Besonders der erste Absatz in "2.0 Overview", in dem er ein wenig darauf rumreitet, dass SQLite3 weiter unterstützt wird und beide Versionen parallel verfügbar bleiben. Und natürlich dann die diversen Änderungen, die SQLite4 gegenüber der anderen Version haben wird, wie zum Beispiel die deutlich bessere Kapselung der Engine in einem eigenen Objekt. Dadurch ist es durchaus möglich mehrere Datenbanken gleichzeitig offen zu haben, ohne großes jonglieren. Und was mich besonders freut: alle Berechnungen in Decimal Math und nicht mehr double oder float. Sorry, aber double (und schon gar nicht float) hat irgendwas in einer Datenbank zu suchen, ausser vielleicht als Datentyp für seltene Sonderfälle. Auch sonst einige nette Sachen drin, zum Beispiel covering indexes und natürlich die standardmäßig verfügbaren foreign key constraints.

Make runfcgi fail when database connection is open before fork. Das ist eine Sache nach der ich schon ewige Zeiten jage, zuletzt in ein paar ziemlich wichtigen Projekten. Flup arbeitet so, dass es die WSGI-Anwendung erst initialisiert und mit dieser initialisierten WSGI Anwendung dann die Forks für die Worker macht. Dummerweise gibt es bei uns aber Datenbankzugriffe wärend der Anwendungsinitialisierung - dadurch hat der Basisprozess schon eine offene Datenbankverbindung, jeder Fork kopiert diese Daten. Aber der Socket der Verbindung geht natürlich nicht mit - der neue Prozess denkt nur er wäre verbunden, ist es aber nicht. Zugriffe von denen neuen Prozessen fallen dann mit einer Exception raus. Man kann im verlinkten Patch auch gut den raise auf die Exception einfach durch connection.connection = None ersetzen. Dann wird einfach die Verbindung die sowieso defekt ist weggeworfen und in neuen Prozessen immer eine neue Verbindung aufgebaut. Damit haben wir zumindestens in einem Produktionsumfeld (mit psycopg2) das ganze beheben können und sind guten Mutes, dass es auch bei der Umgebung mit pyodbc helfen wird.

SET TRANSACTION ISOLATION LEVEL Transact-SQL. Da gibts mehr Infos zum Isolation-Level in MSSQL, speziell was die Snapshot-Geschichte bedeutet. Im Prinzip bringt man MSSQL damit dazu sich ähnlich zu PostgreSQL zu verhalten.

Enabling Snapshot Isolation - SQLAlchemy 0.7 Documentation. Könnte uns das helfen? MSSQL hat scheinbar einen eher ungünstigen Isolation-Level als Default. Hmm, werden wir wohl mal ausprobieren.

r17 - flexible, scalable, relational data mining language. Sieht ganz interessant aus, im Prinzip sowas wie eine Kreuzung aus AWK und SQL. Das Ergebnis ist nicht wirklich schön, aber wirkt praktisch - speziell weil man auf einfache Weise mehrere Prozessoren nutzen kann, oder sogar mehrere Maschinen (implizite Parallelisierung), und damit auch recht einfach große Datenmengen mit ad-hoc Queries auswerten kann. Dadurch, dass es ein einfaches Format für die Übermittlung von daten an weitere Schritte gibt, kann man es auch leicht auf neue Datenquellen anpassen, ohne dort erst einen langwierigen Exportschritt laufen zu lassen.

The Schemaverse. Und weil wir gerade bei seltsamen Projekten sind: da hat jemand ein MMO programmiert, das komplett innerhalb PostgreSQL läuft. Also pgSQL als Sprache benutzt. Sowas wie ein Multi-User-Schiffeversenken. Nur läuft es halt in einer Datenbank. Und wird über SQL bedient.

RavenDB - 2nd generation document database. Geblogmarkt weil ich mir das mal in der nicht zu fernen Zukunft angucken will. Klingt von den Features her recht interessant und ist vielleicht für das eine oder andere Projekt, über das ich zur Zeit nachdenke, brauchbar.

TL Omnis. Und noch so ein RAD Oldtimer - Omnis war eine der ersten RAD Umgebungen mit der ich gespielt habe und sie war recht ungewöhnlich für die damalige Zeit. Keine "richtige" Programmierung damals, nur GUI Tools zur Verdrahtung und Verbindung in Kombination mit berechneten Feldern, aber diese sehr leistungsfähig. Sehr starker Fokus auf grafische Werkzeuge für verschiedenste Zwecke (DB Design, Relationsmanagement, Reports, Formulare etc.). Schon erstaunlich was man alles findet, wenn man etwas nachbuddelt. Gibt übrigens eine freie Standardversion der Umgebung, man kann also einfach mal reingucken was es heute so alles kann.

Bulbflow: a New Python Framework for Graph Databases. Auch wenn ich immer wieder denke, Graphdatenbanken sind eigentlich sowas von 70er Jahre, nicht alles was alt ist ist automatisch schlecht - IMS ist ja auch immer noch da und für manche Zwecke sehr interessant. Und das hier klingt interessant, sowas wie DBAPI für Graphdatenbanken, so dass man in seinen Projekten auch mal die Datenbank wechseln kann, ohne das alles komplett umgeschrieben werden muss.

NOSQL Databases. Sehr gute Übersicht über alle möglichen verfügbaren NoSQL-Datenbanken. Guter Startpunkt wenn man sich über die verfügbaren Systeme und deren Ausrichtung und Implementierung infomieren will.

Write-Ahead Logging - in SQLite! Ab Version 3.7. Das ist sehr interessant, weil damit ein Anwendungsfall einfacher wird - multicore-nutzende Applikationen, die mit einer embedded Datenbank arbeiten wollen. SQLite wird damit noch mehr zum Schweizer Messer der Datenspeicherung (und wenn man beim Programmieren darauf Rücksicht nimmt, ist der Wechsel zu PostgreSQL für größere Installationen wo die embedded Datenbank keinen Sinn mehr macht einfach lösbar).

Oracle Announces Latest Release of Oracle® Berkeley DB - Berkeley DB hat jetzt ein auf SQLite aufbauendes SQL API. Kompatibilität auf Sourcecode-Ebene mit SQLite, Programmierer können also - wenn sie den deutlich instabileren und anfälligeren Storage von Berkeley DB bevorzugen und gerne mal ihre Datenbanken reparieren wollen - wechseln. Sorry, Oracle, aber das ist affig. BDB ist eigentlich nur noch für die interessant, die gezwungenermaßen damit arbeiten müssen - wer heute noch auf BDB wechseln will, müsste mit dem Nagelbeutel gepudert sein. Wenn ich sowieso gegen das SQLite API programmiere, dann nehme ich lieber gleich das richtige Tool. Ja, klar, SQLite hat einige Engpässe wenn man mit mehreren Prozessen parallel zugreifen will. Aber ich verrate Oracle hier mal ein kleines Geheimnis: SQLite hat einen so toleranten SQL Parser, weil man dann damit problemlos Source schreiben kann, dessen SQL sowohl gegen SQLite als auch gegen PostgreSQL funktioniert. Wenn man also an die Grenzen von SQLite stößt - einfach auf PostgreSQL wechseln und gut ist.

inessential.com: On switching away from Core Data - scary read. Wirklich - klar, ORMs sind nett. Und praktisch. Aber irgendwie erschreckt es mich, wenn Programmierer wie Brent Simmons (der NetNewswire Guy) so offen demonstrieren, dass sie eigentlich keinen Plan haben was sie da tun. Nur weil man einen ORM benutzt durch Listen von Objekten wandern und einzelne Objekte bearbeiten und sich dann über miese Performance wundern? Und erst am Ende der Optimiersessions mal die Frage stellen, ob eine ORDB tatsächlich der richtige Weg ist? Hallo, gehts noch? Sobald Massendaten im Einsatz sind, steht automatisch die Frage nach Massendatenbehandlung im Raum und wenn der ORM da keine brauchbaren Abstraktionen liefert, dann fliegt er raus ... (ein Grund warum ich den Django-ORM mag, er kooperiert gut mit handgedengeltem SQL und bietet per Introspection eine Menge Hilfsmittel um auch diese eigenen SQLs möglichst Modell-abstrakt zu erstellen). Für mich liegt jedenfalls der verlinkte Post auf einem ähnlichen Level wie Guido van Rossums "wofür benutzt man denn eigentlich Continuations, ich kapier das nicht".

SQLiteJDBC - noch ein JDBC Treiber für SQLite

SQLiteJDBC - weil ich ein SQLite Fan bin (wenns zu komplex für simple Textfiles ist, ist SQLite die nächsthöhere Stufe), und weil ich mit Scala und Clojure rumspiele, könnte ich das hier mal brauchen.

What happened to Hot Standby? - echte native Synchronisation kommt für PostgreSQL 8.5! Gibt schon bestehende Lösungen, aber native ist natürlich einfacher für die Administration. Und sollte endlich die albernen Diskussionen mit den MySQL-Jüngern verkürzen.

Postgres-R: a database replication system for PostgreSQL - mal angucken?

Hyper Estraier: a full-text search system for communities - Volltextdatenbank mit Attributsuche und einigen anderen netten Eigenschaften - sowie Bindings für verschiedene Programmiersprachen

The Xapian Project - noch ein Volltext-Indexer, dieser mit diversen weitergehenden Features wie z.B. Stemming für verschiedene Sprachen.

SQLAlchemy README - ein weiterer ORM für Python, orientiert sich stark an SQL und bietet einiges an magischer Syntax. Faszinierend, wie gerade in diesem Bereich die Programmierer jedes Sprachfeature versuchen zu missbrauchen nur um nicht SQL schreiben zu müssen ...

Dejavu - Trac - ein weiterer Object-Relational-Mapper für Python. Klingt aber in Punkten ganz interessant.