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 von ATS3788:

Nein Uwe Danke

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

So wie ein Kuchenrezept?

[ATS3788]

Danke Uwe
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 von mkinzler:

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 von ATS3788:

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 von jobo:

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.