SQL-Feldname des Primary Key

Aus der individuellen Arbeit für die jeweiligen Kunden – und auch historisch bedingt – ergab sich eine Abweichung zum IDEF1X.

Es handelt sich dabei um die Benennung des Primary (Unique) Keys. Nach IDEF1X ist der Tabellenname Teil des Namens für dieses ID-Feld. Er wird dann in CamelCase oder mit Unterstrich geschrieben:

SELECT * FROM Person WHERE PersonID = 1;
SELECT * FROM person WHERE person_id = 1;

Diese redundante Bezeichung habe ich mir erspart und den Record-ID jeder Haupttabelle schlicht mit „id“ bezeichnet:

SELECT * FROM table WHERE id = 1;

Damit wurde es PHP-seitig möglich, einfache und generelle Funktionen zu schreiben, die jeden Datensatz schreiben, lesen und aktualisieren können – ohne den Feldnamen des ID-Feldes erneut lesen oder jeweils generieren zu müssen:

UPDATE table SET field='value' WHERE id = 1;

Ebenso wird es einfacher, Joins dynamisch zu erstellen, da immer und in jedem Fall der Key jeder (Haupt-)Tabelle über „id“ angesprochen werden kann.

Relationen, ob nun 1:n oder n:m, werden als Foreign Keys so benannt, dass sie sich aus dem anderen Tabellennamen und dessen ID ergeben. Wird zu einer Person z.B. das Land benötigt und befindet sich dieses in der Tabelle „country“, ist der Name des Foreign Keys „country_id“.

Damit ergeben sich auch gleich die Bezeichner für eine n:m-Tabelle, die z.B. die Sprachen abbilden soll, die von Personen gesprochen werden (ein eigener Primary Key ist hier unnötig):

CREATE TABLE `person_to_language` (
  `person_id` int(14) NOT NULL,
  `language_id` int(14) NOT NULL,
  UNIQUE KEY `person_language_id` (`person_id`,`language_id`)
);

Somit ist an jeder Stelle zweifelsfrei, dass „person_id“ ein Foreign Key ist, und nicht der Primary Key „person_id“ der Tabelle „person“. Zudem werden Unsicherheiten in der korrekten Benennung vermieden, wenn z.B. Tabellennamen lang sind oder ein projektspezifisches Präfix bekommen.

Ein gewisser Nachteil ist wiederum, dass es zwei Bezeichner für einen Wert gibt, doch wird diese durch die Eindeutigkeit von „irgendeine_tabelle.id“ m.E. im späteren Coding gut ausgeglichen.

Ansonsten haben sich unterschiedliche Präfixe als vorteilhaft in der späteren Entwicklung erwiesen – auf dem ersten Blick ist die Aufgabe des Feldes erkennbar:

  • image_ für Bilder und Grafiken, z.B. image_small, image_medium…
  • date_ für benötigte Datumswerte, z.B. date_insert, date_update…
  • flag_ für Felder mit festen Optionen (meist 0/1), z.B. flag_active, flag_email_send

Links:
http://www.idef.com/idef1X.htm
http://www.softwaregems.com.au (PDF)

Schreibe einen Kommentar