UniDac Select & Edit (Anfängerfrage)

[sx2008]

Also ich mache das so:
Alle Primärschlüsselfelder und alle Fremdschlüsselfelder erhalten den Prefix Id (z.B. IdCustomer, IOrder, IdArticle,...).
Eine SQL-Abfrage sieht dann z.B. so aus

SQL-Code:

SELECT [feldliste]
FROM Orders INNER JOIN Customer ON Orders.IdCustomer=Customer.IdCustomer
-- Customer.IdCustomer ist ein Primärschlüsselfeld
-- Orders.IdCustomer ist ein Fremdschlüsselfeld mit gleichem Datentyp&Länge

Felder auf denen ein (oder mehrere)Index liegt (z.B. PLZ, OrderDate, CountryCode, ...) bleiben unverändert.
Feld- und Tabellennamen schreibe ich in UpperCamelCase.
Erlaubt sind nur Buchstaben, Ziffern und der Unterstrich; max 32 Zeichen.
Keine deutschen Umlaute oder Bezeichner die mit einer Ziffer beginnen.
Im Prinzip die gleichen Regeln, die auch für Pascal Bezeichner gelten.

Was sich nicht bewährt hat ist:
* Fester Prefix für alle Felder z.B. alle Feldnamen mit beginnen mit F und alle Tabellennamen beginnen mit T
* Feldnamen werden aus Tabellenname + "_" + Feldname zusammengesetzt wie z.B. (Bestellung_Datum, Customer_City)

Ich habe ein Programm mit dem ich grundsätzlich alle Namen auf reservierte Wörter überprüfe.
Dabei werden nicht nur reservierte Wörter der aktuell verwendeten Datenbank angemeckert sondern auch von anderen Datenbankherstellern.
Damit wird verhindert dass es in Zukunft Probleme gibt falls das Schema mal auf ein anderes DBMS portiert werden sollte.
http://support.microsoft.com/default...b;en-us;321266
http://docs.oracle.com/cd/B19306_01/...rved_words.htm
http://developer.mimer.com/validator...rved-words.tml
http://www.firebirdsql.org/refdocs/l...-reswords.html

[jobo]

Eigentlich gehört das wohl nicht hier her, den Thread relevanten Teil hat sx2008 mit seinen Hinweisen zu den reservierten Wörtern geliefert.
Trotzdem mein Senf zum Thema Index & Co. Auch wenn es mehr oder weniger bekannt sein dürfte, vielleicht hilft es jemand weiter, für absurd halte ich es jedenfalls nicht.

Constraints
===========
Constraint, eine Regel in einem RDBMS, die verschiedene Ausprägungen haben kann und sich z.B. auf einen einzelnen Spaltenwert oder alle Werte einer Spalte oder mehrere Spalten beziehen kann.

Primary Key Constraint, eine spezielle Constraint Form, die bezüglich ein oder mehrerer Spalten Eindeutigkeit und „nicht undefiniert“ fordert. Die Erzeugung der Werte erfolgt häufig über AutoInc Datentypen, Trigger oder Trigger & Generatoren/Sequenzen datenbankseitig, clientseitig dagegen mittlerweile häufig über GUID oder UUID.

Eine Spalte mit Primary Key Constraint wird häufig als Primärschlüssel übersetzt. Es kann auch Sekundärschlüssel geben, also weitere Spalten, die ebenfalls einen eindeutigen Zugriff erlauben.

Unique Constraint, wie Primary Key, „undefiniert“ jedoch erlaubt.

Foreign Key Constraint definiert die Existenz identischer Feldwerte in einer anderen Spalte (einer anderen Tabelle).
Es gibt weitere Constraint Formen.

Ein Datenmodell kann angelegt werden, ohne einen dieser Constraints zu verwenden. Damit lässt man allerdings wesentliche Merkmale eines RDBMS ungenutzt, was Folgen hat für Exaktheit bzw. Konsistenz und Robustheit der Datenverarbeitung. Sind diese und andere Constraints definiert, so garantiert(!) ein echtes RDBMS die Einhaltung u.a. dieser Constraint Regeln (siehe ACID).
Ich habe bereits Software gesehen, die auf derartigen Datenmodellen ohne Constraints aufsetzt. Der Sinn erschließt sich mir nicht, in Betracht kommen Ahnungslosigkeit, Schlamperei, Faulheit oder der Versuch von Obfuscation.

Indizes
=======
Indizes haben mit Constraints nichts zu tun, sie beschleunigen idealer Weise nur den Datenzugriff. Damit helfen sie allerdings dem RDBMS, die definierten Constraints möglichst leicht (also schnell) einzuhalten.

Der Index ist eine zusätzliche, physikalisch vorhandene Sortierung der Feldinhalte ein oder mehrerer Spalten, ein Index kann dabei ebenfalls die Eigenschaft „unique“ beinhalten. Die Sortierungsmöglichkeiten bzw. der Indexaufbau kann je nach RDBMS verschiedene Möglichkeiten bieten, bspw. als Bitmap Index oder Function Based Index. Außerdem können Indizes auch mehrfach auf identischen Spalten angelegt werden. Falls das nicht versehentlich geschieht: es wird absichtlich evtl. zur Indexreorganisation verwendet, ansonsten verlangsamt es lediglich Einfügen und Ändern von Daten weiter, wie jeder Index.

Indizes haben gar nichts mit Funktionsweise und Logik des Datenmodells zu tun und können gelöscht werden, ohne der Funktion eines Datenmodells (ACID) zu schaden. Es wird lediglich langsamer.
(Ich schließe hier mal extra nicht aus, dass es herstellerabhängige Sonderformen gibt, wo das Löschen eines Index auch die Funktion beeinträchtigt.)

Indizes haben eigene Namen, die allerdings häufig vom DB System vergeben werden, z.B. im Falle einer Spalte, die mit Primary Key Constraint definiert wurde, ohne die Indexoptionen explizit anzugeben.

Umgang mit Indizes im Client
============================
Da sie nichts zum Datenmodell an sich beitragen, können sie z.B. auch in separaten Skripten verwaltet werden. Wegen Ihrer Unbeständigkeit, ist es auch nicht zu empfehlen, clientseitig Indizes namentlich anzusprechen (außer das Programm dient der Indexverwaltung bzw. erzeugt oder ändert seine eigene DB „on the fly“).
Ebenso ist es nicht empfehlenswert, Existenz und Art des Index in Spaltenbenennung einzubeziehen. Das gilt auch für alle anderen physikalischen Optionen einer Datenbank. Dieser Teil hat erhebliche Bedeutung bei der so angesagten datenbankunabhängigen Programmierung. SQL Syntax für Indexdefinition ist kaum standardisiert, Datenmodelle mit eingestreuten Index Statements sind also schwerer zu migrieren.

[p80286]

Zitat von sx2008:

Was sich nicht bewährt hat ist:
* Fester Prefix für alle Felder z.B. alle Feldnamen mit beginnen mit F und alle Tabellennamen beginnen mit T
* Feldnamen werden aus Tabellenname + "_" + Feldname zusammengesetzt wie z.B. (Bestellung_Datum, Customer_City)

Warum?

Code:

select TName.FName, FVorname
from TName

gefällt mir zwar nicht aber kommt allen entgegen die sich gerne um qualifizierte Namen drücken.

Bestellungen.BestellDatum,Zahlung.ZahlungsEingangs datum;Bestellungen.BestellEingangsdatum
vs
Bestelldatum,ZahlungsEingangsdatum,BestellEingangs datum
vs
Bestellungen.Datum,Zahlung.Eingangsdatum,Bestellun gen.Eingangsdatum

"Schöner" finde ich die dritte Möglichkeit, in der Praxis habe ich mit der ersten zu tun und nach einer unschönen Eingewöhnungsphase kann ich damit gut umgehen, da zumindestens ich immer weiß wo ich gerade bin.

Gruß
K-H