Ich lese gerade SQLite Foreign Key Support und ich muß sagen, ich kann mir ein leichtes Grinsen nicht verkneifen.

Also, ich finds ja gut, daß SQLite die Option für Foreign Key Constraints implementiert und ich finds sogar noch besser, daß mit DEFERRABLE INITIALLY DEFERRED sogar die einzig sinnvolle Weise das zu tun bereitgestellt wird, aber ich frag mich schon, wozu das gut sein soll.

"Ein paar Gedanken zu Foreign Key Constraints" vollständig lesen

Letzte Woche Montag haben wir beschlossen, den SQL_MODE in unseren Entwicklungsservern auf einen strengeren Wert als "" (den Default) zu setzen. Das war ein Fehlschlag und wir haben den Change diese Woche zurück gerollt. Aber von vorne.

Welchen SQL_MODE will man denn?

Als Ziel-Einstellung haben wir eine Kombination von

TRADITIONAL,
NO_ENGINE_SUBSTITUTION,
ONLY_FULL_GROUP_BY,
NO_AUTO_VALUE_ON_ZERO

ins Auge gefaßt.

SQL_MODE ist eine Einstellung in MySQL, mit der das Verhalten des Servers beeinflußt werden kann. Die Variable ist eine Bitmaske von benannten Bits - jedes Bit hat eine im Handbuch definierte Bedeutung. Außerdem haben bestimmte Kombinationen von Bits einen Sammelnamen.
…

Ein paar Leute hatten mich gebeten, diese Daten zu posten, sobald ich sie habe:

CODE:14:26:35 root@demodb-01:~ 4# grep proc /proc/cpuinfo

processor       : 0

processor       : 1

processor       : 2

processor       : 3

processor       : 4

processor       : 5

processor       : 6

processor       : 7

14:26:36 root@demodb-01:~ 5# free -m

…

We have a new Alpha release for MySQL 6.x

MySQL 6.0.9-alpha, a new version of the MySQL database system has been released. The main page for MySQL 6.0 release is at

• http://www.mysql.com/mysql60/

MySQL 6.0 includes two new storage engines: the transactional Falcon engine, and the crash-safe Maria engine.

If you are new to the Falcon storage engine and need more information, please read the Falcon Evaluation Guide at

• http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php

and the Falcon White Paper at

• …

Isotopp> Drive from SQL Airport to Oracle Corp HQ via Twin Dolphin Drive. Fuck, Yeah!

(SQL Airport)

Der Slideset zu 'MySQL in großen Umgebungen', den ich gerade auf der Open Source Datacenter Conference gezeigt habe, ist nun online. Interessanter als die Slides ist wie immer das gesprochene Wort, und das gibt es wohl von dieser Konferenz auch als Video zum runterladen. Sobald ich die URL habe, stelle ich sie hier dazu.

miracee> Ich reise niiiiiieee wieder in die USA.

miracee> Jedesmal, wenn ich rüber fliege, wird meine Firma verkauft :(

-- Mira (MySQL Sun Oracle)

Nun ist es also passiert: Oracle kauft Sun und hat sich damit auch den stets lästigen Störenfried im Datenbankmarkt MySQL ins Portfolio geholt.

In den Jahren vor der Übernahme von MySQL durch Sun war ja immer mal wieder spekuliert worden, dass Oracle den Datenbankkonkurrenten schlucken könnte – es war dann nur der Hersteller der von MySQL favorisierten Storage Engine InnoDB, aber das Signal machte viele MySQL User und Developer bereits nervös.

Nicht ganz zu Unrecht: Nun geht MySQL, wenn auch über Umwege, also doch zu Oracle. Stellt sich die Frage, was man nun für eine Strategie verfolgen wird. MySQL vom Markt nehmen wäre sinnlos – zu gross ist die Marktdurchdringung. Eine allzu stiefmütterliche Behandlung des Platzhirsches bei Open Source Datenbanksoftware würde meines Erachtens binnen kurzer Zeit zu einem Fork führen (bemerkenswerterweise ist Drizzle ist ja auch kurz nach dem Verkauf an Sun ins Leben gerufen …

Nun ist Sun gekauft worden, und zwar weder von IBM noch von Cisco, sondern von Oracle. Also fragen sich alle - was wird mit MySQL?

Zunächst einmal gehören jetzt MySQL und InnoDB zur selben Firma. Oracle hat InnoDB seit dem Kauf recht gut gewartet und das kann jetzt ja nur noch besser werden.

Wird Oracle MySQL absterben lassen und versuchen, seine eigenen Produkte in den Markt zu drücken? Nein. Wieso sollte Oracle das tun, und vor allen Dingen - welche eigenen Produkte denn?

"Sun, IBM, Cisco, Oracle" vollständig lesen

Aus einer Diskussion in der deutschsprachigen MySQL Gruppe im USENET. Dort ging es um die Frage, warum phpMyAdmin ein eingeschränktes Werkzeug ist und bei vielen Helfern im Netz unbeliebt. Meine Antwort lautete so:

phpMyAdmin unterliegt wie auch viele grafische Werkzeuge für MySQL (darunter auch jene, die von MySQL selbst bereitgestellt werden) einigen besonderen Einschränkungen. Diese sind prinzipbedingt und daher auch nicht leicht zu beheben.

Aber von vorne:

In MySQL ist es so, daß die Connection einen besonderen Kontext oder Scope darstellt. Mindestens die folgenden Dinge sind mit dem Scope der Connection definiert:

• Transaktionen. Ein Disconnect entspricht einen ROLLBACK.
• Transaktionen können mit SELECT ... FOR UPDATE oder LOCK TABLES auch Locks erzeugen. Diese sind bei einem Disconnect wieder weg.
• Die mit LAST_INSERT_ID() abrufbare zuletzt von auto_increment vergebene ID …