Entspannung in der Suppenkrise

Vor einer Weile schrieb ich über die Suppenkrise, die über Lüdenscheid hereinbrach, als der Asia-Markt schloß. Inzwischen hat sich die Situation mehr als entspannt. Es gibt nun gleich 2 Läden, die neben allerlei interessantem Ethnofood auch Ramen anbieten. Beide Läden finden sich in der Hochstraße oben in der Stadt und sind nichtmal 10m von einander entfernt. Das müßte doch zu einer ziemlich harten Konkurrenz führen. Ich werde jedenfalls auch mal die anderen (für mitteleuropäische Verhältnisse) exotischen Nahrungsmittel probieren. Mir stände der Sinn nach einem schönen scharfen Curry. Nur ein einfaches Rezept fehlt noch.

MS Access, pgsqlODBC und Booleans

pgsqlODBC macht in den Standardeinstellungen einige sehr sonderbare Sachen. Eine Spalte mit Booleans erscheint in MS Access als Textfeld. Das führt dann natürlich zu einigen Problemen mit Checkboxen. Access meint dann, das Feld wäre zu klein, um den Wert zu speichern. Dabei beherrscht MS Access Booleans. Man muß nur den pgsqlODBC-Treiber überzeugen, das ganze für MS Access verständlich zu präsentieren. Hierzu müssen nur 2 Optionen in der ODBC-Verbindung geändert werden. Die Optionen finden sich unter Datasource

  1. Bools as Char muß ausgeschaltet werden
  2. True is -1muß eingeschaltet werden

Verknüpft man die Tabellen nun (erneut), werden sie in MS Access auch korrekt als Ja/Nein angezeigt und können auch von Checkboxen verwendet werden.

Spielereien mit Rules und Check Constraints in PostgreSQL

Ich hatte heute das Problem, daß ich in der Datenbank Zeiträume (Start- und Enddatum) speichern mußte, in denen bestimmte Resourcen in Benutzung sind/sein werden. Eine Resource darf dabei zu einem bestimmten Zeitpunkt nicht mehrfach belegt werden. Ich mußte also sicherstellen, daß sich die Zeitbereiche einer Resource nicht überlappen.

Check Constrainst von PostgreSQL alleine hilft da leider nicht. Der kann nur auf Konsistenz innerhalb eines Datensatzen prüfen, z.B. ob das Startdatum vor dem Enddatum liegt. Soll geprüft werden, ob die neu einzufügenden Daten in irgendeiner Beziehung zu bereits vorhanden Daten stehen, so müssen Regeln (RULE) definiert werden. Dies sieht in meinem Beispiel so aus.

CREATE TABLE sometable (
	id				serial,
	start_date			date		NOT NULL,
	end_date			date		NOT NULL,
	resource			integer	NOT NULL,
	CHECK (start_date<=end_date)
);
CREATE RULE no_overlap_insert AS ON INSERT TO sometable
WHERE EXISTS (
	SELECT * FROM sometable
	WHERE ((( new.start_date>=start_date AND new.start_date<=end_date )
		OR ( new.end_date>=start_date AND new.end_date<=end_date ))
	  AND new.resource=resource)
)
DO INSTEAD NOTHING;

Hier habe ich also ein Check Constrainst, das prüft, ob das Startdatum auch wirklich vor dem Enddatum liegt sowie eine Regel, die verhindert, daß ich eine Resource zu einer Zeit mehrfach belege.

Unschön an dieser Lösung ist jedoch, daß der Check Constrainst einen Fehler hervorruft, wenn die Bedingung nicht erfüllt wird, während die Regel einfach still die Daten verwirft. Man kann also nur anhand der Anzahl der geänderten Datensätze, die nach jedem INSERT/UPDATE zurückgegeben wird, feststellen, ob die Daten erfolgreich gespeichert wurden. Hier wäre es natürlich angenehmer, wenn auch ein Fehler erzeugt würde.

Nicht im Beispiel enthalten ist eine zweite Regel, die verhindert, daß man bereits vorhandene Datensätze so ändert, daß es doch wieder zu Überlappungen kommt. Hierzu muß einfach eine zweite Regel (mit anderem Namen) erstellt werden, die statt ON INSERT ein ON UPDATE enthält.