In einem Projekt stand ich vor dem Problem, dass über eine API verschiedene Clients auf die gleichen Tabellen zugreifen. Damit die Tabellen sauber bleiben, darf allerdings immer nur ein Client gleichzeitig schreibende Operationen ausführen. 

Auch muss es weiterhin möglich sein, dass interne Scripte die Tabellen lesen und schreiben dürfen. LOCK TABLES kommt dadurch also nicht in Frage.

Die einfachste Lösung war eine Tabelle mit zwei Spalten. Einem Identifier und dem Status. Der Identifier muss dabei natürlich einzigartig (UNIQUE) sein. Außerdem darf in der Tabelle nur ein Datensatz gleichzeitig den Status 1 (gesperrt) haben.

Folgendes Query führt dann alle nötigen Prüfungen und Aktionen aus:

INSERT INTO LockTable
   (name, status, createdBy, creationTime) 
SELECT 
   '$name', '$lock_status', '11', NOW() 
FROM 
   LockTable 
WHERE 
   '1' NOT IN (
      SELECT  
         status  
      FROM  
         LockTable  
      WHERE  
         status = '1'
   ) OR 
   '$lock_status'='0'
ON DUPLICATE KEY UPDATE 
   status = '$lock_status', 
   lastModifiedBy='1', 
   lastModifiedTime=NOW()

Das Query führt drei Aktionen auf einen Rutsch aus:

• Ist für $name kein Datensatz vorhanden, wird dieser erstellt.
• Ein Datensatz wird nur gesperrt, wenn es keinen anderen gibt, der gesperrt (auf 1 gesetzt) ist.
• Existiert bereit ein Datensatz für $name, wird dieser aktualisiert.

Würde man diese Aktionen nun in einzelne Querys aufteilen, bestünde die Gefahr, dass sich zwischen SELECT und INSERT/UPDATE eine weitere Verbindung zwischen schaltet und sich dort als gesperrt markiert. Im schlimmsten Fall wären dann zwei Verbindungen gleichzeitig gesperrt.

In der Anwendung kann man dann über den Affected Rows Zähler (der muss >0 sein) sehen, ob die sperre erfolgreich gesetzt wurde.

Wichtig: In der Tabelle muss sich IMMER mindestens ein Datensatz befinden. Ansonsten funktioniert das erste Select, welches die Daten für den Insert zusammenbaut nicht!

Ein Datenbank Layout welches mit DBDesigner4 entwickelt wird, soll mit einigen Optionen importiert werden.

Da DBDesigner allerdings bei jedem Export die komplette SQL File überschreibt, müsste man bei jedem Export die Befehle erneut in das SQL File tippen. Hierfür stellt MySQL den Befehl source zur Verfügung.

Es lassen sich also über die MySQL Kommandozeile SQL Files importieren. So kann man auch mehrere Dumps miteinander verketten.

mydb_import.sql

drop database if exists mydb;
create database mydb;
use mydb;
SET foreign_key_checks = 0;

source mydbscheme.sql;

SET foreign_key_checks = 1;

mydbscheme.sql

CREATE TABLE groups (
  group_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  group_name INTEGER UNSIGNED NULL,
  group_description TEXT NULL,
  group_active ENUM('Y', 'N') NULL DEFAULT 'N',
  PRIMARY KEY(group_id)
)
TYPE=InnoDB;

Erspart eine Menge Zeit während der Entwicklung des Datenbank Layouts.

Möchte man DBDesigner4 unter Ubuntu 10.04 starten, bekommt man die Meldung an den Kopf geknallt, dass die Libary libborqt fehlt.

Abhilfe schafft das Sourceforge Projekt Kylix Libs Packaging. Die entpackt man einfach in /usr/lib. Unter Umständen muss man noch einen Link erstellen, damit der Dateiname auch stimmt. Danach sollte es funktionieren.

Have fun.

 Bei einem Projekt habe ich festgestellt das bei einem varchar gar nicht auf Groß- und Kleinschreibung geachtet wird. Definiert man Beispielsweise einen natürlichen Primärschlüssel und verwendet dabei MySQL und mysql jeweils als einen Schlüssel, wird es beim Anlegen von mysql Fehler hageln.

Wie man dies ändern kann, ist in der Dokumentation von MySQL beschrieben. Man muss nur eine spezielle Collation verwenden. Nutzt man normal latin1_general_ci, nutzt man in dem Fall einfach latin1_bin.

⇒ http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html ⇐

Und schon sollte es Funktionieren.

 Bei einem größeren MySQL Projekt mit InnoDB und Referenzierung gab es einige Probleme, die ich hier einmal klären möchte. Vielleicht hilft es dem einen oder anderen ja weiter.

Zirkuläre Referenz

Diese Fehlermeldung warf mir DBDesigner4 an den Kopf, als ich versuchte den SQL Code zu exportieren. Dieser Fehler tritt auf wenn man den Haken Order Tables by Foreign Key drin lässt, und gleichzeitig zwei Tabellen hat die gegenseitig auf einander verweisen.

Beim Export kann man dieses Problem durch das Entfernen des Hakens umgehen. Allerdings nicht beim Import in den MySQL Server. Dort würde immer die Meldung erscheinen, dass die Referenzierte Tabelle vermisst wird. Das kann man mit einem SQL Befehl aber auch umgehen.

SET foreign_key_checks = 0;

Dadurch wird die Überprüfung der Referenzen temporär deaktiviert und alle Tabellen können angelegt werden. Ist das Anlegen abgeschlossen, sollte dies unbedingt wieder aktiviert werden. Ansonsten können Inkonsistenzen in der Datenbank die Folge sein.

MySQL Error Number 1005 Can’t create table

Hier gibt es viele Ursachen. Eine Liste von Ursachen gibt es im Blog VerySimple (thx!). Die Fehlermeldung enthält immer eine errno. Diese Error-Nummer kann man mit folgendem Befehl "lesbar" machen:

perror 150

Unter Linux befindet sich das Programm in $PATH und kann direkt im Terminal ausgeführt werden. Unter Windows müsste man evtl erst in das bin/ - Verzeichnis von MySQL wechseln.

Der Fehlercode 150 erzeugt die Fehlermeldung Foreign key constraint is incorrectly formed. Diese wurde durch einen FK ausgelöst, der kein NULL zuließ. Kurz das NOT NULL aus dem SQL Code entfernt und schon ging es.

Heute habe ich versucht, dass Datadir von einem MySQL Server zu ändern. Also der Ordner, wo die Binärdateien der Datenbanken gespeichert werden.

Nur irgendwie konnte man einstellen was man wollte. Es passierte einfach nichts!

Normalerweise sollte es reichen, in der Datei /etc/my.cnf die Option datadir anzupassen. Nur hat Arch Linux da wieder ein paar Extrawürste eingebaut. Der Datadir Pfad wird in drei verschiedenen Dateien hinterlegt.

• /etc/my.cnf
• /etc/rc.d/mysqld
• /etc/conf.d/mysqld

In den beiden anderen Dateien gibt es jeweils eine Variable die angepasst werden muss. Danach muss nur noch der MySQL Service neugestartet werden.

Beim kopieren der Binären Dateien muss unbedingt darauf geachtet werden, dass sich Besitzer und Gruppe, sowie die Zugriffsrechte nicht ändern!

Ansonsten startet der MySQL Dienst nicht mehr!

Manchmal hat man das Problem beim speichern von Einstellungen in der Datenbank, dass vorher überprüft werden muss, ob es diesen Datensatz nicht schon gibt.

Genau vor so einem Problem stand ich bei meiner Rechteverwaltung. Die Rechte werden dort mit Checkboxen gesetzt. Nun wollte ich bearbeiten und neu erstellen aber nicht getrennt Programmieren, sondern auf einem Rutsch.

Das bedeutet, man müsste erst prüfen, ob nicht schon ein Datensatz existiert. Es gibt dort zwei Möglichkeiten, ein weiteres Query zu vermeiden.
 

Möglichkeit 1: ON DUPLICATE KEY
Die erste, und eigentlich auch konventionelle Lösung ist die ON DUPLICATE KEY Klausel.

INSERT INTO counter 
   (`visitor`, `date`,`hits`)
VALUES
   ('127.0.0.1','2009-06-01', 1)
ON DUPLICATE KEY UPDATE
   hits=hits+1;

Dabei werden die Schlüssel der Tabelle überprüft. Ist bei diesem Beispiel die IP Adresse 127.0.0.1 schon vorhanden, wird der hits-Counter um eins hochgezählt.
 

Möglichkeit 2: Subquery
Die zweite Möglichkeit ist mit einem doppelten Subquery zu überprüfen, ob es den Datensatz schon gibt.

INSERT INTO table
   (name)
   SELECT
      distinct('lala')
   FROM 
      adressliste
   WHERE
      NOT EXISTS (
         select name from adressliste where name = 'lala'
      )

Bei dem insert wird mit einem "dummy"-Select der zukünftige Inhalt des Datensatzes ('lala') "ausgelesen". Dieser Inhalt wird unter der Bedingung "Du bist nicht schon in der Tabelle enthalten", welches mit einem Sub-Subquery überprüft wird, an das insert übergeben.

Die Prüfung passiert dort mit der NOT EXISTS Klausel. Alles was also nicht bei dieser Abfrage raus kommt, wird in die Tabelle eingefügt.

Möglichkeit Nr. 2 ist allerdings nur bei Tabellen die keine Schlüssel definiert haben sinnvoll. (Jeder der eine Tabelle ohne Schlüssel erstellt gehört verprügelt.)

Heute sind die Referenz Befehlskarten angekommen.

Im Moment gibt es im Terrashop Referenz Befehlskarten für viele verschiedene Sprachen für einen Euro!

Das sind 30x21cm große doppelseitige Karten mit Infos und Hilfen über verschiedene Sprachen. Beispielsweise Syntax, Befehle und Kontrollstrukturen. Die Karten sind laminiert, sodass die Abwischbar sind, und zum Beispiel mit Folienstiften drauf Rumgemalt werden kann.

Verfügbare Sprachen:

• HTML & CSS
• C# .NET
• XSLT
• Oracle PL/SQL
• XQuery & XPath
• PHP
• T-SQL
• Visual Basic .NET

Auf der Arbeit haben wir erst mal ne Großbestellung gemacht. Wir sind sogar über den Bestellwert von 20€ rüber gekommen, sodass und alles Versandkostenfrei kommt.

Habe mir von PHP & HTML/CSS jeweils zwei Karten bestellt. Die kommen neben die Domain Weltkarte an die Wand. Zwei von jeder, da die Karten ja doppelseitig sind.

Bis eben gerade habe ich mich mal wieder sehr intensiv mit SQL Abfragen beschäftigt, und einen Weg gefunden diesen ganzen "Ähnliche Artikel" Kram mit einem einzigen Query auszulesen.

Auf http://dev.mysql.com bin ich auf zwei sehr interessante Features gestoßen, die ich bis jetzt noch nicht kannte. Und zwar die Funktion GOURP_CONCAT() und den Operator IN. [...] Weiterlesen...