Bestehende Access-DB, geplante MySQL, Konzept

[Elya]

Hallo,

es ist kein konkretes Einzelproblem, sondern eher die Bitte um Hilfe bei einem Brainstorming. Wir haben auf der einen Seite eine Access Datenbank mit einem recht komplexen/komfortablen Access-Frontend im LAN liegen, mit diversen Office-Schnittstellen, Dokumentenverwaltung etc. Zusätzlich haben wir einen immer komplexer werdenden Webauftritt, der ebenfalls datenbankbasiert arbeitet (LAMP). Diese beiden Bereiche sollen DB-technisch zusammengeführt werden, um redundanten Datenpools und permanente Datenabgleichen ein Ende zu bereiten. Unsere Kompetenzen liegen eher im Bereich LAMP, die Accessprogrammierer sind aber mit im Boot.

Stellt sich die Frage, wie man da besser angeht: Die vorhandene Access DB ins Web stellen und mit ODBC drauf zugreifen, oder die DB komplett in MySQL neu aufbauen und dann mit dem Access-Frontend darauf zugreifen, oder Teile so, Teile so (igitt ;-) ) ... ODBC generell - Bedenken? Alternativen?

Es gibt durchaus sicherheitsrelevante Daten dabei, wobei wir da sehr viele Einflußmöglichkeiten beim Aufbau des Netzwerkes haben, also mitentscheiden können, wo im Netz die DB steht usw.

Geschwindigkeit im Datenzugriff ist natürlich auch eine wichtige Sache, besonders bei den Office-Anwendungen. Welche Erfahrungswerte gibt es da?

Ich bin keine DB-Programmiererin, sondern sammele vorerst Argumente für die kompetente Kundenberatung.

Wer hat ein paar Gedanken/Ideen dazu?

Danke und Gruss aus Koeln-Ehrenfeld,

Elya

[Rouven]

Hallo!

es ist kein konkretes Einzelproblem, sondern eher die Bitte um Hilfe bei einem Brainstorming. Wir haben auf der einen Seite eine Access Datenbank mit einem recht komplexen/komfortablen Access-Frontend im LAN liegen, mit diversen Office-Schnittstellen, Dokumentenverwaltung etc. Zusätzlich haben wir einen immer komplexer werdenden Webauftritt, der ebenfalls datenbankbasiert arbeitet (LAMP). Diese beiden Bereiche sollen DB-technisch zusammengeführt werden, um redundanten Datenpools und permanente Datenabgleichen ein Ende zu bereiten. Unsere Kompetenzen liegen eher im Bereich LAMP, die Accessprogrammierer sind aber mit im Boot.

Permanentes Datenabgleichen ist sicherlich keine sonderlich stabile Lösung bzw. erfordert Performance.

Stellt sich die Frage, wie man da besser angeht: Die vorhandene Access DB ins Web stellen und mit ODBC drauf zugreifen, oder die DB komplett in MySQL neu aufbauen und dann mit dem Access-Frontend darauf zugreifen, oder Teile so, Teile so (igitt ;-) ) ... ODBC generell - Bedenken? Alternativen?

Ein einheitliches Konzept ist denke ich die sinnvollere Alternative. Die ODBC-Schnittstellen dürfte - wenn die Access-Datenbank bisher euren Performance-Ansprüchen genügt hat - nicht wesentlich schlechter sein. Allerdings ist die Frage, wie lange Access einer Belastung standhalten kann, meine Erfahrungen sind da spätestens ab 6-stelligen Datensatzzahlen nicht mehr so gut.
Ich wäre für einen Neuaufbau in MySQL, gleichzeitig eine weitestgehende Umstellung auf eine neue Oberflächentechnik (z.B. Browserzugriff). Das bereitet zwar einmalig Arbeit, vor allem das Importieren der alten Daten, aber danach ist das Programm
a) einheitlich
b) erfordert (bei Web) keine Einrichtung von Client-Programmen
c) ist, je nach Webserver, auch außerhalb zugreifbar
Gerade ODBC erfordert auch immer eine Treibereinrichtung, d.h. ein Access-Frontend bräuchte Access, die Datenbank mit der Oberfläche UND einen Treiber für die MySQL-Datenbank. Anders herum bräuchte eine Weboberfläche auch immer einen ODBC-Treiber um auf die langsame Access-DB zuzugreifen. Also ich denke, einheitlich ist die Lösung in jedem Fall besser.

MfG
Rouven

[Elya]

Hallo Rouven,
Danke für's Antworten.

Permanentes Datenabgleichen ist sicherlich keine sonderlich stabile Lösung bzw. erfordert Performance.

klar.

Ein einheitliches Konzept ist denke ich die sinnvollere Alternative. Die ODBC-Schnittstellen dürfte - wenn die Access-Datenbank bisher euren Performance-Ansprüchen genügt hat - nicht wesentlich schlechter sein. Allerdings ist die Frage, wie lange Access einer Belastung standhalten kann, meine Erfahrungen sind da spätestens ab 6-stelligen Datensatzzahlen nicht mehr so gut.

das kann noch wachsen.

Ich wäre für einen Neuaufbau in MySQL, gleichzeitig eine weitestgehende Umstellung auf eine neue Oberflächentechnik (z.B. Browserzugriff).

Genau das wollten wir, die vorhandene Access-anwendung ist jedoch sehr ausgereift und bietet einige Microsoft/Officespezifische Gimmicks, die mit PHP und Browserseitig nicht so einfach zu machen sind. Außerdem bei jedem DB-Zugriff ein Neuaufbau von Seiten - es spricht einiges dafür, für den Office Bereich das Access-Frontend weiter zu benutzen.

a) einheitlich
b) erfordert (bei Web) keine Einrichtung von Client-Programmen
c) ist, je nach Webserver, auch außerhalb zugreifbar

klar. Da hätten wir auch schön und reichlich mit zu tun, steht aber vermutlich nicht zur Debatte.

Gerade ODBC erfordert auch immer eine Treibereinrichtung, d.h. ein Access-Frontend bräuchte Access, die Datenbank mit der Oberfläche UND einen Treiber für die MySQL-Datenbank. Anders herum bräuchte eine Weboberfläche auch immer einen ODBC-Treiber um auf die langsame Access-DB zuzugreifen. Also ich denke, einheitlich ist die Lösung in jedem Fall besser.

Das erstere versteh ich nicht: Access-DB _und_ MySQL DB? Kann ich nicht von der Access-Anwendung auf die MySQL-DB zugreifen?

Gruss aus Koeln-Ehrenfeld,

Elya

[Axel Richter]

Hallo Elya,

Genau das wollten wir, die vorhandene Access-anwendung ist jedoch sehr ausgereift und bietet einige Microsoft/Officespezifische Gimmicks, die mit PHP und Browserseitig nicht so einfach zu machen sind. Außerdem bei jedem DB-Zugriff ein Neuaufbau von Seiten - es spricht einiges dafür, für den Office Bereich das Access-Frontend weiter zu benutzen.
Das erstere versteh ich nicht: Access-DB _und_ MySQL DB? Kann ich nicht von der Access-Anwendung auf die MySQL-DB zugreifen?

Ja, aber auch nur über ODBC. Es gibt einen MySQL-ODBC-Treiber http://www.mysql.com/doc/en/ODBC.html. Über den und die Tabellen-Verknüpfungs-Funktionalität des Access kannst Du MySQL-Tabellen in die Access-Tabellensammlung verknüpfen. Wenn die Tabellenstruktur ähnlich bis identisch ist, kannst Du sogar vorhandenen Abfragen und Formulare weiter benutzen.

viele Grüße

Axel

[Tom]

Hello,

man wird pauschal gar keine Antwort geben können hierzu.

Allerdings sehe ich bei Internetanwendungen immer den Aspekt der Sicherheit, und der ist eben nicht gewährleistet. Alle Daten gehören eben nicht ins Weltnetz!

Ich würde also ersteinmal mit einem Workflow- und Dataflow-Konzept beginnen. Die Arbeitsprozesse sollten einer genauen Untersuchung unterworfen werden, welche Daten wo anfallen und wer darauf wann in Echtzeit zugreifen können muss. Wenn der Betrieb größer ist, ist es i.d.R. gar nicht erwünscht, dass jeder alles weiß.

Dementsprechend muss auch die Datenbankwelt aufgeteilt werden. Die kaufmännische Applikation muss sicher die Daten bereitstellen. Die Publikumsschnittstelle muss diese dann zur Verfügung gestellt bekommen. Und dann würde ich mir überlgen, ob der Abgleich zwischen diesen zwei Welten nicht z.B. zweimal am Tag gezielt automatisiert angestoßen werden könnte.

Den Ersatz eines interaktiven Access-Frontends (wenn es denn gut ist) durch eine Browser-Lösung halte ich für eine Utopie der besonderen Art. Browser haben noch lange nicht die technischen Möglichkeiten erreicht, die "normale" Programme haben. Alleine der Ersatz eines verbindungsorientierten Protokolls durch HTTP bringt schon soviele Einschränkungen mit sich...

Liebe Grüße aus http://www.braunschweig.de

Tom