AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Referentielle Integrität | Firebird
Thema durchsuchen
Ansicht
Themen-Optionen

Referentielle Integrität | Firebird

Ein Thema von f4k3 · begonnen am 15. Mai 2009 · letzter Beitrag vom 15. Mai 2009
Antwort Antwort
Benutzerbild von f4k3
f4k3

Registriert seit: 15. Aug 2007
Ort: Nürnberg
313 Beiträge
 
Delphi 2007 Architect
 
#1

Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 11:18
Datenbank: Firebird (Win32) • Version: 2.1 • Zugriff über: ZEOSLib
Moin Moin liebe DPler

Ich hätte mal eine Frage zwecks Referentieller Integrität ...
Ich designe und erstelle meine Datenbanken / Tabellen mit IBExpert.

Wenn ich nun einen Fremdschlüssel definieren möchte, hab ich die möglichkeit die Änderungs- und Löschregel einzustellen.

Mir geläufige Änderungsregeln:
ON UPDATA CASCADE
ON UPDATE RESTRICT

Mir geläufige Löschregeln:
ON DELETE CASCADE
ON DELETE RESTRICT
ON DELETE SET NULL

Ich benötige in beiden Fällen die "RESTRICT" Regel ... in IBExpert hab ich aber nur folgende Regeln zur Auswahl (Änderungs- + Löschregeln gleich)

NO ACTION
CASCADE
SET NULL
SET DEFAULT

Alle drei sind für meine Aufgabe nicht zu gebrauchen, da ich nicht zulassen kann (aus Nachweis gründen) dass Datensätze abgeändert oder gelöscht werden, wenn
Detaildatensätze noch vorhanden sind.

Unterstützt Firebird kein RESTRICT? Ich hab schon gegoogled, finde aber keine konkrete antwort darauf

Wenn ja, würde dass Bedeuten, dass ich zur Laufzeit überprüfen müsste ob Detaildatensätze existieren ... und dass wär ja mal nicht so schön


Vielen Dank für eure Posts

Euer f4k3

// NO ACTION hab ich vergessen aufzulisten
Sascha
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.858 Beiträge
 
Delphi 11 Alexandria
 
#2

Re: Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 11:25
Zitat:
Alle drei sind für meine Aufgabe nicht zu gebrauchen, da ich nicht zulassen kann (aus Nachweis gründen) dass Datensätze abgeändert oder gelöscht werden, wenn
Detaildatensätze noch vorhanden sind.
Was soll den in diesem Fall geschehen?
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von f4k3
f4k3

Registriert seit: 15. Aug 2007
Ort: Nürnberg
313 Beiträge
 
Delphi 2007 Architect
 
#3

Re: Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 11:30
Zitat von mkinzler:
Zitat:
Alle drei sind für meine Aufgabe nicht zu gebrauchen, da ich nicht zulassen kann (aus Nachweis gründen) dass Datensätze abgeändert oder gelöscht werden, wenn
Detaildatensätze noch vorhanden sind.
Was soll den in diesem Fall geschehen?
Ein RESTRICT ...

Das Löschen oder Abändern der Daten der Master- oder Childtabelle ist nicht gestattet ... Wobei sich dass ändern / löschen nur auf
die Primary und Foreign Keys bezieht ... also alle Schlüsselattribute.

Ich möchte einfach verhindern, dass wenn ich einen Kunden lösche ... zu dem Daten in der Support-Datenbank existieren ... gelöcht werden kann.
Wenn ich dann überall NULL oder -1 stehen hab, kann kein konkreter Nachweis geführt werden, und die Daten sind inkonsitent ...
Sascha
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.858 Beiträge
 
Delphi 11 Alexandria
 
#4

Re: Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 11:33
Dann sollte NO ACTION passend sein. Verhindert das Löschen von Datensätzen im Master, wenn dieser referenziert wird.
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von f4k3
f4k3

Registriert seit: 15. Aug 2007
Ort: Nürnberg
313 Beiträge
 
Delphi 2007 Architect
 
#5

Re: Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 11:35
Zitat von mkinzler:
Dann sollte NO ACTION passend sein. Verhindert das Löschen von Datensätzen im Master, wenn dieser referenziert wird.
Merci ... ich hatte NO ACTION eigentlich anders interpretiert ... aber wär ja auch quatsch wenn nichts passiert ^^ xD

Nochmals Danke für die schnelle Hilfe

f4k3
Sascha
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.016 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

Re: Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 16:06
Das Verhalten von ON RESTRICT ist ja eigentlich das, was ein foreign key standardmäßig implementiert, von daher wäre eine explizite Angabe dieses Verhaltens redundant.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von mschaefer
mschaefer

Registriert seit: 4. Feb 2003
Ort: Hannover
2.032 Beiträge
 
Delphi 12 Athens
 
#7

Re: Referentielle Integrität | Firebird

  Alt 15. Mai 2009, 16:15
Code:

With Firebird, there is no difference

Some other SQL systems make a following distinction: NO ACTION means to allow the change if the new value in the child table is still valid after statement and all the triggers are completed (i.e. still found in the parent table of the relationship), while RESTRICT means that changing the value is not allowed at all (no change or delete is allowed if there are child records).

This is implemented in such way that NO ACTION constraint rules are checked after all other operation, and RESTRICT is checked before any other operation. In current Firebird versions, both keywords are implemented as NO ACTION.
aus: http://www.firebirdfaq.org/faq338/

Grüße // Martin
Martin Schaefer
Phaeno
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:31 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz