Hallo Forumsteilnehmer,
ich habe ja bereits einige Beiträge ins Forum gestellt, aus denen vielleicht ersichtlich wurde,
dass ich mich mit dem JTL-Wawi recht intensiv beschäftigt habe. Jetzt hat mein Chef einen
IT-Consultanten angesetzt, um das von mir geleitete Projekt zu beurteilen. Ich möchte euch mal
seine Einschätzung (in Auszügen) mitteilen. Vielleicht könnt ihr mir einige Gegenargumente liefern.
Viele Grüße
Wolfgang
Fremdmeinung:
Analyse_der_Datenbankstruktur_von_JTL_WAWI_mit_"katastrophalen"__Ergebnissen
JTL Software hat einen Excel-artigen sogenannten flachen Datenbank-Strukturansatz gewählt,
der zwar eine hohe Universalität bei der Verwendung der Daten durch den Programmierer gestattet
(es diesem in gewisser Weise "leicht" macht, Daten zu manipulieren), aber wofür man im Weiteren
einen hohen Preis bezahlt, was wie folgt beschrieben werden kann:
Die Datenbank selbst ist immer die Grundlage eines datanbankbasierten Systems und es gibt
bestimmte anerkannte Regeln ("ER-Regeln" oder "Einheiten-Relationen-Regeln") für den Entwurf
solcher Datenstrukturen. JTL-WAWI verletzt alle diese Regeln aufs Gröbste.
1. ausufernde Komplexität schon in der Datenhaltung, was das Programmieren durch einen einzelnen
Programmierer, der nicht mit der ganzen Struktur perfekt vertraut ist, außerordentlich erschwert.
2. Die natürlichen Schutzmechanismen für Daten, die Datenbanksysteme wie SQL-Server
(verwendet als SQL Express 2005-Version bei JTL WAWI) eigentlichen mitbringen, werden hier einfach nicht
benutzt (sog. "Referentielle Integrität"). Dieser Schutz muss dann darüberprogrammmiert werden,
was unnötig ist, wenn man die Möglichkeiten des Datenbanksystems richtig nutzt. Außerdem ist diese
Art der Datenhaltung grundsätzlich extrem anfällig gegen Programmierfehler bei Ergänzungen.
3. Da richtig strukturierte Datenbanken doppelte Dateneinträge vermeiden, wachsen diese Datenmengen
in diesen sehr viel geringer als in schwach strukturierten Datenbanken wie der von WAWI / JTL.
Zugleich halten relationale (richtig strukturierte Datenbanken) die Anzahl der Tabellen in Grenzen,
was die Programmierung erleichtert und auch das logische Verständnis der Datenbank durch andere Entwickler
ermöglicht. --> JTL / WAWI kommt auf sage und schreibe ca. 230 Tabellen, die das Programmieren auch
für den begabtesten Entwickler zum Horror selbst jenseits überdurchschnittlicher intellektueller und
fachlicher Fähigkeiten macht. Dass das dann ewig dauern muss, ineffizient ist und fehleranfällig in
hohem Grade dazu, ist jedem Datenbankentwickler schnell klar, wenn er sich das WAWI Backend
(Fachbegriff für die Datenbank "unter" einer Software) auch nur oberflächlich ansieht.
4. Weiterhin gibt es in der Datenbank "Preziosen" wie offen lesbare Login-Passwörter
(kombiniert mit einem gravierenden Mangel an an sich vorhandenen, aber JTL-seitig nicht aktivierten
Sicherheitseinstellungen), was wirklich weit jenseits des Standes der Technik ist.
5. Das Programm JTL-WAWI selbst leidet an den Schwächen aller nicht integriert entwickelter Software,
die die inhaltlichen Zusammenhänge dem Benutzer nicht sonderlich deutlich macht, so dass das Programm
im Grunde ein "Expertensystem" ist. Das bedeutet, dass ein guter Bediener des Programms 50% bis 100% seiner
Zeit auch damit arbeiten muss, um die Bedienung zu verinnerlichen und damit effizient zu arbeiten zu können.
Aus den Schlussfolgerungen:
b.) Allein daher kann JTL / WAWI definitiv nicht verantwortlich für den Einsatz in kommerziell kritischen
Applikationen empfohlen werden. Erweiterungen solcher schon in der Datenstruktur mangelhaft begründeten Software
sind extrem ineffektiv, fehleranfällig und mit hohem Datenverlust-Risiko verbunden, da die datenbankseitigen
Schutzmechanismen für Daten nicht benutzt werden. Sie verbieten sich damit eigentlich von selbst.
d.) Der entscheidende Fehler ist mit der Auswahl der Software durch den Programmierer schon erfolgt.
Allein schon damit und mit der Entscheidung, hier auch noch mit Eigenentwicklung aufsatteln zu wollen,
hat sich der Programmierer unabhängig vom fehlenden Projektfortschritt disqualifiziert.
e.) Viele nicht in (modernen oder großen) Datenbanksystemen erfahrene Programmierer lehnen die Regeln
zur Entwicklung von Datenbanken ab, weil sie das nicht oder nur unzureichend an der Uni lernen und nur
wenige Entwickler in Datenbankdesign eigene Erfahrungen haben. Außerdem erfordert strukturierte Datenhaltung
meist besondere Datenzugriffstechnologien, die mit den eingebauten Datenschutzsystemen der Datenbank konform sind.
Diese modernen Technologien beherrschen eigentlich nur ausgewiesene "Datenbankentwickler".
ich habe ja bereits einige Beiträge ins Forum gestellt, aus denen vielleicht ersichtlich wurde,
dass ich mich mit dem JTL-Wawi recht intensiv beschäftigt habe. Jetzt hat mein Chef einen
IT-Consultanten angesetzt, um das von mir geleitete Projekt zu beurteilen. Ich möchte euch mal
seine Einschätzung (in Auszügen) mitteilen. Vielleicht könnt ihr mir einige Gegenargumente liefern.
Viele Grüße
Wolfgang
Fremdmeinung:
Analyse_der_Datenbankstruktur_von_JTL_WAWI_mit_"katastrophalen"__Ergebnissen
JTL Software hat einen Excel-artigen sogenannten flachen Datenbank-Strukturansatz gewählt,
der zwar eine hohe Universalität bei der Verwendung der Daten durch den Programmierer gestattet
(es diesem in gewisser Weise "leicht" macht, Daten zu manipulieren), aber wofür man im Weiteren
einen hohen Preis bezahlt, was wie folgt beschrieben werden kann:
Die Datenbank selbst ist immer die Grundlage eines datanbankbasierten Systems und es gibt
bestimmte anerkannte Regeln ("ER-Regeln" oder "Einheiten-Relationen-Regeln") für den Entwurf
solcher Datenstrukturen. JTL-WAWI verletzt alle diese Regeln aufs Gröbste.
1. ausufernde Komplexität schon in der Datenhaltung, was das Programmieren durch einen einzelnen
Programmierer, der nicht mit der ganzen Struktur perfekt vertraut ist, außerordentlich erschwert.
2. Die natürlichen Schutzmechanismen für Daten, die Datenbanksysteme wie SQL-Server
(verwendet als SQL Express 2005-Version bei JTL WAWI) eigentlichen mitbringen, werden hier einfach nicht
benutzt (sog. "Referentielle Integrität"). Dieser Schutz muss dann darüberprogrammmiert werden,
was unnötig ist, wenn man die Möglichkeiten des Datenbanksystems richtig nutzt. Außerdem ist diese
Art der Datenhaltung grundsätzlich extrem anfällig gegen Programmierfehler bei Ergänzungen.
3. Da richtig strukturierte Datenbanken doppelte Dateneinträge vermeiden, wachsen diese Datenmengen
in diesen sehr viel geringer als in schwach strukturierten Datenbanken wie der von WAWI / JTL.
Zugleich halten relationale (richtig strukturierte Datenbanken) die Anzahl der Tabellen in Grenzen,
was die Programmierung erleichtert und auch das logische Verständnis der Datenbank durch andere Entwickler
ermöglicht. --> JTL / WAWI kommt auf sage und schreibe ca. 230 Tabellen, die das Programmieren auch
für den begabtesten Entwickler zum Horror selbst jenseits überdurchschnittlicher intellektueller und
fachlicher Fähigkeiten macht. Dass das dann ewig dauern muss, ineffizient ist und fehleranfällig in
hohem Grade dazu, ist jedem Datenbankentwickler schnell klar, wenn er sich das WAWI Backend
(Fachbegriff für die Datenbank "unter" einer Software) auch nur oberflächlich ansieht.
4. Weiterhin gibt es in der Datenbank "Preziosen" wie offen lesbare Login-Passwörter
(kombiniert mit einem gravierenden Mangel an an sich vorhandenen, aber JTL-seitig nicht aktivierten
Sicherheitseinstellungen), was wirklich weit jenseits des Standes der Technik ist.
5. Das Programm JTL-WAWI selbst leidet an den Schwächen aller nicht integriert entwickelter Software,
die die inhaltlichen Zusammenhänge dem Benutzer nicht sonderlich deutlich macht, so dass das Programm
im Grunde ein "Expertensystem" ist. Das bedeutet, dass ein guter Bediener des Programms 50% bis 100% seiner
Zeit auch damit arbeiten muss, um die Bedienung zu verinnerlichen und damit effizient zu arbeiten zu können.
Aus den Schlussfolgerungen:
b.) Allein daher kann JTL / WAWI definitiv nicht verantwortlich für den Einsatz in kommerziell kritischen
Applikationen empfohlen werden. Erweiterungen solcher schon in der Datenstruktur mangelhaft begründeten Software
sind extrem ineffektiv, fehleranfällig und mit hohem Datenverlust-Risiko verbunden, da die datenbankseitigen
Schutzmechanismen für Daten nicht benutzt werden. Sie verbieten sich damit eigentlich von selbst.
d.) Der entscheidende Fehler ist mit der Auswahl der Software durch den Programmierer schon erfolgt.
Allein schon damit und mit der Entscheidung, hier auch noch mit Eigenentwicklung aufsatteln zu wollen,
hat sich der Programmierer unabhängig vom fehlenden Projektfortschritt disqualifiziert.
e.) Viele nicht in (modernen oder großen) Datenbanksystemen erfahrene Programmierer lehnen die Regeln
zur Entwicklung von Datenbanken ab, weil sie das nicht oder nur unzureichend an der Uni lernen und nur
wenige Entwickler in Datenbankdesign eigene Erfahrungen haben. Außerdem erfordert strukturierte Datenhaltung
meist besondere Datenzugriffstechnologien, die mit den eingebauten Datenschutzsystemen der Datenbank konform sind.
Diese modernen Technologien beherrschen eigentlich nur ausgewiesene "Datenbankentwickler".