Mailinglisten-Archive |
Andreas Kretschmer schrieb: > > am Sat, dem 10.03.2001, um 17:31:18 +0100 mailte ulli folgendes: > > ich plane den Einsatz von MySQL auf NT4 Server als Backend für 45 > > WIN98-Clients mit einem A2k-Runtime Programm. > > > > Jetzt steht in den Dokumentationen immer, Access wäre das ideale Frontend > > für MySQL, bzw. umgekehrt MySQL ist das beste Backend für Access-Frontends. > > Leider habe ich aber im Internet bisher so gut wie keine Manuals gefunden, > > wie man die Programme optimal aufeinander anpasst :-( Wir setzen für die Entwicklung von Frontends Delphi ein und greifen über die BDE (Datenbankschnittstelle) und ODBC-Treiber auf auf MySQL zu. Die Performance ist auch bei größeren Datenmengen (bis zu 60.000 Datensätzen) und einem Zugriff von 5 Standorten auf einen zentralen Server zufriedenstellend. > > Was ist mit SubSelect-Abfragen? Angeblich funktionieren die ja in MySQL > > nicht. > > Wenn ich aber eine Access-Abfrage mit einer anderen Abfrage als Datenquelle > > ausführe -> funktioniert! > > MySQL kann das (noch) nicht. Wenn das mit Access als Frontend geht (nie > getestet), dann macht vermutlich der ODBC-Treiber einen Join draus. > Subselect-Abfragen funktionieren in MySQL tatsächlich nicht und der ODBC-Treiber akzeptiert sie auch nicht. Eine automatische Umwandlung in JOINS findet nicht statt. Je nach Problem muß man sich mit dem Erzeugen einer neuen Tabelle über CREATE ... Select und anschließendem additiven Insert into ... Select und einer Endabfrage oder einem Join behelfen. Der Programmieraufwand ist zwar größer, aber das Laufzeitverhalten ist sehr gut. > > Was ist mit Beziehungen zwischen Tabellen? Muss man die in jedem SQL-Befehl > > definieren, oder lassen die sich mit dem Tabellendesign abspeichern wie > > unter Access? Wie realisiert man referenzielle Integrität? > > Da werd noch einer schlau draus. > > Referntielle Integrität ist noch nicht bei MySQL. Referenzielle Integrität gibt es tatsächlich nicht, ist m.E. aber auch nicht notwendig. Gebraucht werden könnte sie z.B. beim Löschen von Datensätzen. Ohne implementiertes (d.h. in MySQL selbst) cascadierendes Löschen führt das aber nur zu einer Fehlermeldung, die dann behandelt werden muß. Also frage ich vor dem Löschen eines Datensatzes die möglichen Untertabellen anhand der Schlüsselnummer lieber gleich direkt ab, gebe entsprechende Meldungen aus und implementiere das cascadierende Löschen programmseitig selbst, da die Fehlerbehandlung im Fall der referentiellen Integrität auch nicht einfacher oder eleganter ist. Auch beim Anzeigen von Master-Detail-Relationen brauche ich mit Delphi die referenzielle Integrität nicht, da die Tabellen über vorhandene Indizes verknüpft werden können. Eine Möglichkeit. Eine andere besteht darin, anhand der Schlüsselnummern die Detaildatensätze zu recherchieren. Ich mache das z.B. in einer Anwendung, um zu vorhandenen Dokumenten die damit verknüpften Anwender zu suchen. Anhand der Schlüsselnummer suche ich in der Verknüpfungstabelle die Schlüsselnummern der Anwender und in der Anwendertabelle die weiteren Angaben. Das geht - auch über ODBC und Netz - bei einem durchschnittlichen Bestand von ca. 1.500 Anwendern und ca. 18.000 Verknüpfungen auf "Knopfdruck" ohne fühlbare Zeitverzögerung. MySQL ist schnell! Beim Eintragen eines neuen Unterdatensatzes wird beim Einsatz von verknüpften Tabellenobjekten unter Delphi die Schlüsselnummer des Master-Datensatzes automatisch in den Unterdatensatz eingetragen, d.h. eine explizite referentielle Integrität ist hier auch nicht notwendig. Bei nicht-verknüpften Tabellenobjekten oder reinen Ergebnismengen muß das programmseitig vorgenommen werden, was m.E. auch nicht weiter schwierig ist. Grüße Jürgen Schneider --- *** Weitere Infos zur Mailingliste und MySQL unter http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive