Am Rande notiert ...

PostgreSQL: Documentation: 8.4: hstore. Aus der Reihe „Sachen die deine Datenbank kann, die du aber vielleicht nicht kennst“: Key-Value-Stores innerhalb eines PostgreSQL Datenfeldes. Oder auch poor-mans-object-notation. Oder einfach dann praktisch, wenn man lose strukturierte Daten ablegen will, aber nicht ständig das Schema anpassen will – das Schema sind dann die primären Daten für die Ordnung des Modells, die Abhängigkeiten, Kardinalitäten etc. – und das hstore Feld speichert dann die zusätzlichen Ausprägungen, die sich zum Beispiel durch fachliche Anforderungen dynamisch ergeben. Manchmal die bessere Alternative zu einer ausnormalisierten Property-Tabelle. Und das ganze ist schon seit den 8er Versionen drin (ist allerdings ein ladbares Modul).

Temporal Keys, Part 2 | Experimental Thoughts. Man lernt doch immer wieder was neues über PostgreSQL – diesmal PERIOD, ein Datentyp, der Zeitspannen umfasst, und EXCLUDES, eine weitere Form von Constraint auf Tabellen, mit denen sich zusammen mit PERIOD dann Überlappungen von Zeiträumen schon im Datendesign vermeiden lassen. Unter Dynamics AX gibt es sowas in Form der Date Effectivity, wobei das dann noch etwas weiter geht, weil auch automatisches Anlegen neuer Bereiche, Gap-Freiheit von Zeitleisten etc. abgebildet werden, wärend das hier nur die Grundlagen für überlappungsfreie Datensätze sind. Andererseits lässt sich das ja auch wesentlich breiter nutzen, da man beliebige EXCLUDES-Constraints formulieren kann.