Wie schon im MySQL-Manual so schön gefragt wird: "Ist MySQL pingelig hinsichtlich reservierter Wörter?" Gelegendlich (er-)findet man als Entwickler oder Datenbankdesigner Spaltennamen für Tabellen, die identisch zu einem MySQL Befehl oder Datentyp sind. So ist es zum Beispiel nicht sinnvoll einem Zahlenfeld in der Tabelle den Namen INT zu geben, da INT ebenfalls ein Datentyp ist. Wer unbedingt meint es trotzdem tun zu müssen, nutzt im Notfall eben die Backticks. So weit so klar. Manche Worte sind zwar reserviert, erzeugen aber nicht gleich einen Syntaxfehler beim CREATE TABLE bzw. sind in neueren MySQL Versionen zumeist auch neue Worte reserviert. Wie läßt sich das einfach prüfen?

Ein Freund fragte mich nach Konventionen für die Benennung von Tabellen bei der Entwicklung von Schemata für MySQL Datenbanken. Es begann damit, daß er mich fragte, wie man denn wohl eine Relation benennen soll, also eine Hilfstabelle, die zwei Tabellen in einer n:m-Beziehung miteinander verbindet.

In einem alten Job hatten wir die unten stehenden Regeln. Sie sind recht willkürlich und man kann sich anders entscheiden, aber wir hatten das so gemacht und es hat gut für uns funktioniert.

Jede Tabelle bekommt einen Namen in Kleinbuchstaben (oder der Server läuft mit lower_case_table_names = 1, was sowieso empfehlenswert ist). Der Name ist ein beschreibendes Wort im Singular. Auf diese Weise hat man weniger Schmerzen, wenn man über eine Query an einem Beispiel diskutiert. Zusätzlich wird für jede Tabelle ein eindeutiges Kürzel definiert.

Beispiel: Die Tabelle kunde bekommt das eindeutige Kürzel k.

Wir …

Sehr erfolgreich ging heute die DOAG Doppel SIG - Database zum Thema "Cloud Computing" und die erste DOAG Veranstaltung zum Thema "MySQL" zu Ende. Die Teilnehmer bewerteten die Vorträge sehr gut. Es gab viele sehr gute und interessante Vorträge.

Am Donnerstag, den 19. Mai 2011 findet in Hannover die DOAG SIG - Database zum Thema "Cloud Computing" und "MySQL" statt. Es gibt zwei parrallele Vortragsstreams, zwischen denen die Teilnehmer auswählen und pendeln können. Moderator ist der DOAG SIg - Leiter und ORACLE ACE Christian Trieb.

Mehr:
https://mydoag.doag.org/termine/termine.php?tid=413838

https://mydoag.doag.org/termine/termine.php?tid=423270

SQL ist lustig und manchmal fällt man richtig rein. Sei es nun bei MySQL oder anderen Datenbanken. Eben habe ich in einem Forum eine Frage gelesen, wie man am Besten den "letzten" Datensatz in einer Tabelle findet. Lösungen? Jede Menge, manche einfach und genial, andere wiederum perfekt geschaffen für einen unfreiwilligen "internen" DoS (Denial of Service) Angriff.

In diesem Seminar stellen wir Ihnen vor, welche Möglichkeiten Ihnen das Partner-Geschäft mit MySQL unter dem neuen Dach von Oracle bietet:

• Platzierung von MySQL innerhalb der Oracle Kundenbasis. Die kommerziellen MySQL Editionen sind nun in MyOracle Support integriert und MySQL Nutzer haben Zugriff auf die gleiche Support-Infrastruktur, wie sie Oracle Datenbank Kunden zur Verfügung steht.
• Ein attraktives Angebot für Microsoft Nutzer mit unserer Strategie und unseren Angeboten für MySQL auf Windows - einschließlich dem MySQL Installer für Windows, der die Installation von MySQL auf Windows erheblich vereinfacht sowie den neuen kommerziellen MySQL Editionen, die gerade auch Windows-Nutzern große Kosteneinsparungen bei ihren Web- und Unternehmensanwendungen ermöglichen.

In diesem Oracle Seminar lernen Sie die verschiedenen Möglichkeiten und Technologien kennen, die Ihnen für die Umsetzung von hochverfügbaren und äußerst skalierbaren MySQL Infrastrukturen zur Verfügung stehen. Wir stellen Ihnen zusätzlich bewährte Architekturen vor.

Ich selbst nutze unter anderem PowerDNS als DNS-Server. Im letzten Monat betrachtete ich mir dessen MySQL-Backend, da ich über zwei Kanäle darüber informiert wurde, dass PowerDNS mit dem Backend nicht skaliert.

Die DNS-Records werden in PowerDNS in zwei Tabellen abgelegt. Eine für die Domains:

create table domains (
id INT auto_increment,
name VARCHAR(255) NOT NULL,
master VARCHAR(128) DEFAULT NULL,
last_check INT DEFAULT NULL,
type VARCHAR(6) NOT NULL,
notified_serial INT DEFAULT NULL,
account VARCHAR(40) DEFAULT NULL,
primary key (id)
) Engine=InnoDB;

Und eine weitere für die Records:

CREATE TABLE records (
id int(11) NOT NULL auto_increment,
domain_id int(11) NOT NULL,
name varchar(255) NOT NULL,
type varchar(10) NOT NULL,
content varchar(255) NOT NULL,
ttl …

Mit MariaDB 5.3 wird ein neuer ColumnType Einzug halten. Das sogenannte Dynamic Column. Die Idee ist gewisse Vorgehensweisen, welche aus den DocumentStore-Lösungen (z.B. MongoDB) bekannt sind zu erfüllen. Ob man das wirklich will, liegt nicht an mir zu entscheiden. Doch sei folgender Link dem geneigten Leser nahe gelegt.
Die Idee ist denkbar einfach: In der Tabelle wird eine BLOB-Spalte verwendet um darin die dynamischen Element zu verwalten.
Es sei erwähnt, dass zum Nachspielen  https://code.launchpad.net/~maria-captains/maria/5.3-mwl34 zu verwenden ist.

MariaDB [test]> SELECT VERSION();
+---------------------+
| VERSION()           |
+---------------------+
| 5.3.0-MariaDB-alpha |
+---------------------+ …

MySQL hat bisher nicht den besten Ruf was die Performance von Stored Procedures angeht. Bereits 2008 war dies ein Thema in einem Blogeintrag[1]. Darin wurde die Fibonacci Formel[2] mit einer Stored Function nachgebildet. Das Ergebnis war: PHP ist mit einer ähnlichen Funktion 10x schneller als die MySQL Stored Function. Hat MySQL inzwischen nachbessern können? UPDATE 03.05.2011