In diesem Kapitel erläutern wir den Aufbau der Namen von

• Tabellen
• Prozeduren
• Triggern

Die Konventionen für „customized“ Objekte sind unbedingt zu beachten, da sie sonst durch das Einspielen von updates gelöscht werden könnten !

Hinweis : Da die SmartEngine ursprünglich den Datenbankserver ASE von Sybase in der Version 11.0.3 unterstützte, standen für Tabellen-, Trigger- und Prozedur-Namen generell nur maximal 30 Zeichen zur Verfügung. Dies wurde bislang trotz der Erweiterung in höheren ASE-Versionen beibehalten, und zwar hauptsächlich weil wir der Ansicht sind, daß zu lange Namen eher kontraproduktiv bzw. schwer zu lesen sind.

Grundsätzlich sind sämtliche Namen von Objekten case-sensitiv, d.h. insbesondere bei Prozedur-Aufrufen ist die Groß- und Kleinschreibung genau einzuhalten.

Bzgl. der Namen von Tabellen (und ihren Spalten) in der „Customer-DB“ und der Datenbank „dstore“ gibt es keinerlei Konventionen. Einzig „customized“ (also nicht zur SmartEngine gehörende) Tabellen müssen mit „cu_“ beginnen.

Es wurde jedoch mit Absicht die Case-Sensitivität ausgenutzt, um die Lesbarkeit zu erhöhen. D.h. bei Namen, die eine Zusammensetzung mehrerer Wörter darstellen, ist jeweils der Anfangsbuchstabe eines Wortes als Großbuchstabe und der Rest in Kleinbuchstaben verfaßt.

Anmerkung : Wie bereits erwähnt, dürfen in der Datenbank „dstore“ keine „customized“ Tabellen oder sonstige Objekt erstellt werden !

Die Namen der Tabellen in den Datenbanken…

• dstoreifin
• dstoreifout
• dstoretempdb

… müssen jeweils mit dem Namen der Prozedur übereinstimmen, für die sie da sind - s.a. Abschnitt „dstoreifin, dstoreifout und dstoretempdb“ in Die "anderen Datenbanken".

Anmerkung : Sollte eine Prozedur z.B. zwei „Input-Tabellen“ benötigen, sind die Namen der Tabellen so zu wählen, daß sie in möglichst vielen der ersten Zeichen mit dem Namen der zugehörigen Prozedur übereinstimmen.

Was die Tabellen in der „model“- und damit der „tempdb“-Datenbank anbelangt, wurde trotz der Verwendung durch mehrere Prozeduren (s. Abschnitt „model und tempdb“ in Die "anderen Datenbanken" bzw. Abschnitte „‚Input‘-Tabellen“ und „‚Output‘-Tabellen“ in Engine-Prozeduren) auf eine möglichst gute Charakterisierung geachtet.

So deutet der Name „OneID“ an, daß nur Datensätze mit jeweils einer ID gespeichert werden können, wohingegen „TwoIDs“ bzw. „ThreeIDs“ für Daten mit zwei bzw. drei IDs gedacht sind.

Wie bereits im Kapitel „Das Berechtigungs-Konzept“ erläutert, gibt es grundsätzlich zwei Arten von Prozeduren hinsichtlich der Ausführbarkeit :

• extern : Prozeduren, die von „SmartGates“ aufgerufen werden
• intern : Prozeduren, die nur innerhalb von Prozeduren aufgerufen werden

Die „internen“ Prozeduren beginnen mit einem „_“ im Namen und sind nicht dokumentiert. Es sind für sie keine expliziten Ausführungsrechte vergeben und sie dürfen auch nicht ohne explizite Freigabe (durch die dbap GmbH) aufgerufen werden !

Die ersten zwei Zeichen (bei den „internen“ : die Zeichen zwei und drei) kennzeichnen den „Aufgaben-Bereich“ (o.a. das Modul) der Prozedur, z.B. „om“ für „Order Management“ (also alles, was mit Aufträgen und Bestellungen zu tun hat). Es werden hierfür immer Kleinbuchstaben verwendet.

Es folgt eine möglichst aussagekräftige Kurzbeschreibung (zwecks Lesbarkeit mit einem „_“ vorangestellt) dessen, was die Prozedur tut. Wie bei Tabellen wurde auch hier mit Absicht die Case-Sensitivität ausgenutzt, um die Lesbarkeit zu erhöhen. Anmerkung : Im Regelfall wird zu Beginn dieser Kurzbeschreibung das Wort„Get“ oder „Search“ verwendet, um anzudeuten, daß Daten gelesen werden, bzw. es wird oftmals „Insert“, „Modify“, „Update“, „Delete“ oder „Create“ verwendet, um zu kennzeichnen, daß die Prozedur Daten manipuliert. Danach folgt sehr häufig eine Abkürzung der Tabelle, für die die Prozedur hauptsächlich gedacht ist.

Schließlich gibt es noch ein (optionales) aus drei Zeichen bestehendes „Postfix“, das entweder „_Ad“ oder „_Pu“ lautet. Dies dient der Kennzeichnung, welche Datenbank- Benutzer-Gruppen die Prozedur ausführen dürfen (s.a. Das Berechtigungs-Konzept, Abschnitt „Datenbank-Berechtigungen“). Hintergrund : Die Kürzel stehen für „admin“ und „public“. „public“ ist der Name einer speziellen Gruppe des (ASE-) Datenbankservers, der implizit jeder Datenbank-Benutzer angehört. Besitzt die „public“-Gruppe Ausführungsrechte auf eine Prozedur, so bedeutet dies, daß jeder Benutzer der Datenbank die Prozedur ausführen darf.

Prozeduren ohne ein solches Postfix oder Prozeduren, die auf „_Pu“ enden sind für „öffentlich zugängliche“ Anwendung wie z.B. Shop- oder Community-Webseiten gedacht. Im Gegensatz dazu sind „Ad“-Prozeduren ausschließlich für Aufgaben im Backend zuständig, also z.B. für Mitarbeiter oder Schnittstellen-Programme. Prozeduren ohne Postfix sind für beide Bereiche gleichermaßen geeignet.

„customized“-Prozeduren sind dadurch zu kennzeichnen, daß zwischen Modul und Kurzbeschreibung „_cu“ steht.

Eine besondere Gruppe von „halb-customized“ Prozeduren sind solche, die mit „_ac_“ beginnen. Sie sind schon in der Engine vorhanden, können aber „überschrieben“ werden. Details befinden sich in Das ‚Actions‘-Konzept.

Die folgende Tabelle mit einigen Beispielen faßt den Abschnitt nochmals zusammen :

Trigger-Namen beginnen mit einem aus drei Zeichen bestehenden „Prefix“, der die Aktion kennzeichnet, die zur Ausführung führt :

• „ti_“ : (für „trigger, insert“) Nach dem Einfügen von Datensätzen
• „tu_“ : (für „trigger, update“) Nach dem Aktualisieren von Datensätzen
• „td_“ : (für „trigger, delete“) Nach dem Löschen von Datensätzen

Anmerkung : Da die SmartEngine den Datenbankserver ASE von Sybase (in der Version 15.7) unterstützt, gibt es keine „before“-trigger.

Nach dem Prefix folgen (wg. der Beschränkung auf 30 Zeichen) die ersten 27 Zeichen des Tabellen-Namens in Kleinbuchstaben.

Diese Konventionen sollten auch für Trigger von „customized“ Tabellen eingehalten werden. Auf Standard-Tabellen sind übrigens keine „customized“ Trigger erlaubt !