Firebird Reihenfolge der Tabellen bei Insert mit Foreignkey

[Neutral General]

Zitat von Hansa:

Zitat von Kostas:

wenn eine Firebird Datenbank ForeignKeys verwendet, muss bei Inserts auf die richtige Reihenfolge geachtet werden.

Wo steht das ? Oder wer sagt das ? Reihenfolge von was überhaupt ? Wegen mehrerer Antworter gehe ich da mal davon aus, dass mir jemand eine plausible Antwort geben kann.

Du kannst nicht die Lieferadresse zu einem Beleg speichern bevor der Beleg gespeichert ist.
Das meint er.

[Hansa]

Das ist ja wohl klar, aber woher soll die Datenbank bzw. die Systemtabellen das wissen ? Kenne so etwas nur von schlecht programmierten Programmen. Insofern ist die Nachfrage für mich dann doch eher irrelevant.

[Fritzew]

Wenn Foreign Keys da sind muss die Reihenfolge stimmen. Ansonsten tritt ein Fehler auf und das ist ja wohl mehr als korrekt

[Kostas]

Hallo Hansa,

ich verwende sehr intensiv referenzielle Integrität. Tabellen haben Abhängigkeiten (Foreign Keys) Als Beispiel die Tabelle BelegPos referenziert auf die Tabelle Belege. Ich kann also
nicht Belege löschen und dabei die BelegPositionen stehen lassen. Das Bedeutet auch, wenn ich Datensätze in die Datenbank inserte, muss ich zuerst die Datensätze der Tabelle Belege inserten
erst danach kann ich die Datensätze für BelePos inserten. Wenn das Datenbankschema wächst mit mehreren hundert Tabellen wird es unübersichtlich und gefährlich selbst die Tabellenreihenfolge zu
setzen.
Im meinem Fall benötige ich die Funktion für ein automatisierten Restore aus einem Backup der Datenbank.
Mein Anwender macht also ein Backup jeden Tag. Solange nichts passiert, ist alles gut. Wenn jedoch in der Datenbank durch User Fehler Daten gelöscht werden, soll es möglich sein seine aktuelle Datenbank so zu belassen wie sie ist und aus dem Backup die Fehlenden Datensätze zu rekonstruieren. Dabei ist es eben wichtig in der richtige Reihenfolge zu inserten wegen Foreign Key.

Die Funktionalität in einer StoredProc zu haben ist sehr interessant. Ich habe die StoredProc jetzt mit mehreren Datenbanken getestet und sie funktioniert einwandfrei. Was noch zu testen ist, wenn zirkulare Referenzen(Eine Tabelle referenziert sich selbst durch Foreign Key) verwendet werden.

Schöne Grüße Kostas

[Hansa]

Zitat von Kostas:

Tabellen haben Abhängigkeiten (Foreign Keys) Als Beispiel die Tabelle BelegPos referenziert auf die Tabelle Belege. Ich kann also
nicht Belege löschen und dabei die BelegPositionen stehen lassen.

Das macht ja sowieso die Datenbank von selbst, sofern richtig angelegt. Und das heisst : on delete cascade Du musst der DB sagen, dass es beim Löschen eines Beleges dazu kommen soll, dass auch alle Beleg-Positionen gelöscht werden. Da braucht man gar nichts mehr selber zu machen. Man kann sogar von mir aus 50 verschachtelte Tabellen so behandeln. Und es gibt auch noch on update, on insert. Man kann also da sogar unbesezte NULL-Felder etc. mit sinnvollem Wert besetzen. Wenn ich das hier im Zusammenhang so sehe, dann denke ich, dass das Dir nicht so bekannt ist,

[Kostas]

Hallo Hansa,

das ist mir alles durchaus bekannt. Ich habe eine Ahnung von Datenbank Design.
Was mich jedoch wundert ist, wenn Du eine Ahnung von Datenbank Design hast, warum begreifst du nicht warum ich die Reihenfolge der Tabellen benötige wenn ich erwähne das ich Foreign Keys verwende?
Andere haben es doch auch kapiert!
Sorry, vermutlich habe ich etwas übersehen zu erwähnen.

Also nochmal: Ich verwende bewusst referenzielle Integrität, ich nutze Cascade Delete wo es Sinn macht, ich nutze bei Foreign Keys immer cascade update außer wenn ich es bewusst nicht einsetze.
Bei referenzielle Integrität ist die Reihenfolge der Tabellen bei Inserts elementar wichtig.

Gruß Kostas

[jobo]

Zitat von Kostas:

Hallo Zusammen,

ich habe den Artikel gefunden http://firebird-support.yahoogroups....-of-dependency

und daraus die StoredProc erzeugt. Aus meiner Datenbank hat er alle Tabellen komplett richtig ausgelesen.

Ich würde mich auf das Script nicht verlassen. Es enthält mehrere Ungereimtheiten.
Die Select Statements darin arbeiten auch mit Views, die da einfach nicht reingehören.
Die Tabelle mit der "Reihenfolge" der Tabellen enthält faktisch keine Reihenfolge, sondern nur Tabellennamen, deren Reihenfolge sowohl beim Befüllen als auch beim späteren Auslesen nicht definiert ist. (Selbst wenn man davon ausgeht, dass die ID Spalte vlt. über einen Generator befüllt wird.)
Außerdem scheint mir die Verwendung der Indexnamen fragwürdig, aber vielleicht ist das ja bei Firebird fest vorgegeben.

[Kostas]

Hallo Jobo,

danke für den Hinweis mit den Views, werde ich noch herausfiltern.

Die Reihenfolge der Tabelle scheint soweit ich es bis jetzt getestet habe, korrekt zu sein.
Die Tabellen werden in der richtigen Reihenfolge abgerufen über das Feld ID

Code:

SELECT RDB$RELATION_NAME
FROM TABLES_ORDERED
ORDER BY ID

Mal sehen was weitere Tests ergeben, aber wie gesagt, bis jetzt stimmt es.
Danke und schöne Grüße.
Kostas

[Lemmy]

Zitat von jobo:

Die Select Statements darin arbeiten auch mit Views, die da einfach nicht reingehören.

wo werden da views verwendet?

Zitat von jobo:

Die Tabelle mit der "Reihenfolge" der Tabellen enthält faktisch keine Reihenfolge, sondern nur Tabellennamen, deren Reihenfolge sowohl beim Befüllen als auch beim späteren Auslesen nicht definiert ist. (Selbst wenn man davon ausgeht, dass die ID Spalte vlt. über einen Generator befüllt wird.)

wenn ein Generator verwendet wird, dann sollte die Reihenfolge passen.

Zitat von jobo:

Außerdem scheint mir die Verwendung der Indexnamen fragwürdig, aber vielleicht ist das ja bei Firebird fest vorgegeben.

Was würdest Du verwenden?

[Kostas]

Die Version ohne Views.

Code:

create or alter procedure ORDER_ALLTABLES
as
declare variable COUNTNEWINSERTS integer;
declare variable NEWINSERTS integer;
begin
 /* http://firebird-support.yahoogroups.narkive.com/XPYLG1la/odp-firebird-support-listing-table-of-database-in-order-of-dependency */
  delete from tables_ordered;

  INSERT INTO TABLES_ORDERED(RDB$RELATION_NAME)
          SELECT RDB$RELATION_NAME FROM RDB$RELATIONS r
          WHERE RDB$SYSTEM_FLAG=0
          AND RDB$RELATION_TYPE = 0 /* nur Tabellen */
          AND NOT EXISTS(SELECT *
                           FROM RDB$INDICES i
                          WHERE r.RDB$RELATION_NAME=i.RDB$RELATION_NAME
                            AND i.RDB$FOREIGN_KEY IS NOT NULL);

  select count(*)
  from tables_ordered
  into :countNewInserts;
  newInserts = 0;

  while (1=1) do
  begin
      INSERT INTO TABLES_ORDERED(RDB$RELATION_NAME)
              SELECT RDB$RELATION_NAME
                FROM RDB$RELATIONS r
               WHERE RDB$SYSTEM_FLAG=0
               AND RDB$RELATION_TYPE = 0 /* nur Tabellen */
               AND NOT EXISTS(SELECT *
                                FROM TABLES_ORDERED o /*Ignore tables already inserted*/
                               WHERE r.RDB$RELATION_NAME = o.RDB$RELATION_NAME)
                               AND NOT EXISTS(SELECT *
                                                FROM RDB$INDICES i /*Only insert tables whose foreign key tables are inserted already*/
                                                JOIN RDB$INDICES i2 ON i.RDB$FOREIGN_KEY = i2.RDB$INDEX_NAME
                                                                       AND r.RDB$RELATION_NAME <> i2.RDB$RELATION_NAME /*Omit this line if you don't want to include tables pointing to themselves*/
                                                LEFT JOIN TABLES_ORDERED o ON i2.RDB$RELATION_NAME = o.RDB$RELATION_NAME
                                                WHERE r.RDB$RELATION_NAME=i.RDB$RELATION_NAME
                                                  AND i.RDB$FOREIGN_KEY IS NOT NULL
                                                  AND o.ID IS NULL);

      select count(*)
      from tables_ordered
      into :newInserts;

      if (countNewInserts <> newInserts)then
      begin
        countNewInserts = newInserts;
      end else break;
  end


        
end