Access & mariaDB - wo werden Tabellenbeziehungen gespeichert?

[jacons]

Hallo,

ich experimentiere gerade mit Access als Frontend für eine lokale mariaDB. Die Verbindung zur DB via ODBC steht.
Grundsätzlich möchte ich erreichen, dass alle DB-spezifischen Informationen (Tabellenstrukturen und -beziehungen, Daten natürlich sowieso) in der mariaDB, also nicht irgendwo im Frontend gepeichert werden.

Lege ich mit DBeaver Beziehungen (als Virtual ForeignKey) an, sehe ich die beim anschließenden Öffnen auch in Access. Aber - ich sehe sie nicht in phpMyAdmin?

Lege ich in Access Beziehungen an, sehe ich diese anschließend weder in DBeaver noch phpMyAdmin (ja, dort ist 'Beziehungen zeigen' aktiv).

Im Moment bin ich relativ verwirrt und hoffe auf den ein oder anderen Hinweis, wie und wo die Tabellenbeziehungenn gespeichert werden.

P.S. Das Captcha hier weist ständig meine Eingabe zurück (ca. 10 Versuche) obwohl ich sicher bin, dass alles richtig war?

[ebs17]

Beziehungen sind Datenbankobjekte wie Tabellen und können nur zwischen Realtabellen erstellt werden und also dort wirken. Also ausschließlich im Backend.

Access ahmt Beziehungen nach und zeigt solche Kopien auch gern im Frontend. Auch wird es im Abfrageeditor solche Beziehungen als Verknüpfungen für Abfragen vorbelegen (was oft sinnvoll ist).

Fremdschlüssel in PHPMyAdmin eintragen

[PhilS]

Grundsätzlich möchte ich erreichen, dass alle DB-spezifischen Informationen (Tabellenstrukturen und -beziehungen, Daten natürlich sowieso) in der mariaDB, also nicht irgendwo im Frontend gepeichert werden.


Lege ich mit DBeaver Beziehungen (als Virtual ForeignKey) an, sehe ich die beim anschließenden Öffnen auch in Access. Aber - ich sehe sie nicht in phpMyAdmin?

Generell musst du alle Änderungen an Datenstrukturen (Tabellen, Indizes, Constraints inkl. Foreign Keys) in der MariaDB vornehmen.
Die meisten Änderungen an Datenstrukturen sind im Access-Frontend gar nicht möglich. Die wenigen die möglich sind, betreffen dann nur das Frontend und gehen verloren, wenn du die Tabellen neu verknüpfst.

Was meinst du mit "Virtual ForeignKey"?
Ob MariaDB echte Foreign Keys (Referenzielle Integrität) unterstützt, hängt von der Storage Engine der Tabellen ab. Die InnoDB Storage Engine (Standard bei MariaDB) unterstützt FKs, die MyIsam Storage Engine, die oft in Datenbanken vorkommt, die von MySql migriert wurden, unterstützt keine echten FKs.

[markusxy]

Lege ich mit DBeaver Beziehungen (als Virtual ForeignKey) an, sehe ich die beim anschließenden Öffnen auch in Access.

Wo siehst du sie in Access?
Unter Datenbanktools -> Beziehungen?
Grundsätzlich sollte klar sein, dass man bei Nutzung eines aktiven Servers Abfragen nicht in Access erstellen sollte - weil man dadurch den Hauptvorteil des Servers verliert - , sondern zentral am Server und damit sind die Beziehungen innerhalb von Access auch nicht wirklich wichtig.
Aber abgesehen davon ist das Auslesen von Beziehungen nicht einheitlich und somit müsste Access das für jeden Server "wissen" was keinen Sinn macht. Beim MS SQL Server werden zumindest auch keine Beziehungen im Access Frontend angezeigt.

Die Frage ist also, wozu du die Info außerhalb des Servers überhaupt benötigst.

[PhilS]

Aber abgesehen davon ist das Auslesen von Beziehungen nicht einheitlich und somit müsste Access das für jeden Server "wissen" was keinen Sinn macht.

Sinn machen würde es zu rein informativen Zwecken im Beziehungs- und Abfragefenster durchaus.
Eigentlich sollte es für jedes ODBC 1.0 kompatibles Backend auch einheitlich möglich sein die Fremdschlüssel zu ermitteln. (ODBC API: SQLForeignKeys Function)

[markusxy]

Eigentlich sollte es für jedes ODBC 1.0 kompatibles Backend auch einheitlich möglich sein die Fremdschlüssel zu ermitteln.

Aha - also es gibt dafür einen eigenen Standard - danke dafür.
Was bedeutet das nun, für die Praxis?
Muss der Treiber das zur Verfügung stellen bzw. kann eine Anwendung prüfen, ob der Treiber die Infos liefert damit man die Infos abrufen kann, oder wie soll man sich das vorstellen?

[PhilS]

Muss der Treiber das zur Verfügung stellen bzw. kann eine Anwendung prüfen, ob der Treiber die Infos liefert damit man die Infos abrufen kann, oder wie soll man sich das vorstellen?

Das ist eine gute Frage, die ich erst jetzt, nach einen Blick in die Doku, beantworten kann.

Disclaimer: Ich habe nie praktisch einen ODBC-Treiber oder Client auf ODBC-API-Ebene implementiert. Die folgenden Informationen basieren nur auf der Dokumentation des ODBC-Standards. Meine Erfahrungen mit anderen Standards und deren Implementierungen legen nahe, dass zwischen dem Standard "auf Papier" und seinen tatsächlichen Implementierungen erhebliche Abweichungen bestehen können.


Ich war bei meinem vorigen Posting davon ausgegangen, dass jeder Treiber die SQLForeignKeys Function implementieren muss, weil sie bereits im ODBC 1.0 Standard definiert ist. - So einfach ist es aber nicht.

Es gibt verschiedene ODBC Interface Conformance Levels, die beschreiben, was ein Treiber innerhalb einer ODBC-Standard-Version genau implementiert.  Die SQLForeignKeys Function wird erst in der höchsten Konformitätsstufe (Level 2 Interface Conformance) verlangt. Man muss also davon ausgehen, dass viele Treiber die Funktion nicht unterstützen. Das ist sicherlich der Grund warum Access die Informationen über FKs nicht abruft/anzeigt.

Eine Anwendung, die ODBC-Datenquellen nutzt, kann die SQLGetInfo Function aufrufen, um genauer zu erfahren, was der jeweilige ODBC-Treiber unterstützt. Im ODBC Standard 1.0 ist da aber nur SQL_ODBC_VER vorgesehen, um die genaue Version des unterstützten Standards abzufragen, aber eben nicht das o.a. Konformitätslevel. Erst mit ODBC 3.0 ist als Argument für SQLGetInfo auch SQL_ODBC_INTERFACE_CONFORMANCE vorgesehen, mit dem man nun das Konformitätslevel  abfragen kann.
Vorher, ohne diese genau Abfrage, war es wohl nur über Trial&Error möglich festzustellen, ob ein Treiber das unterstützt oder nicht.

Fazit:
Eine Anwendung wie Access, die schon ewig möglichst viele ODBC-Treiber unterstützen möchte, ist wahrscheinlich so implementiert, dass sie auf alle nicht zwingend erforderlichen Informationen verzichtet. Damit dürfte geklärt sein, warum Access diese Informationen bisher nicht anzeigt.

[markusxy]

Ich habe nie praktisch einen ODBC-Treiber oder Client auf ODBC-API-Ebene implementiert.

Na ja, ich natürlich auch nicht, daher meine Fragen dazu.
Ich hätte jetzt mal angenommen, dass praktisch jeder Treiber diese API-Schnittstelle des Servers nutzt um auf eine Datenbank zuzugreifen und dann wiederum eine weitere standardisierte Schicht zur Verfügung stellt, die z.B. DAO nutzen kann.
Interessant aus Anwendersicht wäre ja nur, ob ein Treiber eine standardisierte Schnittstelle zur Verfügung stellt, die man per SQL nutzen kann um auf diese Werte zuzugreifen. Ansonsten bleibt mir immer nur der direkte Zugriff auf die Systemtabellen, der dann bei jedem DB-Server System anders aussieht. Dafür ist man dann natürlich unabhängig.

[PhilS]

Ich hätte jetzt mal angenommen, dass praktisch jeder Treiber diese API-Schnittstelle des Servers nutzt um auf eine Datenbank zuzugreifen und dann wiederum eine weitere standardisierte Schicht zur Verfügung stellt, die z.B. DAO nutzen kann.
 Interessant aus Anwendersicht wäre ja nur, ob ein Treiber eine standardisierte Schnittstelle zur Verfügung stellt, die man per SQL nutzen kann um auf diese Werte zuzugreifen.

ODBC ist keine Schnittstelle des Servers! ODBC wird von einer DLL auf dem Client implementiert (dem ODBC-Treiber), der nach aussen hin für Anwendungen (z.B. Access) die Funktionen aus dem ODBC-Standard zur Verfügung stellt. Intern kommuniziert der ODBC-Treiber mit dem Server so wie es im beliebt bzw. wie es der Server versteht. Das ist allein Sache des jeweiligen Anbieters von Server und/oder ODBC-Treiber.
ODBC ist die standardisierte Schicht, die z.B. DAO nutzt!
Der Treiber stellt also eine standardisierte Schnittstelle zur Verfügung. - Die ODBC-Schicht. - Nur kannst du sie nicht per SQL nutzen, sondern nur per C(++), oder wenn du willst auch per VBA über API-Declares.

Ansonsten bleibt mir immer nur der direkte Zugriff auf die Systemtabellen, der dann bei jedem DB-Server System anders aussieht.

Anstelle von proprietären Systemtabellen sollte man möglichst die INFORMATION_SCHEMA Views verwenden, die im SQL-Standard standardisiert sind. - Ob, wie und in welchem Umfang diese unterstützt werden, ist wieder eine andere Frage.

[jacons]

Was meinst du mit "Virtual ForeignKey"?

So werden In Dbeaver die Fremdschlüssel genannt, wenn man Beziehungen im ER-Diagramm 'zeichnet'. Denn daneben gibt es aber auch 'normale' ForeignKeay, die man nicht zeichnet sondern ähnlich wie in phpMyAdmin anlegt.

DBeaver nutze ich ganz neu, wegen eben dem ER-Diagramm, dass Heidi-SQL fehlt und bin auch hier noch beim Lernen.

Grundsätzlich finde ich das Zeichnen von Beziehungen im Diagramm - wie ich es aus Access kenne - sehr intuitiv, aber wenn es daneben noch diese textorientierte Methode über Masken gibt, wird das ja sicher seine Gründe haben.

[jacons]

Wo siehst du sie in Access?
Unter Datenbanktools -> Beziehungen?
Grundsätzlich sollte klar sein, dass man bei Nutzung eines aktiven Servers Abfragen nicht in Access erstellen sollte - weil man dadurch den Hauptvorteil des Servers verliert - , sondern zentral am Server

Genau, unter Datenbank-Beziehungen im Access-ER-Diagramm. Nur erschließt  sich mir mit Einsteigerkenntnissen in DB-Programmierung eben nicht, WO Access die dort angelegten Beziehungen abspeichert.
Wie ich hier nun erfahre, offenbar irgendwo im eigenen Frontend. Das das nicht sinnvoll ist leuchtet mir total ein.

Ich hab kapiert, dass Access als MySQL-Frontend nur zum reinen Datenhandling (Aus-, Eingabe) eingesetzt werden sollte, während alle Arbeiten an der DB-Struktur auf dem Server via z.B. phpMyAdmin oder evtl. auch DBeaver erfolgen sollte.

Danke!

[jacons]

Vielen Dank auch für den interessanten Austausch zu Treiberfragen und Abstraktionsschichten. Ist immer cool, wenn man dazulernen kann, auch wenn es meinen Horizont übersteigt. 

[markusxy]

während alle Arbeiten an der DB-Struktur auf dem Server via z.B. phpMyAdmin oder evtl. auch DBeaver erfolgen sollte.

Strukturänderungen sind ja auch reine SQL Anweisungen.

Die kann von überall aus absetzen. Ich erzeuge alle Objekte und Änderungen in direkten SQL Anweisungen und speichere die in einem Script, da Einspielungen in ein Live-System nur wenige Sekunden in Anspruch nehmen sollten - auch wenn das hunderte Änderungen betrifft.
Da sollte man ein entsprechendes Tool haben, welches einen beim Entwickeln entsprechend unterstützt. Aber dazu würdest du natürlich in entsprechenden Mysql Foren mehr erfahren.

[markusxy]

INFORMATION_SCHEMA Views verwenden, die im SQL-Standard standardisiert sind

Spannend, hab ich noch nie verwendet, sondern immer nur den direkten Zugriff auf die Tabellen.