Tabellen richtig mit Constaints darstellen

[ATS3788]

Hallo frohes neues 2015

Ich habe da eine kleine Datenback
mit Abhängigkeiten, Constraints

Wie bekomme ich es richtig hin die Abhängifkeiten, mithilfe
von TDBTable, dies in zwei DBGrids darzustellen.

Also wenn COUNTER sich ändert die Abhängigkeit von TOMAIN
im GRID mit der richtigen Datenmenge dargestellt wird.

SQL-Code:

CREATE GENERATOR GENDIRINFO;

CREATE TABLE DIRINFO (
    COUNTER      BIGINT NOT NULL,
    PRINT        BOOLEAN /* BOOLEAN = SMALLINT CHECK (value is null or value in (0, 1)) */,
    LOCATION     STRING50 /* STRING50 = VARCHAR(50) */,
    PLACE        STRING50 /* STRING50 = VARCHAR(50) */,
    DESCRIPTION  STRING50 /* STRING50 = VARCHAR(50) */,
    PFAD         STRING50 /* STRING50 = VARCHAR(50) */
);

ALTER TABLE DIRINFO ADD CONSTRAINT PK_DIRINFO PRIMARY KEY (COUNTER);


CREATE GENERATOR GENFILENAMES;

CREATE TABLE FILENAMES (
    COUNTER   BIGINT NOT NULL,
    TOMAIN    BIGINT,
    FILENAME  STRING50 /* STRING50 = VARCHAR(50) */,
    PATH      STRING80 /* STRING80 = VARCHAR(80) */,
    "SIZE"    DOMBIG /* DOMBIG = BIGINT */,
    "DATE"    DOMCHAR21 /* DOMCHAR21 = CHAR(21) */
);

ALTER TABLE FILENAMES ADD CONSTRAINT PK_FILENAMES PRIMARY KEY (COUNTER);
/*                                Foreign Keys                                */

ALTER TABLE FILENAMES ADD CONSTRAINT FK_FILENAMES_1 FOREIGN KEY (TOMAIN) REFERENCES DIRINFO (COUNTER);

[Uwe Raabe]

Hast du dir schon das Tutorial zu FireDAC Haupt/Detail-Beziehung durchgelesen? Wenn das noch Fragen offen lässt, können wir das hier ja noch weiter diskutieren.

[ATS3788]

Nein Uwe Danke

Ich verstehe nicht warum die nicht einfach ein paar PDF erstellen die man abarbeiten kann.

[p80286]

Ein Feld, daß als PrimaryKey fungiert, "Counter" zu benennen ist ja schon richtig aussagekräftig.
Da Dateinamen eine ziemlich feste Beziehung zu Unterverzeichnissen pflegen, was willst Du da ändern?
Im Allgemeinen werden Daten und nicht die Beziehung von Daten untereinander dargestellt, darum irritiert mich Dein Frage ein wenig.

Gruß
K-H

Zitat:

Zitat von ATS3788 (Beitrag 1285106)

Nein Uwe Danke

Ich verstehe nicht warum die nicht einfach ein paar PDF erstellen die man abarbeiten kann.

So wie ein Kuchenrezept? :gruebel:

[ATS3788]

Danke Uwe:thumb:
nun geht es wie es sein soll.

Ein frage habe ich da noch. Für was habe ich dann die Constraints in der
Datenbank ?

Schönes 2015

[mkinzler]

Damit das DBMS diese sicherstellt und auch automatisch entsprechnend benötigte Indizes erstellt.

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1285112)

Damit das DBMS diese sicherstellt und auch automatisch entsprechnend benötigte Indizes erstellt.

... und damit z.B. keine doppelten Einträge erfolgen können. Nehmen wir man an, ich hab in einer Tabelle die Spalten Vorname, Nachname, Geburtsjahr, Ort und Strasse. Wenn ich diese Kombination indiziere und explizit eindeutig sage, dann darf diese Kombination nicht mehrfach vorkommen.

[jobo]

Zitat:

Zitat von ATS3788 (Beitrag 1285110)

Für was habe ich dann die Constraints in der
Datenbank ?

Du hast 2 Arten Constraints verwendet (laut den Scripts oben):
Primärschlüsselconstraints und Fremdschlüsselconstraints.

Sie haben in der Tat nichts mit dem Delphicode und der Master Detail Mechanik, die Du erzielen möchtest zu tun. Du kannst die Constraints löschen, ohne dass die Funktion Deines Programms beeinträchtigt ist.

Diese beiden und andere Arten von Constraints definieren serverseitige Regeln, die in Deinem Fall u.a. die Datenkonsistenz garantieren! Ja, garantieren. Klingt vielleicht banal, ist es aber nicht.
Beispiel 1:
Deinem Delphiprogramm ist es vermutlich erstmal egal, wenn ein Masterdatensatz gelöscht wird, auch wenn noch Detaildatensätze angezeigt werden. Dein Programm wird diese Daten auch nie wieder anzeigen, also könnte es fast egal sein.
Machst Du aber bspw. einen Report über Deine Daten, wirst Du nie auf die richtigen Zahlen kommen. Weil Du Leichen im Keller hast.

Ein DB Server speichert eben nicht nur stumpf Daten, es geschieht viel mehr, sofern definiert. Und das unabhängig davon, wie gut oder schlecht das zugreifende Programm ist.
Kleiner Wermutstropfen:
Der Server garantiert zwar die Einhaltung gewisser Regeln, er nimmt Dir aber leider nicht ab, die aus Regelverletzung resultierenden Fehler abzufangen.

Beispiel 2:
Löscht Du bei der Constraint Definition oben einen Datensatz aus der Mastertabelle, auf den bereits Detaildatensätze verweisen, wird der Server einen Fehler erzeugen (eine häßliche Meldung auswerfen, die eigentlich niemand sehen will) und den Datensatz nicht löschen. Probier es aus, entferne den Foreign Key Constraint und von da an, ist dem Server egal, was Du löscht.
Umgekehrt kannst Du die Foreign Key Definition so erweitern, das abhängige Datensätze gleich mitgelöscht werden, praktisch, aber vielleicht etwas überraschend für den Anwender.

Dinge wie automatisch erzeugte Indizes auf Schlüsselfeldern sind ein (meist sinnvolles) Geschenk der DB Hersteller. Eigentlich macht man auch das häufig selbst, da man dann z.B. die Namensgebung des Index und seine Art kontrollieren kann.

[Perlsau]

Zitat:

Zitat von jobo (Beitrag 1285121)

Löscht Du bei der Constraint Definition oben einen Datensatz aus der Mastertabelle, auf den bereits Detaildatensätze verweisen, wird der Server einen Fehler erzeugen (eine häßliche Meldung auswerfen, die eigentlich niemand sehen will) und den Datensatz nicht löschen.

Deshalb verzichte ich seit langem darauf, Verknüpfungen auf Datenbank-Ebene (Foreign Keys) zu implementieren, und regle das stets in der Anwendung. Da kann ich nämlich abfragen, ob der zu löschende Detaildatensatz in der Mastertabelle Verwendung findet, und zwar mit einem einfachen

Code:

select * count
where Detailspalte = DetailDatensatzID

Ist Result > 0, erfolgt eine Meldung für den Anwender, die ihm mitteilt, daß der Datensatz nicht gelöscht werden kann, weil er noch in Verwendung ist. Oder optional eine MessageDlg, die fragt, ob die entsprechende Spalte aller Datensätze der Mastertabelle, die diesen Datensatz der Detailtabelle verwenden, mit Null oder 0 (steht bei mir meist für '_unbekannt') aktualisiert werden sollen: 'Wenn Sie den Eintrag "spanisch" dennoch löschen wollen, werden alle Datensätze, die die Sprache "spanisch" aufweisen, der Sprache "_unbekannt" zugeordnet.'

[mkinzler]

Genauso könntest Du auf die Exception/den Returncode reagieren.
Zudem werden die Contraints im Datenbankschema auch von anderen Verbindungen auch von Zugriffen ausserhalb des Programmes beachtet und erzwungen. Zudem kann eine Datenbankadmintool diese verwenden ( Filterung beim Insert usw.)
Deshalb würde ich nicht auf dieses sinnvollen Features verzichten.
Der vorgeschlagene Weg funktioniert zudem auchg mit angelegten Constraints.

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1285131)

Genauso könntest Du auf die Exception/den Returncode reagieren.

Vollkommen richtig :thumb:

Zitat:

Zitat von mkinzler (Beitrag 1285131)

Zudem werden die Contraints im Datenbankschema auch von anderen Verbindungen auch von Zugriffen ausserhalb des Programmes beachtet und erzwungen.

Andere Zugriffe als von "meiner" Anwendung gibt es bei meinen Datenbanken im Grunde nicht. Die allermeisten sind sogar FB-Embedded.

Zitat:

Zitat von mkinzler (Beitrag 1285131)

Zudem kann eine Datenbankadmintool diese verwenden ( Filterung beim Insert usw.)

Meine Kunden verwenden gewöhnlich (mangels Kenntnissen) kein Datenbankadmintool, sondern beschränken sich beim Datenbankzugriff auf "meine" Anwendung.

Zitat:

Zitat von mkinzler (Beitrag 1285131)

Deshalb würde ich nicht auf dieses sinnvollen Features verzichten.

Ich verzichte auf manches, wenn es mir unnötig erscheint. Manche Kunden – zumeist selbst Entwickler – bestehen dennoch darauf, dann kriegen die das auch.

Zitat:

Zitat von mkinzler (Beitrag 1285131)

Der vorgeschlagene Weg funktioniert zudem auchg mit angelegten Constraints.

Wiederum vollkommen richtig :thumb:
Normalerweise muß ich mit der Zeit, die ich für die Entwicklung benötige, schon ein wenig haushalten, sonst wird's entweder zu teuer oder ich ruiniere mir meinen Stundensatz :stupid:

[ATS3788]

Schönes 2015

Mir ist schon klar das die Constraints =! Einschränkungen
eine gewisse "Ordnung" in eine Tabelle gebracht werden soll.

Es wäre eben schon gut wenn es ein Handbuch zu FireDac für Noops wie mich
in PDF Format geben würde.

Gibt es sowas ?

[Uwe Raabe]

Zitat:

Zitat von ATS3788 (Beitrag 1285256)

Es wäre eben schon gut wenn es ein Handbuch zu FireDac für Noops wie mich
in PDF Format geben würde.

Gibt es sowas ?

Bei FireDAC V8 (ich glaube das war XE4) gab es noch ein CHM und ein PDF in einer separaten Installation unter

Delphi-Quellcode:

%PROGRAM FILES(X86)%\Embarcadero\FireDAC\Help\

. Allerdings steht da auch nicht viel mehr drin als man im DocWiki findet. Dafür ist das DocWiki aber auch in Deutsch - falls das relevant ist.

[ATS3788]

Danke UWE
Da gibt es so mächtige Tool und nur eine bescheidene Doku.

[Dejan Vu]

Bücher, Bücher immer wieder Bücher. Es gibt Dinge, die kann man nicht als Kuchenrezept handhaben, da bedarf es ein wenig Theorie. DB-Design, 3NF, Constraints etc. gehören einfach dazu.

Ich würde niemals auf Constraints verzichten, denn eine Datenbank sollte auch verständlich sein, ohne in den Code schauen zu müssen. Es gibt massenhaft (freie) Tools, die aus einer DB mit Constraints grafisch so aufbereiten, das man das Modell sofort versteht. Ohne Constraints ist das nicht möglich. Demjenigen, der darauf verzichtet, wünsche ich viel Spaß, wenn er nach Jahren die Datenbank erweitern soll. Oh, wenn diese natürlich nur aus 5 Tabellen besteht, braucht man wirklich keine Constraints.

Das Schöne an Constraints ist zudem, das sie mich auf Integritätsfehler in meiner SW hinweisen.