Datenbank Design SAP
-
Hallo Forum,
bei einer Firma ist SAP Business One installiert. Ich schaue gerade in die Datenbank dahinter. Dort sind keine Fremdschlüsselbeziehngen definiert. Alles wird von neuem rudeimentär in riesige Tabellen gekippt. (Der Kundenname zB steht als NVCHAR Spalte in vielen Tabellen drin.) Hat das irgendwelche Vorteile wenn man einen Fat Client entwickelt? Soweit ich verstanden habe gibt es bei diesem Produkt nur den Datenbank Server und einen Fat Client wo die gesamte Logik inkuldiert ist und der direkt auf die DB zugreift. (Oder haben die SAP Heinis das DB Design irgendwie aus den 60er Jahren geerbt?)
Also die SAP Tabellen selbst zu ändern wär wohl ein Himmelfahrskommando. Ich denke da könnte man höchstens lesend mal irgendwas auslesen, die eigenen Daten dann prallel in neue Tabellen schreiben. Hat schonmal wer von euch an SAP B1 herumgeschraubt? Wenn ich mich in das SDK hereinarbeite, was für Minen warten dann noch auf mich? Kann man damit gut eigene Dialoge entwerfen die halbwegs akzeptabel mit dem Fat Client verknüpft sind?
Vielen Dank
Peter
-
Also ich kenn mich mit SAP nicht so aus. Wir haben eNVenta und da ist das ähnlich. Das basiert auf einer SQL-Datenbank, die rein nur aus Tabellen besteht. Relationen und Schlüsselbeziehungen sind Fehlanzeige. Die ganze Logik steckt in der Anwendung und die Datenbank wird sozusagen nur als Speicher verwendet. Blöd ist, wenn da Bugs enthalten sind. Das Programm bekommt man ähnlich wie bei SAP in einer Grundversion, die dann auf die speziellen Bedürfnisse des Kunden angepasst werden. Dort ist das über Framework Studio realisiert. Allerdings komnmt es in den "Anpassungen" hin und wieder zu Problemen, wenn da nicht sauber programmiert wird. Wir haben in einer Abfrage da Problem, dass ein Feld (in dem Fall eine Bestellnummer) durch den Benutzer geleert werden kann, was aber beim Schreiben in die Tabelle nicht leer sein darf. Die Spalte in der DB hat aber nicht die Eigenschaft notNULL, sodass der Fehler erst später auftritt wenn kombinierte Abfragen durchgeführt werden.
Was deine Anmerkung zum Kundennamen angeht, so ist das in unserem Fall auch so. Es gibt zig Tabellen (die DB ist ca. 130 GB groß), die Artikelnummern und Chargen verwalten. Nach der allgemeinen Datenbanktheorie würde man die Tabellen zusammenfassen und mit Relationen arbeiten. Dann könnte man mit wenigen GB auskommen, da die Daten nicht redundant vorhanden wären. Die werden das sicher aus Performance-Gründen wieder denormalisiert haben und die Tabellen den Masken der Oberflächen angepasst haben. Damit kann man meist nicht mit dem was man mal gelernt hat konform werden.
Aber um die Frage zu beantworten: damit ist es einfacher eigenes Zeugs zu implementieren, ohne den Rest damit zu belasten.
-
abcd schrieb:
Dort sind keine Fremdschlüsselbeziehngen definiert. Alles wird von neuem rudeimentär in riesige Tabellen gekippt. (Der Kundenname zB steht als NVCHAR Spalte in vielen Tabellen drin.) Hat das irgendwelche Vorteile wenn man einen Fat Client entwickelt?...
Constraints können Performance kosten (wobei ich dies nicht als Argument ansehe, mir ist Konsistenz wichtiger), ebenso wie Redundanz unter Umständen Performance steigern kann. Ich kenne das DB-Design von SAP nicht, gehe aber mal davon aus das dies tatsächlich der Historie geschuldet ist.
Ansonsten kann ich zu den SAP-Tabellen nichts sagen (Bin zwar zertifizierter Berater, aber a) ist das lange her und b) hatte die Schulung nur sehr am Rande mit Datenbanken zu tun).
-
asc schrieb:
Constraints können Performance kosten (wobei ich dies nicht als Argument ansehe, mir ist Konsistenz wichtiger), ebenso wie Redundanz unter Umständen Performance steigern kann. Ich kenne das DB-Design von SAP nicht, gehe aber mal davon aus das dies tatsächlich der Historie geschuldet ist.
Ansonsten kann ich zu den SAP-Tabellen nichts sagen (Bin zwar zertifizierter Berater, aber a) ist das lange her und b) hatte die Schulung nur sehr am Rande mit Datenbanken zu tun).
Sehe ich auch so. Die Abfragen laufen schneller wenn man nur auf eine Tabelle zugreifen muss in der dann alles steht. Sowas steht immer im Gegensatz zur Konsistenz.
Natürlich ist die historische Entwicklung einer solchen DB auch nicht außer Acht zu lassen. Dann muss man halt noch was dranmurksen und schon hat man wieder 2-3 Tabellen mehr, die auch Inhalte anderer Tabellen enthalten.
-
Constraints können aber auch die Performance steigern. Wenn man anhand der Constraints schon erkennen kann, dass die Query keine Ergebnisse liefern kann, braucht man die Query erst gar nicht ausführen. Bzw. könnte man dann evtl. auch andere Optimierungen machen und bei Joins einen Teil der Daten ignorieren anstatt danach zu suchen.