Hallo :)
Habe das gleiche Problem, wie hier beschrieben:
eine Datenbank mit ca 200 Tabellen, die auf mindestens eine zentrale Tabelle verlinken: eine tbl_Personendaten und viele mit dokumentatorisch wichtigen Daten einer Klinik. Da ich auch noch recht frisch bin im Thema .Net, habe ich einfach mal gehofft, es g?be etwas in der Art wie das DataEnv in VB6, welches schon recht un?bersichtlich wird...
Auch bei mir m?sste jedes DataSets wenigstens die tbl_Personendaten enthalten -> schlecht.
Einzelne Prozesse sind schon in kleinere DataSets abgebildet, trotzdem bleibt aber ein pathologisch (sch?nes Wort in diesem Kontext) gro?es ?ber.
Wie ist das denn bei dir weitergelaufen?
Ich finde den Verlauf dieses Threads ziemlich am?sant und hilfreich zugleich (ihr habt manchmal Lehrbuch-m??ig aneinander vorbeigeredet :), nur fehlt mir noch das Ergebnis.
Vielen Dank schonmal.
Hoffe, das wird noch gelesen, da ja jetzt schon ein Jahr vergangen ist. :)
Viele Gr??e!
Markus
MichaelGlande wrote:
Hallo G??nther,verzeih meine sp??te Meldung.
19-Feb-09
Hallo G??nther
verzeih meine sp??te Meldung. Danke f??r die L??sungsvorschl??ge, ich glaube Du
bist der einzige der mein Kauderwelsch verstanden hat. Ich werde es mal mir
einem Dataset versuchen, sonst so wenig wie m??glich.
Danke auch an die anderen replies. Eine kleine Kritik: wenn jemand sein
Umfeld beschreibt, sollte man ihm auch glauben. Ich entwickle und erweitere
die DB seit 11 Jahren und weiss wie oft ich ??nderungen an der DB-Struktur
vornehmen muss, da sind Hinweise darauf, dass eine Struktur??nderung wohl
ausf??llt nicht sonderlich hilfreich
Gr????
Michael
Previous Posts In This Thread:
On Thursday, February 05, 2009 1:24 PM
MichaelGlande wrote:
Wie viele Tabellen in einem Dataset - Design
Hallo community
meine Frage betrifft den Softwareentwurf
Ich habe eine SQL-Datenbank mit knapp 200 Tabellen, auf die diverse
Anwendungen zugreifen. Diese Anwendungen stelle ich seit geraumer Zeit auf
.Net um. Ich benutze eine Datenzugriffsschicht in der im wesentlichen ein
typed dataset den Zugriff auf die Datenbank regelt. Nun bin ich wieder mit
der Frage konfrontiert, die mich von Anfang an qu??lt: wie viele Tabellen darf
ich in mein DataSet stopfen? Viele Tabellen f??hren zu einer hohen
Speicherauslastung, abgesehen davon leidet die ??bersichtlichkeit. Bei wenigen
Tabellen muss ich mehrfach codieren und bekomme den Wartungsalbtraum.
Isolierte Inseln gibt es in meiner Datenbank nicht, alle Tabellen stehen
miteinander in Beziehung
Ich bin ??ber jeden Tip dankbar
Michael
On Friday, February 06, 2009 1:15 AM
Peter Fleischer wrote:
Re: Wie viele Tabellen in einem Dataset - Design
"Michael Glander" <***@discussions.microsoft.com> schrieb im
Newsbeitrag news:C8AE8876-8484-448D-AF0C-***@microsoft.com..
Hi Michael
eine SQL-Datenbank mit 200 Tabellen ist nichts besonderes. Ich kann mir aber
nicht vorstellen, dass ein Anwender alle diese 200 Tabellen in einem
technologischen Ablauf ben??tigt. Viele Anf??nger machen den Fehler, dass sie
im Client ein Abbild der externen Datenbank halten wollen. Das ist ??berhaupt
nicht n??tig. Zuerst sollte man seine Bedienabl??ufe in horizontale Prozesse
zergliedern. Am Beispiel einer Software zur Lagerverwaltung kann die
Anwendung vereinfacht in folgende Prozesse zergliedert werden
- Verwaltung des Lagerortverzeichnisse
- Verwaltung der Artikelstammdate
- Einbuchung von Lagerzug??nge
- Einbuchung von Materialentnahme
- Inventu
Jeder dieser horizontalen Prozess nutzt eine eigene Inline-Datenbank f??r die
von ihm ben??tigten Gesch??ftsobjeke. In erster N??herung k??nnen als
Gesch??ftsobjekte typisierte DataRows und als Container f??r die
Gesch??ftsobjekte typisierte DataSet-Objekte dienen, d.h. f??r die obige
Zergliederung gibt es 5 verschiedene typisierte DataSet-Klassen. In jedem
der DataSets gibt es Tabellen, die mit Join aus mehreren Tabellen der
Datenbank geladen werden und die durch den Prozess nur zum Lesen (z.B. als
Nachschlagetabellen) genutzt werden. Die eigentliche Tabelle im DataSet, in
der ge??ndert wird, entspricht teilweise der externen Datenbanktabelle;
teilweise in bezug auf die Spalten und teilweise in Bezug auf die ben??tigten
Datens??tze. Das bedeutet, dass die Struktur eines DataSets nur in seltenen
F??llen zuf??llig der Struktur der externen Datenbank entspricht.
Diese Herangehensweise sichert, dass auch funktionell auf der Ebene
horizontaler Prozesse gekapselt werden kann. Realisiert wird jeder
horizontale Prozesse in der entsprechenden Ebene durch eigene
Programmabl??ufe, z.B. eine UI, eine BL und eine DAL. Zwischen den Schichten
wird die Inline-Datenbank bzw. deren Objekte f??r die Daten??bergabe genutzt.
Im Rahmen der Optimierung kann man nat??rlich auch mehrere DataSets, die in
naheliegenden Prozesse genutzt werden, vereinen und gemeinsam nutzen. Wo da
der Kompromiss liegt, muss der Entwickler entscheiden.
Problematisch sind prinzipielle ??nderungen der Datenbankstruktur, die sich
auf mehrere DataSets auswirken. Bei einer ausreichenden konzeptionellen
Vorarbeit ist das aber praktisch selten der Fall. In einem laufenden
Anwendungssystem ist f??r solche F??lle der ??nderung der Datenbankstruktur
sowieso eine komplexe ??nderungstechnologie zu erarbeiten die sowohl die
Konvertierung der vorhandenen Daten als auch die ??nderung und Einf??hrung der
ge??nderten Programmkomponenten enth??lt.
Unter den obigen Gesichtspunkten verstehe ich diese Aussagen nicht.
Vielleicht kannst du dazu noch etwas schreiben.
--
Viele Gr??sse
Peter
On Friday, February 06, 2009 5:15 AM
MichaelGlande wrote:
Hallo Peter,vielen Dank f??r Deine Antwort.
Hallo Peter,
vielen Dank f??r Deine Antwort. Deine Empfehlung w??re also ein DAL pro
Anwendung. Ich denke das ist die Orientierung, die ich gebraucht habe.
Du hast nat??rlich Recht, kein User muss schreibend auf 200 Tabellen
zugreifen, es geht prim??r um die Lesetabellen. Mit mehrfach codieren meine
ich vor allem die TableAdapter, mit ihren von mir erstellten
FillBy()-Methoden, die in mehreren Anwendungen zu gebrauchen sind. Aber auch
andere Funktionen, die z.B. Tabelleninhalte zusammenfassen und formatieren.
Mal kurz zu meinem Kontext: Ich arbeite als Einzelentwickler bei einem
Filmverleih, den Leuten f??r die ich programmiere kann ich nicht mit
Spezifikationen kommen. Entsprechend intuitiv f??llt da die Planung aus. Da
sich obendrein die ??u??eren Bedingungen recht h??ufig ??ndern, muss ich
regelm??ssig zumindest kleinere Erweiterungen an der Datenbank vornehmen. Was
den Datenzugriff angeht, versuche ich was geht vom DataSet-Assistent
erledigen zu lassen. Auf ein so erstelltes DataSet greife ich dann in einer
Anwendungen zu. Bisher habe ich pro Anwendung ein DAL benutzt (nicht als
Ergebnis ausgekl??gelter Planung, sondern um ??berhaupt mal eine Anwendung
produktiv zu bekommen). Wenn sich was an einer der Tabellen ??ndert, die fast
jeder benutzt, habe ich so nat??rlich richtig zu tun. Also w??re die Idee ein
gr????eres DataSet f??r mehrere Anwendungen zu kreieren. Das ist die
Ausgangssituation f??r meine Frage.
Viele Gr????e
Michael
On Saturday, February 07, 2009 2:01 AM
Peter Fleischer wrote:
Re: Wie viele Tabellen in einem Dataset - Design
"Michael Glander" <***@discussions.microsoft.com> schrieb im
Newsbeitrag news:17E1524E-3A63-44A2-B8E2-***@microsoft.com...
Hi Michael,
jede Anwendung, die irgendwie mit extern abgelegten Daten arbeitet, hat eine
Datenzugriffsschicht. Diese Schicht kann mehr oder weniger abgegrenzt als
separate Methode und/oder auch separate Dll ausgebildet sein. Um den
??berblick zu behalten, sollte man die DAL schon recht deutlich abgrenzen
(eigene Dll's, eigene Namensr??ume, Klassen). Ob sich eine DAL in einer Dll
oder in mehreren Dll's befindet, h??ngt auch wieder von weiteren Bedingungen
ab (z.B. Nutzbarkeit von Teilen der DAL in anderen Projekten).
Ich kann mir nicht vorstellen, dass man f??r die Prozesse in einem
Filmverleih so vile Tabllen ben??tigt. Aber dazu fehlen mir die Kenntnisse zu
den Prozessen im Filmverleih.
F??r jeden Prozess sind diese Fill-Methoden meist anders, da unterschiedliche
Spalten und auch unterschiedliche Tabellen zu verkn??pfen sind.
Wenn der Auftraggeber keine Spezifikation erarbeiten und bewerten kann,
musst du die Kenntnsse aneigenen, um das selbst zu machen.
Das bedeutet, dass du einen gewaltigen Mehraufwand hast, da du die einzelnen
Prozesse mehrfach implementierst. Bevor nicht die Datenbankstruktur fertig
ist, sollte man so wenig wie m??glich implementieren, da jede ??nderung eine
Neuimplementierung von Teilen der Anwendung erfordert.
Wenn es nur Erweiterungen der Datenbankstruktur und die Einf??hrung neuer
Prozesse ist, dann ist das recht einfach, da die alten Prozesse auch ohne
die Erweiterungen weiter funktionieren. Kompliziert wird es, wenn bezeichner
und Typen in der Datenbank zu ??ndern sind.
Um das zu bewerten, m??sstetst du genauer definieren, was du unter DAL
verstehst. DAL als logische Ebene betrachtet, braucht wirklich nur einmal
vorhanden zu sein. Wie viele Namensr??ume, Klassen, Methoden das sind und
auch wie viele dll das aufgetielt wird, h??ngt von vielen anderen Bedingungen
ab.
Wenn du die Prozess auf verschiedene Anwendungen aufteilst und nicht f??r die
einzelnen Prozesse separate dataSets nutzt, dann hast du schnell ein Problem
mit der Reaktionsgeschwindingkeit wegen gro??er Datenmengen im Client.
--
Viele Gr??sse
Peter
On Monday, February 09, 2009 4:18 AM
MichaelGlande wrote:
Hallo Peter,ich habe mich schlecht ausgedr??ckt, die Anzahl der Datasets ist
Hallo Peter,
ich habe mich schlecht ausgedr??ckt, die Anzahl der Datasets ist
entscheidend, nicht der DALs. Und um diese Anzahl sinnvoll zu w??hlen, w??re
ein Anhaltspunkt, wie viele Tabellen (maximal) pro Dataset angemesssen sind
hilfreich. Ich sollte noch hinzuf??gen, dass die Tabellen h??chstens wenige
Tausend Datens??tze umfassen.
Die Datenbankstruktur steht ??brigens schon seit langer Zeit, die ??nderungen
sind ausschliesslich kleinere Erweiterungen.
Viele Gr????e
Michael
"Peter Fleischer" wrote:
On Monday, February 09, 2009 4:26 AM
MichaelGlande wrote:
Re: Wie viele Tabellen in einem Dataset - Design
Hallo Peter,
ich habe mich schlecht ausgedr??ckt: Entscheidend ist die Aufteilung auf
Datasets nicht DALs. Daf??r w??re ein Anhaltspunkt, wie viele Tabellen
(maximal) ein Dataset enthalten sollte, hilfreich. Ich sollte noch erw??hnen,
dass die Tabellen maximal wenige Tausend Datens??tze umfassen.
Die Datenbankstruktur steht ??brigens schon seit langer Zeit, bei den
??nderungen handelt es sich um kleinere Erweiterungen.
Viele Gr????e
Michael
"Peter Fleischer" wrote:
On Monday, February 09, 2009 5:24 AM
Peter G?tz wrote:
Hallo Michael,Wieviele DataTables Du in ein DataSet packst, h?ngtvor allem
Hallo Michael,
Wieviele DataTables Du in ein DataSet packst, h?ngt
vor allem davon ab, ob und wieviele DataTables in
irgendeiner Beziehung (DataRelation) zueinander stehen.
Solange Du voneinander v?llig unabh?ngige DataTables
hast, m?ssen die ?berhaupt nicht in einem DataSet
liegen. Sollen via DataRelation Beziehungen zwischen
DataTables hergestellt werden, dann geht das nur
innerhalb eines DataSets.
Gru? aus St.Georgen
Peter G?tz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
On Monday, February 09, 2009 7:18 AM
MichaelGlande wrote:
Hallo Peter,ja die Relationen sind genau der springende bzw. verbindende Punkt.
Hallo Peter,
ja die Relationen sind genau der springende bzw. verbindende Punkt. Ich habe
eine Datenbank mit knapp 200 Tabellen die alle untereinander in Beziehung
stehen, isolierte Inseln gibt es nicht. M??chte ich die Beziehungen f??r
Comboboxen oder eingebettete DataGridViews benutzen, muss ich die
entsprechenden Tabellen in ein DataSet tun. Wollte ich keine Tabelle in
mehreren DataSets kapseln, m??sste ich ein DataSet mit 200 Tabellen erstellen,
was mir pathologisch erscheint. Gut, ich muss ja nicht alle Tabellen mit
Daten bef??llen, sondern je nach Anwendung nur einen Teil. Aber genau zu
diesem Punkt finde ich keine Tips im Netz. Kann ich getrost ein
Monster-DataSet mit 200 Tabellen erstellen und muss nur bei der
Datenbef??llung aufpassen? Oder muss ich (meiner Intuition folgend) mehrere
DataSets erstellen, in denen ich Teilmengen meiner Datenbank kapsele. Und wie
viele Tabellen darf ich dann in ein solches DataSet unterbringen? Sollte man
vielleicht mehr als 20 vermeiden
Gru?? nach St.George
Michae
"Peter G??tz" wrote:
On Monday, February 09, 2009 8:33 AM
Peter G?tz wrote:
Hallo Michael,In welcher Beziehung stehen diese 200 Tabellenzueinander?
Hallo Michael
In welcher Beziehung stehen diese 200 Tabelle
zueinander
Ich vermute mal, mit einem ver?nderten DB-Desig
liesse sich die Anzahl Deiner Tabellen resp. de
in Beziehung stehenden Tabellen vermindern
DataTables die via DataRelation zueinander in Beziehun
stehen m?ssen im selben DataSet liegen
Was Deine DataGridViews mit den DataRelations z
tun haben, sehe ich bisher nicht
Dann h?ttest Du mehrere DataSets ohne Inhalt
Irgendwas verstehe ich da nicht so ganz
Wie schon erw?hnt, m?ssen DataTables, die vi
DataRelation in einer Beziehung stehen, innerhal
des selben DataSets liegen
DataTables die keine Beziehung zu anderen DataTable
haben, k?nnen als eigenst?ndige DataTables ohn
?bergeordnetes DataSet existieren
Wozu sollen DataTables ohne Inhalt ?berhaupt gut sein
Wenn Du sie nicht mit Daten f?llst, kannst Du vermutlic
ganz auf sie verzichten
Da ich bisher immer noch nicht weiss, was genau D
eigentlich machst bzw. machen m?chtest und wi
Dein DB-Design aussieht und ob und welche DataTable
lokal zueinander in Beziehung gesetzt werden m?ssen
kann ich Dir leider auch keinen Tip geben
Erst mal solltest Du Dein DB-Design mit den 200 Tabellen
die alle irgendwie zueinander in Beziehung stehen, n?he
beschreiben bzw. gleich neu ?berdenken
Die Frage kann ich Dir mit Deinen bisher mehr al
sp?rlichen Informationen nicht beantworten
Soviele wie Du im akt. verf?gbaren Speicherplat
unterbringst
Warum ausgerechnet 20
Warum nicht 5, 99 oder 231
Wie schon erw?hnt, ohne n?here Informationen z
Deinem Projekt, insbesondere Deinem DB-Desig
kann man Deine Fragen nicht beantworten
Gru? aus St.George
Peter G?t
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
On Monday, February 09, 2009 11:33 AM
MichaelGlande wrote:
Hallo Peter,die Datenbank bildet die Gesch??ftsprozesse eines Lizenzh??ndlers
Hallo Peter
die Datenbank bildet die Gesch??ftsprozesse eines Lizenzh??ndlers ab und ist
schon einige Jahre in Betrieb. Ich denke sie ist hinreichend gut designed,
jedenfalls steht eine ??berarbeitung nicht an. Alle Tabellen sind direkt oder
indirekt "verbunden", im Sinne von Tabelle D hat eine Beziehung zu C, diese
zu B und B zu A.
Es gibt insgesamt 15 Applikationen, die auf die DB zugreifen. Eine
M??glichkeit auf die Daten zuzugreifen, w??re also ein DataSet zu erstellen,
dass alle Tabellen und somit alle Relationen beinhaltet. Die Bef??llung mit
Daten w??rde ich dann in den Anwendungen unterschiedlich gestalten. Im Modul
Warenwirtschaft w??rden beispielsweise die Tabellen der Videoabrechnungszahlen
leer bleiben. Trotdem wirkt ein DataSet mit einer dreistelligen Zahl von
Tabellen pathologisch.
Teile ich meinen Datenzugriff auf viele griffige Datasets auf, muss ich
bestimmte Tabellen mehrfach in DataSets kapseln, weil ich Ihre Relationen in
verschiedenen Anwendungen ben??tige, dann gibt es Probleme mit der
Wartbarkeit. Ein Beispiel w??re die Tabelle mit den Filmen. Die
Warenwirtschaft ben??tigt sie, um z.B. den Materialbestand f??r einen Film in
Erfahrung zu bringen. Die Videoanwendung braucht die Tabelle um durch die
verschiedenen Vertr??ge zu navigieren. ??ndert sich etwas an der Filmtabelle,
muss ich nun in jedem Dataset ??nderung vornehmen
Gr????
Michae
"Peter G??tz" wrote:
On Monday, February 09, 2009 12:25 PM
Peter Fleischer wrote:
Re: Wie viele Tabellen in einem Dataset - Design
"Michael Glander" <***@discussions.microsoft.com> schrieb im
Newsbeitrag news:06267EC6-FAC7-466F-ACE4-***@microsoft.com..
Hi Michael
das ist wirklich unverst??ndlich, warum man ein dataSet erstellen muss, was
nur zu einem Bruchteil genutzt werden soll
Wie ich dir bereits geschreiben habe, sollte f??r jeden Prozess ein eigenes
DataSet erstellt werden, welches nur die f??r den Prozess notwendigen
Strukturen enth??lt
Wenn das System 15 Anwendungen hat und ??ber Jahre bereits funktioniert ist
erstens die Wahrscheinlichkeit der ??nderung einer Datenstruktur
vernachl??ssigbar gering und ??nderungen in den Anwendungen um ein Vielfaches
umfangreicher als eine DataSet-??nderung. Solange ein Gesch??ftsprozess nicht
ge??ndert wird, ist auch keine ??nderung des dazugeh??rigen DataSets
erforderlich, auch wenn die Datenbankstruktur um zus??tzliche Spalten
erweitert wird.
Das w??ren mindestens 3 verschiedene Prozesse: Filmverzeichnis (Stammdaten),
Filmausleihe/-r??ckgabe (Bewegungsdaten) und Inventur
(Bewegungskorrekturdaten). F??e jeden Prozess gibt es ein separates DataSet.
Bei der bearbeitung des Filmverzeichnisses braucht man keine Bewegungs- und
Korrekturdaten. F??r die Filmausleihe/-r??ckgabe braucht man nur Teile des
Filmverzeichnisses, aber mit Join verkn??pte weitere Nachschlagetabellen.
Die ??nderung in der Filmtabelle bedeutet, dass die Verwaltung des
Filmverzeichnisses und alle weiteren Prozesse, die die ver??nderte
Filmtabelle nutzen, ??berarbeitet werden m??ssen. Die ??nderung der DataSet's
ist davon nur ein klitzekleiner Bruchteil, der ggf. nicht mal in allen
Prozesses notwendig ist.
--
Viele Gr??sse
Peter
On Tuesday, February 10, 2009 6:37 AM
Peter G?tz wrote:
Hallo Michael,Das heisst aber doch sicher, dass ein einzelner
Hallo Michael,
Das heisst aber doch sicher, dass ein einzelner dieser
Gesch?ftsprozesse lediglich eine Teilmenge der ins-
gesamt von der Anwendung geforderten Funktionalit?ten
und somit wohl auch nur eine ?berschaubare Teilmenge
der in der DB vorhandenen Daten resp. Tabellen ben?tigt.
.... kann ich von hier aus nat?rlich nicht beurteilen.
Wobei ich vermute, dass ein einzelner Gesch?ftsprozess
eben nicht alle diese Tabellen mit ihren wie auch immer
gestalteten Beziehungen ben?tigt, sondern eben nur
eine Teilmenge daraus und genau das l?sst sich vermutlich
f?r diesen einen Gesch?ftsprozess in einem DataSet
abbilden.
Womit eine ?nderung des DB-Designs ohnehin
ausgeschlossen sein d?rfte.
F?r einen einzelnen Gesch?ftsprozess mit einer begrenzten
Menge an Funktionalit?ten wird man sicher nicht alle
in der DB vorhandenen Tabellen und Relationen ben?tigen.
Ein Benutzer kann ja vermutlich nicht 25 Dinge gleichzeitig
tun, sondern wird eher einen Arbeitsgang nach dem anderen
abarbeiten und f?r eben nur diesen Arbeitsgang braucht
er dann wohl auch nur eine Begrenzte Menge an Daten.
Wie schon mehrfach erw?hnt, verstehe ich nicht,
warum Du ein DataSet mit einer Vielzahl von DataTables
erstellen willst, von denen dann doch nur jeweils eine
geringe Menge genutzt und mit Daten gef?llt ist.
Was willst Du mit leeren DataTables?
Wenn sie leer bleiben, sind sie doch ?berfl?ssig.
Ein solches DataSet w?re zwar m?glich, aber ich
kann mir nicht vorstellen, welcher Sinn dahinterstecken
sollte.
Mangels Kenntnis Deines konkreten DB-Designs und
ohne zu wissen, welche Anforderungen Deine einzelnen
Gesch?ftsprozesse stellen, kann ich das nicht beurteilen.
Das sind aber doch offensichtlich zwei verschiedene
Arbeitsabl?ufe, die nicht zeitgleich abgearbeitet werden
und insoweit erst mal wenig bis gar nichts miteinander
zu tun haben.
So ganz verstehe ich immer noch nicht, welches
Konzept Du Dir bei der Sache vorstellst. Ich habe
aber den Eindruck, dass Du unterschiedlichste
Funktionalit?ten, die erst mal gar nichts miteinander
zu tun haben und auch nicht zeitgleich ablaufen in
einer eierlegenden Wollmilchsau vereinigen willst,
anstatt f?r jeden Arbeitsgang ein spezialisiertes
und damit ?berschaubares und leicht zu pflegendes
Programm-Modul zu erstellen.
Gru? aus St.Georgen
Peter G?tz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
On Tuesday, February 10, 2009 8:21 AM
G?nter Prossliner wrote:
Hallo Peter!
Hallo Peter!
Eine Sinn kann das durchaus machen. N?mlich es zu vermeiden f?r ein und die
selbe Entit?t verschiedene Typen zu haben.
Da ich mit typed Datasets normalerweise nicht arbeite kann ich es nicht
100%ig sagen, aber normalerweise ist es bei solchen auf Code-Generierung
aufbauenden Frameworks so, dass jede Datei (=jedes Dataset) unabh?ngig
voneinander generiert werden.
Wenn Du also in 2 Datasets die Tabelle "Customer" drinnen hast, sind das
unterschiedliche Typen f?r die generierten Klassen (Table und Row). Methoden
wie "void ShowCustomer(CustomerRow r)" sind dann (ohne selbst z.b.
Interfaces zu definieren und diese in die parital classes einzuf?gen) nicht
mehr m?glich. Das selbe gilt nat?rlich auch f?r Members welche ggf. (?ber
partial classes) f?r die generierten Klassen implementiert werden.
L?sungen:
1. Interfaces: Wobei das sehr aufwendig werden kann, vorallem bei komplexen
DB-Schema
2. Late-Binding: Neben schlechterer Laufzeit auch sehr "umst?ndliche"
Entwicklung (auch in Sprachen wie VB.Net oder das zuk?nftige C# 4.0 welche
einen "Late-Bound" Modus haben bzw. haben werden). Intellisense, kein
Compile-Time Checking, ...
3. If (... is DataSet1.Customer) / DataSet1.Customer test = customer as
DataSet1.Customer ... also im Endeffekt das Testen und Casten in den
Methoden (wobei die Variablen / Parameter dann immer nur 'DataRow',
'DataTable', ... sind d.h. auch die Kompiler?berpr?fung fehlt).
Bei zentralen Tabellen, welche dann in z.b. 10 verschiedene Datasets
verwendet werden ist das Chaos so perferkt.
Fazit: Ich kenne die Anwendung nicht, und weiss nicht wie die Module
"verschr?nkt" sind. Im Allgemeinen w?rde ich eine L?sung mit mehreren
Datasets (welche ?fter die selben Tabellen beinhalten!) nicht empfehlen.
mfg GP
On Thursday, February 19, 2009 11:40 AM
MichaelGlande wrote:
Hallo G??nther,verzeih meine sp??te Meldung.
Hallo G??nther,
verzeih meine sp??te Meldung. Danke f??r die L??sungsvorschl??ge, ich glaube Du
bist der einzige der mein Kauderwelsch verstanden hat. Ich werde es mal mir
einem Dataset versuchen, sonst so wenig wie m??glich.
Danke auch an die anderen replies. Eine kleine Kritik: wenn jemand sein
Umfeld beschreibt, sollte man ihm auch glauben. Ich entwickle und erweitere
die DB seit 11 Jahren und weiss wie oft ich ??nderungen an der DB-Struktur
vornehmen muss, da sind Hinweise darauf, dass eine Struktur??nderung wohl
ausf??llt nicht sonderlich hilfreich.
Gr????e
Michael
On Thursday, February 19, 2009 12:04 PM
Peter Fleischer wrote:
Re: Wie viele Tabellen in einem Dataset - Design
"Michael Glander" <***@discussions.microsoft.com> schrieb im
Newsbeitrag news:6661C0C6-E300-4D06-81CB-***@microsoft.com...
Hi Michael,
mit meiner Erfahrung bin ich der Meinung, dass eine inline-Datenbank (z.B.
DataSet) zu einem Prozess zu geh??ren hat, den die Anwendung realisiert. Wenn
da mehrere Prozesse in einer oder mehreren Anwendungen zu bearbeiten sind,
dann gibt es bei mir auch mehrere unterschiedliche inline-Datenbanken, die
alle die gleiche externe Datenbank nutzen. Wie immer liegt das Optimum
irgendwo in der Mitte, indem mehrere Prozessabl??ufe u.U. auch den gleichen
Typ der inline-Datenbank nutzen, wenn auch nur teilweise. Bei relativ
kleinen Anwendungen kann das dann ggf. in nur einen Typ der genutzten
inline-Datenbank enden. In diesem Sinne kann ich G??nter zustimmen, nicht
aber der allgemeinen Empfehlung, f??r alle abzubildenden Prozesse nur einen
einheitlichen Typ zu nutzen.
Ich habe auch schon einige Erfahrungen mit Datenbanken und komplexen
L??sungen mit mehreren hundert Tabellen in der externen Datenbank und auch
Kunden mit SAP, wo noch viel mehr Tabellen genutzt werden. Meine ersten
Datenbankprojekte habe ich vor ??ber 30 Jahren geleitet, damals noch auf IBM
360, 370, vor ??ber 20 Jahren dann auf dem DMBS auf VAX, nebenbei Redabas,
dBase, Clipper. daher wei?? ich auch, dass eine schlecht vorbereitete
Datenbankstruktur eine unmenge zus??tzlichen Aufwand bewirken kann. Das
parallele ??ndern einiger ??hnlicher inline-Datenbank-Typen ist da dank der
designer meist der geringste Aufwand. Jede ??nderung in der Datenbank muss
auch von unten (externe datenabnk) bis nach oben (UI) durchgezogen werden.
Und da das meist nicht in allen Prozessen erforderlich ist, ist es auch
nicht notwendig, alle inline-Datenbanken anzupassen.
--
Viele Gr??sse
Peter
Submitted via EggHeadCafe - Software Developer Portal of Choice
Sending SMTP email from within BizTalk Orchestration
http://www.eggheadcafe.com/tutorials/aspnet/9dd0f346-baf9-4674-a50f-1716445b26bc/sending-smtp-email-from-w.aspx