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
Isotopp> Drive from SQL Airport to Oracle Corp HQ via Twin Dolphin Drive. Fuck, Yeah!
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 …
[Mehr]kikkay> An SQL query walks into a bar and sees two tables.
kikkay> He walks up to them and says “Mind if I join you?”
In BASE - An ACID Alternative fanden sich ja schon Links auf den Artikel von Dan Pritchett und den von Werner Vogels. Einen Folgeartikel gibt es bei Eventually Consistent - Revisited. Den Artikel muß man lesen, indem man ein synchrones Replikationssystem (eigentlich ein Two Phase Commit-System, denn nur das hat ACID-Eigenschaften) einem asynchronen Replikationssystem (etwa das MySQL Replikationssystem oder jedes Message Queue System) mental gegenüberstellt und in den Klassifikationen des Artikels bewertet.
Man kann sehen, daß beide Ideen Extrempunkte in einem Spektrum von Möglichkeiten sind, und daß beide Ideen am Ende zu einem stabilen …
[Mehr]Aus der ACM Queue schreibt uns Dan Pritchett (eBay) "BASE - An ACID Alternative":
In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.
(via hohjg)
Daß RAM eine Feine Sache (tm) ist, wenn man eine Datenbank betreiben will, ist ja der Kern vieler meiner Ausführungen zu diesem Thema. Daß Flash kein "RAM" im engeren Sinne ist, wird dabei gerne einmal überhört - Flash Disks stinken aber generell ab, wenn sie beschrieben werden und noch mehr, wenn sie mit Random I/O beschrieben werden. Selbst etwas so langsames und mechanisches wie eine traditionelle Festplatte gewinnt hier. Was man stattdessen will ist RAM mit Batterie.
Nun gibt es auch Spezialisten, die sich ein Notebook mit Flash statt Harddisk haben aufschwatzen lassen, denn immerhin kann Flash nicht durch Fall-Schock kaputt gehen und außerdem braucht es weniger Strom. Braucht es wohl, denn Daten auf ein Flash zu braten frißt nun einmal Leistung.
Der Fotodienst Flickr wurde vor 5 Jahren in Betrieb genommen. Am
29. Dezember wurde das Foto 2147483647 auf Flickr hochgeladen. Diese
Zahl ist 2 hoch 31 minus 1, also MAXINT für einen 32 Bit Signed
Integer. Dies hat zu einem Integer Overflow
in einer Bibliothek geführt, die Signed Integer als ID für
Flickr-Bilder verwendet hat.
Hier sind ein paar simple Abfragen von INFORMATION_SCHEMA, mit
denen man offensichtliche Designdummheiten bei Datenbankschemata
finden kann:
CODE:mysql> select table_schema, table_name, column_name, column_type
from information_schema.columns
where table_schema not in ("information_schema", "mysql") …
Bug #31876: Neulich war ich bei einem Kunden, der
ein kleines Testscript hatte, das im wesentlichen 500 mal
hintereinander eine Row in eine InnoDB-Tabelle eingefuegt hat und
dann ein Commit gesendet hat. Das Script war unter Linux
unmöglich schnell, und unter Windows unmöglich langsam -
insbesondere war es unter Windows viermal langsamer als dasselbe
Script unter DB/2 und MS SQL Server. Das ist natürlich verdächtig
und nicht akzeptabel.
"Bug #31876: MySQL Commit in Windows" vollständig
lesen
18. Oktober: MySQL Central Europe Customer Conference, München
(Programm) in Deutscher Sprache.
Das Programm läuft auch noch am 16. Oktober in London und am 20. Oktober in Paris.