UniDac Select & Edit (Anfängerfrage)

[Perlsau]

Was soll daran fragwürdig sein? Wenn du beim Datenbank-Design Indexspalten erstellst, die immer automatisch hochgezählt werden, empfiehlt sich diese Vorgehensweise. Wenn du kein eindeutiges Indexfeld erstellst, sondern deinen Index aus mehreren Spalten zusammensetzt, wäre das natürlich Blödsinn. Deshalb jedoch gleich die komplette Idee zu verwerfen, halte ich für mehr als fragwürdig. Hier geht es nicht wirklich um den "Unterschied zwischen Index und Key Constraint", sondern um einen Regelvorschlag zur Benennung ganz bestimmter Spaltentypen. Dein Einwand, daß der Vorschlag bei Konstrukten, für die er gar nicht gedacht ist, nicht funktioniert, ist daher mehr als überflüssig.

[jobo]

Wenn es um das "Hochzählen" geht, also vielleicht um einen Primärschlüssel(?) und nicht um die Indizierung, warum sollte ich das Feld dann mit dem irreführenden Namensteil "Index" versehen?
Was nützt eine Konvention, wenn sie nicht durchgängig funktioniert? Falls der Name mir eine bestimmte Idee davon geben soll, was die Spalte macht, wie sie sich verhält, warum nennt man es dann nicht genauso. Die Konvention ist in meinen Augen unglücklich, weil Ihre Anwendung nicht in beiden Richtungen Name<>Verhalten durchgängig ist bzw. die Benamung nach Deiner Erläuterung nicht mal etwas mit einem Index zu tun hat.
Der Begriff Index hat in der Datenbankwelt nun mal eine feste Bedeutung. Das wird hier außer Acht gelassen.

[p80286]

Zitat von Perlsau:

Was soll daran fragwürdig sein? Wenn du beim Datenbank-Design Indexspalten erstellst,..

Das erinnert mich stark an die alten ISAM-Vorgehensweise. Wenn ich z.B. eine Tabelle mit Personendaten habe käme ich nicht auf die Idee eine Spalte idx_FamilenVorname zu erstellen. Die Indices sind für den schnellen Zugriff auf die Daten notwendig, und wenn für meine Anwendung alle erfassten Daten für den Zugriff genutzt werden, dann gibt es eben für jede Spalte und ggf. für Spaltenkombinationen einen Index.
Wer hier spart, spart am falschen Ende.

Gruß
K-H

[Perlsau]

Lieber K-H,

ich hatte doch oben bereits deutlich gemacht, daß mein Vorschlag lediglich für jene Fälle gilt, in denen ein automatisch forgezählter oder ein sonstwie erzeugter Index existierst oder notwendig ist. Der TE hatte in seinem Eingangsposting von genau so einer Spalte gesprochen, und genau diesem Fall galt auch mein Vorschlag, den der TE sogar gut findet.

Was du mir hier erzählst, ist mir erstens bekannt und hat mit meinem Vorschlag, wie bereits erwähnt, nichts zu tun. Deshalb verstehe ich nicht, was dich dazu treibt, ständig und wiederholt darauf herumzureiten und meinen Vorschlag der Namensgebung als veraltet, verwirrt, falsch gespart usw. zu diffamieren. Sollte die Ursache in irgend einem Groll gegen mich liegen, darfst du mich gerne via PM darüber aufklären.

[Perlsau]

Zitat von jobo:

Wenn es um das "Hochzählen" geht, also vielleicht um einen Primärschlüssel(?) und nicht um die Indizierung, warum sollte ich das Feld dann mit dem irreführenden Namensteil "Index" versehen?
Was nützt eine Konvention, wenn sie nicht durchgängig funktioniert? Falls der Name mir eine bestimmte Idee davon geben soll, was die Spalte macht, wie sie sich verhält, warum nennt man es dann nicht genauso. Die Konvention ist in meinen Augen unglücklich, weil Ihre Anwendung nicht in beiden Richtungen Name<>Verhalten durchgängig ist bzw. die Benamung nach Deiner Erläuterung nicht mal etwas mit einem Index zu tun hat.
Der Begriff Index hat in der Datenbankwelt nun mal eine feste Bedeutung. Das wird hier außer Acht gelassen.

Das ist ein vernünftes Argument, denn tatsächlich ist dein Index in einer Datenbank nicht identisch mit einer AutoInc-Spalte, die z.B. eine Rechnungsnummer oder Personalnummer repräsentiert. Man könnte diese Spalte auch z.B. PK_Adressen nennen oder PK_Rechnung. Ich lehnte mich jedoch bei meiner Namenswahl vor etlichen Jahren, als ich mit dem DB-Design begann, an gängige Vorstellungen an, wonach ein Index (außerhalb der Datenbankwelt) u.a. auch eine zugeordnete willkürliche Nummer sein kann wie z.B. eine Artikelnummer oder Rechnungsnummer. In meinen ersten Access-Datenbanken hießen alle AutoInc-Felder INDEX, wohl auch, weil das in den entsprechenden Tutorials so vermittelt wurde. Davon wird wohl auch der TE bzw. der DB-Designer, der die Datenbank gestaltet hat, mit der der TE nun solche Probleme hatte.

Davon abgesehen wird die PK-Spalte (also jene Spalte, die den Primärschlüssel einer Tabelle stellt) ja sowieso meist indiziert, was die Wahl auf Idx_ als Präfix nicht ganz so absurd erscheinen läßt, wie du es hier darstellst.

Bevor hier jetzt aber wieder Streitigkeiten mit unschönen und an Beleidigungen grenzenden Zuweisungen entstehen, klinke ich mich aus und klicke auf abbestellen. Vielen Dank für's Gespräch.

[DeddyH]

Ich habe den Thread nun 4 mal komplett durchgelesen und kann nirgends diffamierende Äußerungen entdecken. Im Gegenteil, es wurde mit sehr sachlichen Argumenten dargelegt, dass eine solche Benennung von Spalten evtl. nicht ganz optimal ist, da der Zweck dahinter im Laufe eines Release-Zyklus sehr schnell ad absurdum geführt werden kann. Von daher finde ich diese Reaktion sehr befremdlich

[nahpets]

Hallo zusammen,

die hier "entstehenden Streit" resultiert vermutlich auf der unterschiedlichen Interpretation von Index.

Frank beschreibt mit Index das, was ich eher unter dem Namen "Technischer Schlüssel" kenne, also eine datenbasierende Möglichkeit der eindeutigen Zuordnung von Daten.

Im Allgemeinen scheint man in der Datenbankwelt unter Index eher die technische Möglichkeit des schnellen Zugriffes auf Daten zu verstehen, eine Eindeutigkeit ist hier nicht zwingend erforderlich. Diese technische Möglichkeit dürfte datenbankabhängig sein und dient ausschließlich der schnelleren Verarbeitung von Daten, kann/muss daher außerhalb der dateninduzierten liegen.
In meiner bisherigen ca. 25-jahrigen Praxis mit vielen Unternehmen und Kunden ist mir kein Fall erinnerlich, in dem mit dem Begriff Index nicht die technische Möglichkeit des optimierten Datenzugriffs seitens der Datenbank gemeint war.

Sicherlich ist es "im realen Leben" sinnvoll, technische Schlüssel mit einem Index zu versehen. Um die Eindeutigkeit eines technischen Schlüssels sicherzustellen, empfiehlt sich ein eindeutiger Index (Primary Key). Ein AutoInc-Feld bildet diese Eindeutigkeit auf einem anderen Weg ab.

Eventuell sollten wir bei der Benutzung des Wortes Index hinzufügen, ob wir die technische Variante oder die dateninduzierte Variante meinen. Hierdurch ließen sich die "Streitigkeiten" bzw. "Missverständnisse" sicherlich deutlich reduzieren.

[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