2
Access Grenzen bzw. Entscheidungskriterien
Hallo zusammen,
ich will in diesem Forum die Access Praktiker um einen Rat bitten.
Momentan betreibe ich eine Web-Applikation mit folgenden Parametern:
-Webserver auf Windows NT (IIS)
-freie, indizierte FoxPro Tabellen
-es gibt gleichermaßen lesende und schreibende Zugriffe
-jede Tabelle hat augenblicklich weniger als 100.000 Datensätze
-Datenvolumen ca. 700 MB
-auf diese Tabellen wird mit ODBC (ADO) und ASP Skripte zugegriffen
-Backup durch zip-Files, die per FTP verteilt werden.
-zw. 20-30 User
Durch Funktionen der Applikation selbst ist kein Field-, Record- oder
Table-Locking notwendig. Es gibt keine Stored Procedures, kein Rollback-
anforderungen usw... Die Datenbank ist nur ein 'Datenspeicher'.
Auf dem Server läuft jede Nacht ein Prozess, der ca. 750.000 SQL Befehle
direkt über ODBC absetzt.
Diese Umgebung ist sehr stabil (Downtime < 3Std./Jahr), kein booten
einer 'Datenbank' nötig, sehr schnell, also soweit alles prima!
Diese Umgebung hat zwei Haken:
1. veraltetes NT
2. aus politischen Gründen sollte eher SQL Server oder Oracle anstatt
FoxPro eingesetzt werden
Vorallem Punkt 2 wird immer wichtiger, da freie Tabellen nix kosten
und somit auch nichts taugen können
Als weitere Herausforderung kommt jetzt
noch der tägliche Import von 70.000 Records/Nacht hinzu.
Um den Umstieg nicht zu hart machen zu müssen, wollte ich Access auf
Windows 2003 Webedition per ASP-Skripte inkl. ODBC als Zwischenschritt einführen.
MySQL könnte ich nur über ODBC verwenden, da ich nicht ASP gegen PHP tauschen wollte.
Meine Fragen:
Gibt es durch oben beschriebenes ein KO Kriterium für Access?
Ich hörte, dass bei älteren Access Versionen es irreparable Abstürze bei Datenbanken
größer 2GB gab. Wie ist das heute? Müsst ihr Access Dateien häufig reparieren?
Hat man irgendwann einen abgeschlossenen Datenklumpen?
Wie sind die Zugriffszeiten per ODBC? Ich lass, dass sich das alte ADO noch ganz gut schlägt.
Oder ist DAO vorzuziehen?
Kann im laufenden Betrieb ein Backup für einen entfernten anderen Webserver erstellt werden?
Gibt es in Access eine Verschachtelungsgrenze für SQL-Befehle (nested SQLs)?
Vielleicht kann mir jemand zu einer oder anderen Frage einen Hinweis geben.
Vielen Dank im Voraus.
Gruss
ich will in diesem Forum die Access Praktiker um einen Rat bitten.
Momentan betreibe ich eine Web-Applikation mit folgenden Parametern:
-Webserver auf Windows NT (IIS)
-freie, indizierte FoxPro Tabellen
-es gibt gleichermaßen lesende und schreibende Zugriffe
-jede Tabelle hat augenblicklich weniger als 100.000 Datensätze
-Datenvolumen ca. 700 MB
-auf diese Tabellen wird mit ODBC (ADO) und ASP Skripte zugegriffen
-Backup durch zip-Files, die per FTP verteilt werden.
-zw. 20-30 User
Durch Funktionen der Applikation selbst ist kein Field-, Record- oder
Table-Locking notwendig. Es gibt keine Stored Procedures, kein Rollback-
anforderungen usw... Die Datenbank ist nur ein 'Datenspeicher'.
Auf dem Server läuft jede Nacht ein Prozess, der ca. 750.000 SQL Befehle
direkt über ODBC absetzt.
Diese Umgebung ist sehr stabil (Downtime < 3Std./Jahr), kein booten
einer 'Datenbank' nötig, sehr schnell, also soweit alles prima!
Diese Umgebung hat zwei Haken:
1. veraltetes NT
2. aus politischen Gründen sollte eher SQL Server oder Oracle anstatt
FoxPro eingesetzt werden
Vorallem Punkt 2 wird immer wichtiger, da freie Tabellen nix kosten
und somit auch nichts taugen können
Als weitere Herausforderung kommt jetzt
noch der tägliche Import von 70.000 Records/Nacht hinzu.
Um den Umstieg nicht zu hart machen zu müssen, wollte ich Access auf
Windows 2003 Webedition per ASP-Skripte inkl. ODBC als Zwischenschritt einführen.
MySQL könnte ich nur über ODBC verwenden, da ich nicht ASP gegen PHP tauschen wollte.
Meine Fragen:
Gibt es durch oben beschriebenes ein KO Kriterium für Access?
Ich hörte, dass bei älteren Access Versionen es irreparable Abstürze bei Datenbanken
größer 2GB gab. Wie ist das heute? Müsst ihr Access Dateien häufig reparieren?
Hat man irgendwann einen abgeschlossenen Datenklumpen?
Wie sind die Zugriffszeiten per ODBC? Ich lass, dass sich das alte ADO noch ganz gut schlägt.
Oder ist DAO vorzuziehen?
Kann im laufenden Betrieb ein Backup für einen entfernten anderen Webserver erstellt werden?
Gibt es in Access eine Verschachtelungsgrenze für SQL-Befehle (nested SQLs)?
Vielleicht kann mir jemand zu einer oder anderen Frage einen Hinweis geben.
Vielen Dank im Voraus.
Gruss
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 69800
Url: https://administrator.de/contentid/69800
Ausgedruckt am: 25.11.2024 um 08:11 Uhr
2 Kommentare
Neuester Kommentar
Moin zoro17,
ich gehöre nicht zu den Praktikern, die Erfahrungen mit "einer 700MB-M$ACCESS-Datenbank genutzt von 20-30 Usern" gesammelt haben.
Möchte aber auch nicht zu dieser Gruppe gehören.
Weil für mich eindeutig Killerkriterien wären:
Genau genommen solltest gerade Du als Admin auf die Unvertretbarkeit einer *.mdb-Krücke hinweisen - schriftlich und mit dem Zusatz "....ein produktiver störungsfreier Produktivbetrieb kann unter diesen Umständen nicht gewährleistet werden".
Grüße
Biber
ich gehöre nicht zu den Praktikern, die Erfahrungen mit "einer 700MB-M$ACCESS-Datenbank genutzt von 20-30 Usern" gesammelt haben.
Möchte aber auch nicht zu dieser Gruppe gehören.
Weil für mich eindeutig Killerkriterien wären:
- M$-Access ist vertretbar für eine Einzelplatz-Weinkellerverwaltung. Never never never für eine produktive Gruppen/Team/OE-Datenbank.
- denn es gibt ja eben KEINE DB-Engine, die Locking, Rollback/Fallback, Backup, Logging oder Optimizing übernehmen kann--->UNVERTRETBAR!
- eine "kaputte" Access-DB ist nur ein wertloser Datenklumpen --- schlimmer ist, das ich erstens schon mehrere "kaputte" *.mdb's gesehen habe und zweitens in weniger als 20% Prozent der Fälle gesichert vermuten kann, wie es dazu kam. Andersherum: in 80% der Fälle weiß ich nicht genau die Fehlerursache ("nicht reproduzierbar") und kann entsprechend da nicht gegensteuern oder vorsorgen. ----> DAS IST EIN K-O.-Kriterium.
- ACCESS' SQL ist ebensowenig "Standard-SQL" wie das SQL irgendeines anderen DBMS. Aber: Access UNTERbietet jegliches andere SQL. Du fühlst dich damit wie mit einem Fiat Panda auf einem Dragster-Rennen.
- Und Deine bisherige Mimik des Backups mit "ZIP-Files per FTP deployed" ---das willst Du doch nicht etwa in 2 Jahren immer noch erzählen müssen??? Auch das wäre ein Grund, eine ACCESS-"Datenspeicher"-Schmalspurlösung abzulehnen.
Genau genommen solltest gerade Du als Admin auf die Unvertretbarkeit einer *.mdb-Krücke hinweisen - schriftlich und mit dem Zusatz "....ein produktiver störungsfreier Produktivbetrieb kann unter diesen Umständen nicht gewährleistet werden".
Grüße
Biber
Hallo Biber,
vielen Dank für Deine schnelle Antwort!
Sie entspricht etwa dem, was ich erwartet habe. Leider.
Gedanklich bin ich auch schon an einer MySQL oder SQL Server Lösung.
Oracle kommt für mich nicht in Frage, da meine User unter einer Oracle Application Lösung sehr zu leiden haben.
Gerade Dein Hinweis, dass es für ca. 80% der Datenklumpenprobleme keine genauen Ursachen gibt, hat mein Bauchgefühl bestätigt.
Ich könnte aber Access als Importhilfe für MySQL oder SQL Server nutzen, da meines Wissens FoxPro nicht direkt nach MySQL geht.
Ich weiss nicht genau, wozu Access geplant war. Vielleicht doch nur zum privaten Office Gebrauch.
Schaut man aber sich die vielschichtige Literatur an, da könnte man meinen, Access wäre zu höherem geeignet.
Vielleicht kann jemand noch etwas dazu sagen.
Danke und Gruss
vielen Dank für Deine schnelle Antwort!
Sie entspricht etwa dem, was ich erwartet habe. Leider.
Gedanklich bin ich auch schon an einer MySQL oder SQL Server Lösung.
Oracle kommt für mich nicht in Frage, da meine User unter einer Oracle Application Lösung sehr zu leiden haben.
Gerade Dein Hinweis, dass es für ca. 80% der Datenklumpenprobleme keine genauen Ursachen gibt, hat mein Bauchgefühl bestätigt.
Ich könnte aber Access als Importhilfe für MySQL oder SQL Server nutzen, da meines Wissens FoxPro nicht direkt nach MySQL geht.
Ich weiss nicht genau, wozu Access geplant war. Vielleicht doch nur zum privaten Office Gebrauch.
Schaut man aber sich die vielschichtige Literatur an, da könnte man meinen, Access wäre zu höherem geeignet.
Vielleicht kann jemand noch etwas dazu sagen.
Danke und Gruss
