{"id":1263,"date":"2010-04-19T20:38:46","date_gmt":"2010-04-19T18:38:46","guid":{"rendered":"http:\/\/www.bernhardschloss.de\/blog\/?p=1263"},"modified":"2010-04-19T20:41:08","modified_gmt":"2010-04-19T18:41:08","slug":"347-access-vs-andere-datenbanken","status":"publish","type":"post","link":"https:\/\/www.bernhardschloss.de\/blog\/347-access-vs-andere-datenbanken\/","title":{"rendered":"#347 Office: Access vs. andere Datenbanken"},"content":{"rendered":"

Wenn wir uns im konkreten Fall f\u00fcr eine Datenbankl\u00f6sung entschieden haben, sollten wir nicht den gleichen Fehler wie bei Excel („Der Hammer als einziges Werkzeug“)<\/a> begehen und alle Datenbankl\u00f6sungen in Access realisieren.<\/p>\n

Access ist ein feines Werkzeug mit hoher Office-Integration, Drag-and-Drop-Funktionalit\u00e4ten und zahlreichen Assisstenten. Ansehnliche Formulare sind im Handumdrehen erstellt,…<\/p>\n

Im Vergleich zu anderen Datenbanken haben wir Quick&Dirty-L\u00f6sungen schnell umgesetzt, aber an die Grenzen sto\u00dfen wir meist schneller als man denkt, z.B. bei einem Mehrnutzerbetrieb, den Access zwar grunds\u00e4tzlich unterst\u00fctzt, aber vielleicht doch nicht ganz optimal. Haben Sie sich schon einmal wegen Netzwerkproblemen eine Access-Datenbank zerschossen? Auch das kann passieren. In Sachen Performance k\u00f6nnen die Grenzen schnell erreicht werden und eine Tabelle darf nciht gr\u00f6\u00dfer als 2 GB werden.<\/p>\n

Ist dann der Einsatz von Access trotzdem sinnvoll?<\/p>\n

Na, klar, wenn man wei\u00df wof\u00fcr und wo die Grenzen liegen. F\u00fcr die schnelle Bearbeitung gr\u00f6\u00dferer Datenmengen, wo wir in Excel schon an unsere Grenzen gestossen sind, gerne, aber als dauerhafte Anwendung im Betrieb bei vielen Nutzern, weniger. \u00dcbergangsweise l\u00e4sst sich dann Access weiter als Frontend nutzen und eine Performance-st\u00e4rkere Architektur kann im Backend schuften. Auch zur Modellierung oder f\u00fcr Prototypen spricht nichts gegen Access.<\/p>\n

<\/div>