Zitat:

Aber eine Datenbank ist nun einmal kein Word und kein Excel und kein Powerpoint und hier heißt die klare Unterscheidung: Was will ich mit dem Produkt erreichen? Wenn jemand seine Briefmarkensammlung oder eine komfortablere Tabellenverwaltung von ein oder zwei Tabellen oder einen einfachen Datenabgleich zwischen zwei Tabellen, der einfacher ist als ein kompliziertes VLOOKUP in Excel, mit Access durchführen will oder einfach ein wenig damit herumspielen möchte - warum nicht? Es ist doch jedem freigestellt, mit seiner Software anzufangen, was er möchte. Doch spätestens, wenn es um Datenbanken geht, die in irgendeiner Form für berufliche Zwecke und Unternehmensdaten verwendet werden sollen, hat für meine Begriffe "der Spaß ein Ende", oder anders ausgedrückt: Unsinnige Herangehensweisen wie Makros, undurchdachte Datenmodelle usw. haben in so einem Umfeld einfach nichts zu suchen. Denn die Erstellung solcher Datenbanken kostet den Unternehmer Geld, da spielt es keine Rolle, wieviel Erfahrung zugrundeliegt. Und die falsche Herangehensweise scheint anfangs "gut zu funktionieren", aber wenn skaliert werden muß, beginnen plötzlich die Kopfschmerzen und damit enorm höhere Kosten, den begonnenen Unsinn wieder geradezubiegen. Dann muß u.U. ganz von vorn angefangen werden und das nur, weil man nicht von Beginn an ein ordentliches Fundament gebaut hat.
Für mich als Programmierer ist das sicherlich gut, ich habe deswegen einen krisenfesten Job... ich bin die letzten vier Jahre (!) damit beschäftigt, so eine Datenbank umzubauen und ein Ende ist noch nicht in Sicht. Das Fazit ist nach wie vor, das Produkt nochmal ganz von vorn zu beginnen.
Was ein Geld damit verbrannt wird, ist gar nicht zu zählen. Nicht nur die Programmierkosten für den Umbau, sondern auch die enormen Kosten für (hier) ca. 300 Mitarbeiter, die mit Krampflösungen wie Datenaustausch über Excel-Dateien uvm. unglaublich viel Zeit verbrennen, nur um Systempflege zu betreiben, und trotzdem ist die Datenbank voll von Datenmüll, der kaum zu beheben ist. Und jetzt rate mal, wie das "Produkt" angefangen hat: Als kleine Excel-Tabelle, die in einer Abteilung das Leben etwas erleichtern sollte. Und dann wurde "mal schnell" eine Access-Datenbank auf einem Netzwerklaufwerk daraus gemacht. Und dann wurden noch ein paar Tabellen hinzugepfropft. Und ein paar Funktionen. Lief ja "irgendwie". Und dann kamen ein paar User mehr hinzu, die auch damit arbeiten wollten. Und ein paar neue Ideen. Und ein paar neue Tabellen. Und plötzlich lief die kleine Access-Datenbank nicht mehr rund. Zu langsam, Abstürze ohne Ende (wer macht schon Fehlerabfangen in einer Runtime...). Schnell mal einen Umzug auf ein SQL Server 2000-Backend, so ein Server ist ja schließlich schneller. Mit der gleichen Tabellenstruktur und der Access-/Excel-Denke, versteht sich. Komisch, irgendwie hat sich nicht viel geändert. Immer noch ziemlich langsam, immer noch Abstürze, fluchende Mitarbeiter, Wut auf das Produkt.
Und ein Hobby-Programmierer ist damit mit einem Mal überfordert und es wird ein externer Programmierer hinzugeholt, der mal "ein bißchen was verbessern" soll. Und der steht nun vor der Mammutaufgabe, in etlichen Tabellen voller Datenmüll, ohne Normalisierung, ohne vernünftige Verknüpfungen, mit sinnfreien Vermischungen von Makros und VBA im Frontend, mit schlecht designten Formularen und Reporten und Abfragen, "irgendwie" etwas zu verbessern - in vier Wochen.
Das hat das Unternehmen RICHTIG Geld gekostet, denn diese externe Firma war richtig teuer. Und im Ergebnis konnten nach vier Wochen nur die heißesten Brandherde bekämpft werden.
Ich bin mittlerweile als externer Mitarbeiter bei der Firma beschäftigt, wie gesagt, seit vier Jahren und das Ergebnis ist immer noch, das man eigentlich von vorn anfangen müßte, wenngleich die Hoffnung immer mehr schwindet. Die Datenbank läuft mittlerweile stabil und performant, die Probleme in Front- und Backend sind größtenteils geradegezogen, aber die schrottige Datenstruktur ist weitgehend geblieben, da man nur schwer im Einsatz befindliche Produkte umstellen kann.

Und warum das alles? Hätte man gleich zu Beginn zwei bis drei Monate in eine gründliche Planung investiert, erfahrene Programmierer darangesetzt oder mindestens eine ordentliche Kurzausbildung in einen internen Mitarbeiter investiert, dann hätte man mit relativ wenig Geld ein stabiles Produkt erhalten, das in diesen Jahren kontinuierlich hätte wachsen können, das dem Unternehmen eine Menge Kosten und Ärger erspart hätte, und die Motivation der Mitarbeiter unterschiedlichster Abteilungen deutlich verbessert hätte sowie die Identifikation mit dem hauseigenen Produkt (was für ein Unternehmen sehr wichtig ist!).

Zitat:

schlechter Ruf von Excel in der "Managementebene".

Zitat: von Josef P.

Hallo!

Diese Kombination von Excel-Denke und Access-Nutzung nennt man Excess-Anwendung, oder?

mfg
Josef

Zitat: von Atrus2711

Darf ich das als abschreckendes Beispiel in meinen Kursen anbringen?

@CptChaos:

Excel hat einen viel zu guten Ruf bei den Spitzhaarigen. Wie oft werden Dinge via Excel ausgetauscht, anstatt einen zentralen DB-Server hinzustellen. Excel "kostet halt auch nix (an Geld, an Einarbeitung, ...)", im Gegensatz zu Access oder aktiven DBMS.

Zitat: von Benny

Ich nenne das in meinen Dokus intern immer AccEl... den Missbrauch von Access für Excel