Vorteil SQL Datenbank?

[Braun_Thomas 10]

Liebe alle,

 

ich habe ein Problem. Ich bin Netzwerkadminstrator und kein Datenbankspezialist. Ein Kunde von mir verwendet eine Datenbanksystem für die Kundenverwaltung. Insgesamt sind es 15 Benutzer die damit arbeiten.

 

Soweit ich es sehe arbeitet die Datenbank auf mdb Daten bzw. Access. Auf den Clients ist auch die Access Runtime installiert und wenn ich mir den Server ansehe dann sind über 30 mdb und ldf Dateien im gleichzeitigen Zugriff. Die ganzen MDB Dateien die in der Verwendung sind haben größen bis zu 2 GB an Größe. Wenn ich alle MDB Dateien zusammenehme, komme ich auf eine Datenmenge von 50 GB.

 

Jetzt gibt es Probleme mit der Geschwindigkeit beim arbeiten in der Datenbank. Angeblich liegt es am Server.

 

Nach meinem bisherigen Verständniss ist es doch so, dass Clients auf den SQL Zugreifen und ihn "fragen" was sie wollen. Die Daten und die Berechnungen finden auf dem Server statt. Er gibt also nur die Infos an den Clients zurück, die der Client braucht.

 

Die Lösung des Problems soll jetzt sein, dass direkt auf dem Server gearbeitet werden soll (Remotesoftware, Terminal whatever). Das halte ich aber für einen Wahnsinn da neben der DB noch andere Dinge darauf laufen.

 

Sehe ich das jetzt falsch?

 

Was sind jetzt also die Signifikaten Unterschiede zwischen Access mdb und SQL in Bezug auf Verarbeitungsgeschwindigkeit??

 

Danke & beste Grüße

Thomas

[zahni 554]

Hallo,

 

ich verstehe die Frage nicht vollständig:

 

Die Anwendung verwendet Access -> verstanden

Willst Du nun alternativ auf einem SQL-Server umstellen, oder willst Du einen Terminalserver verwenden ?

 

Ja, ein richtiger SQL-Server schlägt Access um Längen.

Natürlich muss die Anwendung damit auch umgehen können.

Access ist in Multiuser-Umgebungen fast immer langsam.

 

-Zahni

[Dukel 454]

Wie macht ihr Backups mit der Access Datenbank?

[Braun_Thomas 10]

Hallo -Zahni,

 

entschuldige.

 

Also ich will gar nichts, ausser dass es natürlich schnell läuft.

 

Die Datenbank hat ein Datenbankspezialist geschrieben und installiert. Ich wollte mit ihm eine Lösung finden, stattdessen schrieb er der GL das es am Server und Netzwerk liegt.

 

Jetzt bin natürlich ich der Buhmann.

 

Das kann und will ich nicht auf mir sitzen lassen. Ich kannte bisher nur SQL bezogene Datenbanken wo es nie ein Thema war.

 

Wenn ich es richtig verstehe, dann liegt es natürlich an der Übertagungsgeschwindigkeit im Netzwerk wenn jedesmal riesige Datenmengen übertragen werden muss. Die Serverprozessoren langweilen sich nämlich die ganze Zeit wenn voll gearbeitet wird obwohl darauf noch eine ganze Menge anderes Zeugs läuft.

 

Ich bin der Meinung, dass ein Datenbankprogrammierer, ab dieser Userzahl und noch dazu bei den Datenmengen doch so kulant sein sollte, das Ding auf SQL zu übertragen und nicht seinen alten Stiefel weiterfahren. Ich meine diese Runtime Geschichte ist doch nur für ein paar User bzw. einen Desktop ausgelegt und über 10 Jahre alt.

 

Statdessen wird jetzt die Schuld woanders gesucht. Das finde ich unproduktiv. Ich will ihm ja nicht in die Suppe spucken, aber wenn er damit gleich zur GL läuft finde ich das unfair.

 

Ich muss also belegen können das es doch an der Architektur der Datenbank liegt. Im wesentlichen:

 

Ab wann sollte überlegt werden SQL zu verwenden. (Userzahl-Datenmengen)

 

Danke für die Hilfe!

Thomas

[Braun_Thomas 10]

Na das ist doch simple: Die Dateien sichern??

[Dukel 454]

Na das ist doch simple: Die Dateien sichern??

 

Während diese in Benutzung sind?

[Braun_Thomas 10]

Sowas macht man wenn keiner dran arbeitet bzw. in der Nacht. Wenn das nicht geht macht das die Sicherungssoftware über den sog. Shadow Volumen dienst. Dabei wird ein snapshot der Datei gemacht und diese dann gesichert.

[Dukel 454]

Welcher dann nicht Konsistent sein muss. Alleine für ein sauberes Backup würde ich einen SQL Server einsetzen.

[zahni 554]

Access kann man auch als Frontend für einen SQL-Server verwenden.

Und es ist einfach sinnvoller, sicherer und performanter, wenn sich "Einer" um das Thema kümmert. Zumal dann auch keine überflüssigen Daten über das Kabel geschickt werden.

[Braun_Thomas 10]

Ein Admin und ein Datenbankprofi unterhalten sich ;)

 

Ich tanze nicht auf mehreren Hochzeiten ;) das Datenbankthema soll der machen der sich damit auskennt und "Spezialisiert" ist.

 

Aber ich sehe nicht ein, dass man auf dem Server Terminal verwenden soll, nur weil die Datenbank so unperformant und ohne SQL arbeitet.

 

Daher hohle ich mir eine zweite Meinung ein.

 

Klar läuft das Ding schneller, wenn Access usw. auf dem Server installiert ist und direkt auf die MDB zugreift. Aber so macht man das doch heute nicht mehr oder bin ich da falsch.

 

Herzlichen Dank!

[marka 584]

Access Datenbankdateien zicken gerade im Hinblick auf mehrere gleichzeitige User gerne mal rum.

Wenn eine Datenbankdatei von einem user geöffnet ist, kann sie regulär nicht von einem zweiten User mit Schreibzugriff geöffnet sein.

 

Es ist auch logisch, dass beim Öffnen der Datei, zumal sie im Netz liegt, diese erst über das Netzwerk übertragen werden muss, um sie am Client in den RAM zu laden.

 

Ich würde bei Euch definitiv eine saubere SQL-Umgebung empfehlen.

Es muss ja dabei kein "ausgewachsener" MS-SQL-Server sein, ich denke bei der Größenordnung kommt Ihr auch erst Mal mit der kostenlosen Variante "SQL-Server Express" aus.

 

Dann werden von den Clients lediglich die SQL-Abfragen an den Server geschickt, der diese verarbeitet und die Antwort zurückschickt. Diese Datenpakete sind wesentlich kleiner, als jedes Mal die komplette DB zu ziehen und zurückzuschreiben.

Ihr bekommt dann auch keinen Ärger bzgl. des multiplen Zugriffs und Inkonsistenzen...

 

Eine weiter Möglichkeit wäre, das über eine MySQL-Datenbank zu realisieren.

Eine vernünftige Zugriffsmaske könnte dann, auf Eure Anforderungen und die CI zugeschnitten, über ein individuell programmiertes Webfrontend (PHP) umgesetzt werden.

Hier bestünde dann der Vorteil, dass die Software zentral gewartet würde und die User ohne lokal installierte Software über den Browser auf die datenbank zugreifen können.

[Braun_Thomas 10]

Hallo Marka,

 

danke. So etwas wollte ich hören ;) War mir nur nicht sicher, ob ich das so verstanden hatte. Kann man den sagen, ab wievielen Usern bzw. GB an Daten, eine mdb bzw. Access Lösung nicht mehr tragbar ist?

 

Ich sehe auch das dafür ein SQL Express ausreichen würde.

 

Mein Kunde zahlt ca. 20.000 € / pro Jahr an Lizenzen, dafür glaube ich, kann man schon erwarten, dass es auf einer moderneren bzw. sinnvollere Basis aufbaut.

 

Danke & schönen Abend

Thomas

[Sunny61 806]

Access Datenbankdateien zicken gerade im Hinblick auf mehrere gleichzeitige User gerne mal rum.

Wenn eine Datenbankdatei von einem user geöffnet ist, kann sie regulär nicht von einem zweiten User mit Schreibzugriff geöffnet sein.

 

Beide Aussagen kann ich so nicht stehenlassen. Ich habe viele Jahre mit Access gearbeitet, Front- und Backend in Acces. Wenn es Geschwindigkeiteprobleme gibt/gab, dann lag es hauptsächlich an Abfragen, deren Design verbesserungswürdig war.

 

Es ist auch logisch, dass beim Öffnen der Datei, zumal sie im Netz liegt, diese erst über das Netzwerk übertragen werden muss, um sie am Client in den RAM zu laden.

 

Auch das kann ich nicht stehen lassen. Dann wäre ja sofort ein Access Task mit ca. 2 GB im RAM zu sehen, ist aber nicht. Falls Du das sog. Frontend meinst, das gehört auf den Client. Da muß jeder sein eigenes haben, egal ob Access oder SQL-Server als Backend.

 

Ich würde bei Euch definitiv eine saubere SQL-Umgebung empfehlen.

Es muss ja dabei kein "ausgewachsener" MS-SQL-Server sein, ich denke bei der Größenordnung kommt Ihr auch erst Mal mit der kostenlosen Variante "SQL-Server Express" aus.

 

Ja, 2008R2 Express kann Datenbanken verwalten, die 10 GB Größe haben. Allerdings kann die Express Version nur 1 GB RAM nutzen.

 

Dann werden von den Clients lediglich die SQL-Abfragen an den Server geschickt, der diese verarbeitet und die Antwort zurückschickt. Diese Datenpakete sind wesentlich kleiner, als jedes Mal die komplette DB zu ziehen und zurückzuschreiben.

 

Das hat mit dem SQL-Server nichts zu tun. Wenn das Frontend müllig programmiert ist, kann der SQL-Server nichts verbessern.

 

Ihr bekommt dann auch keinen Ärger bzgl. des multiplen Zugriffs und Inkonsistenzen...

 

Auch den Multiuser Zugriff beherrscht Access ziemlich gut. Außer der Client, das Frontend, ist entsprechend müllig programmiert.

 

Eine weiter Möglichkeit wäre, das über eine MySQL-Datenbank zu realisieren.

Eine vernünftige Zugriffsmaske könnte dann, auf Eure Anforderungen und die CI zugeschnitten, über ein individuell programmiertes Webfrontend (PHP) umgesetzt werden.

Hier bestünde dann der Vorteil, dass die Software zentral gewartet würde und die User ohne lokal installierte Software über den Browser auf die datenbank zugreifen können.

 

[Haarspaltmodus an]

Ein Browser ist auch eine lokal installierte Software. ;)

[Haarspaltmodus aus]

[Sunny61 806]

danke. So etwas wollte ich hören ;) War mir nur nicht sicher, ob ich das so verstanden hatte. Kann man den sagen, ab wievielen Usern bzw. GB an Daten, eine mdb bzw. Access Lösung nicht mehr tragbar ist?

 

Ich hatte ein Frontend mit dem ca. 30 User gleichzeitig auf mehrere Access Backends zugegriffen haben, es gab keine Probleme mit inkonsistenten Daten oder ähnlichem.

 

Mein Kunde zahlt ca. 20.000 € / pro Jahr an Lizenzen, dafür glaube ich, kann man schon erwarten, dass es auf einer moderneren bzw. sinnvollere Basis aufbaut.

 

Verrate doch die verwendete Software, dann kann man sich das evtl. ansehen.

[Sunny61 806]

ich habe ein Problem. Ich bin Netzwerkadminstrator und kein Datenbankspezialist. Ein Kunde von mir verwendet eine Datenbanksystem für die Kundenverwaltung. Insgesamt sind es 15 Benutzer die damit arbeiten.

 

Welches System ist da genau im Einsatz?

 

Soweit ich es sehe arbeitet die Datenbank auf mdb Daten bzw. Access. Auf den Clients ist auch die Access Runtime installiert und wenn ich mir den Server ansehe dann sind über 30 mdb und ldf Dateien im gleichzeitigen Zugriff. Die ganzen MDB Dateien die in der Verwendung sind haben größen bis zu 2 GB an Größe. Wenn ich alle MDB Dateien zusammenehme, komme ich auf eine Datenmenge von 50 GB.

 

Gibts dort evtl. schon einen SQL-Server? LDF Dateien haben mit Access nichts zu tun.

 

Jetzt gibt es Probleme mit der Geschwindigkeit beim arbeiten in der Datenbank. Angeblich liegt es am Server.

 

Kann der Entwickler das beweisen? Wenn nein, dann ist es seine Schuld.

 

Nach meinem bisherigen Verständniss ist es doch so, dass Clients auf den SQL Zugreifen und ihn "fragen" was sie wollen. Die Daten und die Berechnungen finden auf dem Server statt. Er gibt also nur die Infos an den Clients zurück, die der Client braucht.

 

Was meinst Du jetzt mit "auf den SQL zugreifen"? Ist ein SQL-Server installiert?

 

Die Lösung des Problems soll jetzt sein, dass direkt auf dem Server gearbeitet werden soll (Remotesoftware, Terminal whatever). Das halte ich aber für einen Wahnsinn da neben der DB noch andere Dinge darauf laufen.

 

Wenn dann Terminalserver. Das kostet zusätzliche Lizenzgebühren.

 

Was sind jetzt also die Signifikaten Unterschiede zwischen Access mdb und SQL in Bezug auf Verarbeitungsgeschwindigkeit??

 

Sorry, aber erst muß klargestellt sein, was genau jetzt verwendet wird. Access Backend (MDB) oder SQL-Server Backend.