AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Beziehungen in Acces DBs nötig
Thema durchsuchen
Ansicht
Themen-Optionen

Beziehungen in Acces DBs nötig

Ein Thema von glunzl · begonnen am 3. Jan 2005 · letzter Beitrag vom 3. Jan 2005
Antwort Antwort
Benutzerbild von glunzl
glunzl

Registriert seit: 21. Mär 2004
Ort: Reinbek
119 Beiträge
 
Delphi 7 Professional
 
#1

Beziehungen in Acces DBs nötig

  Alt 3. Jan 2005, 06:10
Hallo Leute!

Ich habe ein wenig mit Access und dann mit Access Tabellen in Delphi 7 rumexperimentiert. Jetzt frage ich mich, ob die die Beziehungen in der Access DB eigentlich brauche, wenn ich mit einer ADO Connection auf die DB zugreife, oder ob ich die mit einer Query/SQL Query "dynamisch" erzeuge?`

Gruss
glunzl
Michael
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

Re: Beziehungen in Acces DBs nötig

  Alt 3. Jan 2005, 08:47
Moin glunzl,

Beziehungen dienen eigentlich der Refrenziellen Integrität. Ein Beispiel:

Tabellen:

Bestellungen
- Kunde_ID
- Artikel_ID

In diese Felder soll geweils die ID des Kunden und des Artikels eingetragen werden.
Dabei ist es sinnvoll, keine Kunden oder Artikel einzutragen, die es garnicht gibt.
Also setze ich eine Beziehung zwischen Bestellungen und Kunden bzw Artikeln.
Dies ist dann eine 1-zu-n-Beziehung, weil ja ein Artikel in n Bestellungen
vorkommen kann; genauso mit den Kunden...

Durch eine Query kannst du keine Beziehungen in diesem Sinne erzeugen. Du setzt sie nur sinnvoll
um, indem du zum Bespiel folgendes machst:
SQL-Code:
select kundenname, artikelname
from bestellungen b, kunden k, artikel a
where b.kunde_id = k.kunde_id
and b.artikel_id = a.artikel_id
Hier listest du alle Bestellungen mit Name von Kunden und Artikel auf.

Hoffe, dir geholfen zu haben
MfG
Stevie
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

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

Registriert seit: 11. Apr 2003
Ort: Moestroff (Luxemburg)
3.741 Beiträge
 
Delphi 2007 Professional
 
#3

Re: Beziehungen in Acces DBs nötig

  Alt 3. Jan 2005, 09:19
Beziehungen sind auch als "Foreign Keys" bekannt. Normalerweise wird bei Erstellung einer Beziehung gleich ein Sekundärindex mit angelegt, welcher das Suchen und Filtern dann erheblich beschleunigt.

Darüberhinaus kann man auch das Verhalten definieren, ob Masterrecords gelöscht werden dürfen oder nicht. Und wenn ja, daß die Records aus der referierenden Tabelle mitgelöscht werden, damit keine Dateileichen übrig bleiben. Um das Bsp. von Stevie nochmal aufzugreifen, ist es an der Datenbank zu entscheiden, was mit den Records in der Tabelle Artikel passieren soll, wenn du den zugehörigen Kunden löschst. Entweder es wird direkt verboten, oder es ist erlaubt, und alle betroffenen Artikeldatensätze werden mitgelöscht (cascading delete).

Somit brauchst du dich als Entwickler nicht um die Datenkonsistenz kümmern, sondern das übernimmt die Datenbank für dich... Es sei denn du nutzt MySQL im Standard MyISAM Betrieb, da gibts diese Sicherheit nicht. Dafür müsstest du InnoDB als Tabellentyp wählen, der steht aber nicht unter Opensource und ist lizenzpflichtig... Bei Access hast du diese Probleme nicht.
  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 02:10 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