Raven84 Geschrieben 6. Juni 2008 Teilen Geschrieben 6. Juni 2008 Hallo zusammen, folgendes Szenario: Wir entwickeln Software zur Zeit auf einer AS/400 I5 von IBM, Programmiersprache RPG3, DB400 Datenbank, basiert auf DB2. Wollen nun aber auf C# wechseln mit einer entsprechenden SQL Datenbank. Aus historisch gewachsenen Gründen (ich liebe diese Umschreibung^^) haben wir extrem viele Datenbankteildateien. Da man dort kaum noch durchblickt, stellte sich ein Kollege es so vor: Eine Datei, mit entsprechenen Schlüsseln für den Zugriff. z.B.: Firma Schlüsselwort (wir entwickeln Lagerverwaltungssoftware, daher dachtenwir an LO für Lagerorttabelle, ART für Artikeltabelle etc) Und nachfolgend in einem Feld z.B. 2048 Zeichen mit allen Informationen, aller Teildateien. So das man nur mit dem Schlüssel zu greift und sich mit entsprechenden Zugriffen die Informationen ranholt. Ist das sinnvoll? Oder kann man davon eher abraten. Da ich nicht spezialisiert auf Datenbanken bin, kann ich dazu nicht richtig etwas sagen, und hoffe ich habe das Problem hinreichend erklärt. Hoffe das mir jemand hier weiterhelfen kann. mfg Raven Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 6. Juni 2008 Teilen Geschrieben 6. Juni 2008 Hallo zusammen, folgendes Szenario: Wir entwickeln Software zur Zeit auf einer AS/400 I5 von IBM, Programmiersprache RPG3, DB400 Datenbank, basiert auf DB2. Wollen nun aber auf C# wechseln mit einer entsprechenden SQL Datenbank. Aus historisch gewachsenen Gründen (ich liebe diese Umschreibung^^) haben wir extrem viele Datenbankteildateien. Da man dort kaum noch durchblickt, stellte sich ein Kollege es so vor: Eine Datei, mit entsprechenen Schlüsseln für den Zugriff. z.B.: Firma Schlüsselwort (wir entwickeln Lagerverwaltungssoftware, daher dachtenwir an LO für Lagerorttabelle, ART für Artikeltabelle etc) Und nachfolgend in einem Feld z.B. 2048 Zeichen mit allen Informationen, aller Teildateien. So das man nur mit dem Schlüssel zu greift und sich mit entsprechenden Zugriffen die Informationen ranholt. Ist das sinnvoll? Oder kann man davon eher abraten. Da ich nicht spezialisiert auf Datenbanken bin, kann ich dazu nicht richtig etwas sagen, und hoffe ich habe das Problem hinreichend erklärt. Hoffe das mir jemand hier weiterhelfen kann. mfg Raven HI, (Wusste gar nicht, dass es die AS/400 noch gibt :-)) - Dieses Design ist nicht nur nicht sinnvoll, sondern (Verzeihung) völliger Murks. Du arbeitest mit einer Relationalen DB...also modeliere die Entitäten und Releationen. Also, keine Felder, welche irgendwelche gesammelten Informationen als String beinhalten, da du so das Konzept einer SQL DB ad absurdum führtst. ich möchte nicht derjenige sein, der die entsprechenden Abfragen auf solche einem System macht. Gruss Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 6. Juni 2008 Teilen Geschrieben 6. Juni 2008 Hallo, ich schließe mich da wirklich nur an! Macht ein anständiges Datenbankmodell. Ich kam selbst in Genuss so etwas Gemurkstes zu überarbeiten und mehr als wegwerfen und neu machen kann man da nicht. Es kostet aber sehr viel Zeit ein falsches Design neu zu entwickeln. Sorry, dass ich hier das so schreibe, aber habt ihr in der Berufsschule geschlafen? Phil Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MasterZelgadis Geschrieben 6. Juni 2008 Teilen Geschrieben 6. Juni 2008 Tach zusammen. Ich bin der Kollege vom raven. Also, erstmal, die AS400 gibts tatsächlich noch. und zu flash: geschlafen nicht, aber private Notebooks lenken halt ab, außerdem war der Unterricht total für die Fott So, zum Thema... Natürlich wissen wir, dass man eine ganze Datenbank nicht so aufbauen kann, weils völliger Bull**** wäre. Hintergrund ist eigentlich der, dass die Firma das komplette Lagerverwaltungssystem, das wir auf der AS400 entwickeln, auf C# umzustellen. Ob komplett oder teilweise migriert oder komplett neu geschrieben, da ist man sich noch nciht so einig. Mit dem Modell geht es jetzt lediglich um Stammdaten. Sprich, so sachen wie Firmenstamm (Mandantenfähigkeit), Lagerorte, Versandarten...vielleicht schon gar nicht mal mehr der Artikelstamm. Also wirklich nur Daten, von denen in jeder Tabelle so ca. 10 - 100 Datensätze existieren, und die auch selten verändert werden. Hintergrund der ganzen Geschichte ist, dass wir statt der vielen vielen Stammdatenprogramme, die wir auf der AS400 haben, nur noch ein einziges Wartungsprogramm zu haben. Nun, bedingt durch die AS400 Programmierung stehen wir in C# noch ganz am Anfang. Es wäre doch sicher auch möglich mit einem einzigen Programm auf unterschiedliche Tabellen zuzugreifen, oder? Also, dass ich mir per ComboBox meine Stammdatendatei wählen kann, und bekomme dann je nach auswahl die Tabelle "Lagerorte", oder "Firmen", oder "Artikel" angezeigt... Wenn das einfach zu machen wäre, wäre das glaub ich das Argument gegen das Modell, das unser Chef vorgeschlagen hat. Wie die Performance sich verhält kann ich nichts zu sagen, da wir dort keine Erfahrungswerte haben. rein vom Gefühl her würde ich sagen, dass einzelne Stammdatentabellen performanter sind, als dieser zusammengewürfelte Haufen aus Daten, wo man sich per Stazart die richtigen Daten herausfiltert. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 6. Juni 2008 Teilen Geschrieben 6. Juni 2008 Also, erstmal, die AS400 gibts tatsächlich noch. [/CODE] - Ja, das waren noch Zeiten .... [CODE]Mit dem Modell geht es jetzt lediglich um Stammdaten. Sprich, so sachen wie Firmenstamm (Mandantenfähigkeit), Lagerorte, Versandarten...vielleicht schon gar nicht mal mehr der Artikelstamm. Also wirklich nur Daten, von denen in jeder Tabelle so ca. 10 - 100 Datensätze existieren, und die auch selten verändert werden. - Trotzdem, ich würde jede Entität in eine Tabelle packen : 1. Ist für das Wartungsprogram genauso gut zu handhaben (Programmieren musst du so oder so 2. Was machst du, wenn einzelne Stammdaten untereinander oder mit den Appliaktionsdaten Beziehungen besitzten (Foreing Keys, andere Constriants). Nur mit einem sauberen Datenmodel lässt sich dies in der DB implementieren, ansonsten fängst du an, dies im Code zu implementieren --> Bad/Ugly/Bull* 3. Es skaliert besser 4. Es ist wartbar Hintergrund der ganzen Geschichte ist, dass wir statt der vielen vielen Stammdatenprogramme, die wir auf der AS400 haben, nur noch ein einziges Wartungsprogramm zu haben. - Hat mit dem gewählten Datenmodel nichts zu tun Nun, bedingt durch die AS400 Programmierung stehen wir in C# noch ganz am Anfang. Es wäre doch sicher auch möglich mit einem einzigen Programm auf unterschiedliche Tabellen zuzugreifen, oder? Also, dass ich mir per ComboBox meine Stammdatendatei wählen kann, und bekomme dann je nach auswahl die Tabelle "Lagerorte", oder "Firmen", oder "Artikel" angezeigt... Wenn das einfach zu machen wäre, wäre das glaub ich das Argument gegen das Modell, das unser Chef vorgeschlagen hat. - Das ist kein Problem mit Stammdaten in einzelnen Tabellen, im Gegenteil (Wir haben diverse solche Administrationstools so gebaut...) Gruss Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MartinSt Geschrieben 6. Juni 2008 Teilen Geschrieben 6. Juni 2008 volle Zustimmung, dbwizard Das ganze DB-Modell ist doch völlig unabhängig davon, ob ihr in C# oder in sonstwas entwicklelt. Prinzipiell kann und sollte man das DB-Modell erstmal mit Papier und Bleistift entwerfen. so dass man wie von den Kollegen gesagt vernünftige Entitäten modelliert. Erst wenn es zwingende Performance-Gründe gibt kann man zur Not das Modell zugunsten der Performance aufweichen, aber das dürfe bei euren Mengen und Zugriffshäufigkeiten kein Thema sein. Gruß Martin Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.