Prinzipielle Herangehensweise bei der Entwicklung von Datenbankanwendungen

17/02/2009 - 23:31 von Dirk Wölfel | Report spam
Hallo zusammen,

eine Frage mal zur ganz allgemeinen Herangehensweise bei der
Entwicklung.

Bisher habe ich immer als erstes Access bemüht und mir einer passende
Datenbank (MDB) entwickelt. Anschließend habe ich darum meine DotNet-
Anwendung gestrickt: Datatables gefüllt, Bindingsources aufgebaut
usw

Visual Studio (2008) bietet aber doch auch integrierte Funktionen zum
Aufbau der DB. Mein Ziel wàre es in meiner Anwendung eigentlich nur
mit Datatables zu arbeiten, die ich auch in Visual Studio entwickle.
Welche Datenbank(-engine) dann dahinter làuft und die Daten annimmt
sollte mir möglichst zu Entwicklungszeit egal sein.

Kann mir jemand ein paar Anregungen / Stichworte zum "besten" Vorgehen
"eine Datenbank-Anwendung mit DotNet" zu entwickeln geben?

Und vielleicht einen Tipp für ein gutes Buch / Tutorial?

Vielen Dank,

Dirk
 

Lesen sie die antworten

#1 Peter Fleischer
18/02/2009 - 06:55 | Warnen spam
"Dirk Wölfel" schrieb im Newsbeitrag
news:

Visual Studio (2008) bietet aber doch auch integrierte Funktionen zum
Aufbau der DB. Mein Ziel wàre es in meiner Anwendung eigentlich nur
mit Datatables zu arbeiten, die ich auch in Visual Studio entwickle.
Welche Datenbank(-engine) dann dahinter làuft und die Daten annimmt
sollte mir möglichst zu Entwicklungszeit egal sein.

Kann mir jemand ein paar Anregungen / Stichworte zum "besten" Vorgehen
"eine Datenbank-Anwendung mit DotNet" zu entwickeln geben?



Hi Dirk,
für die Enwicklung einer Datenbank ist das Visual Studio nur eine der
meöglichen technischen Mittel. Besser geht das mit den direkt dafür
vorgesehenen Mitteln, z.B. MS Access, Management Studio usw. Eine Datenbank
wird anhand der abzubildenden Prozesse, vor allem auch der Primàrbelege und
Ergebnisse entwickelt und dann normalisiert. Das Visula Studio bietet
beispielsweise für die Rechteverwaltung und auch für die Normalisierung
keine Unterstützung, so dass sowieso auf andere Entwicklungswerkzeuge
zurückzugreifen ist.

Üblicherweise arbeiten mit einer Datenbank mehrere Anwendungen. Es ist
sinnlos, für alle Anwendungen die gesamte Datenbank strukturell und
mengenmàßig identisch in der Clientanwendung zu halten. Meist reichen da
schon die Ressourcen nicht aus, um alle Datensàtze in den Client zu laden.
Auch wird nicht in jedem Programm die gesamte Struktur der externen
Datenbank 1:1 benötigt.

Das Visual Studio sollte benutzt werden, um die inline-Datenbank für eine
konkrete Anwendung für den darin abzubildenden Prozess zu entwickeln. Diese
inline-Datenbank liegt dan als typisiertes DataSet, Linq to SQL, EDM oder
auch eigenes Objektmodell vor. Sie sollte optimal auf den Prozess abgestimmt
sein, der mit dem Programm bearbeitet / abgebildet / unterstützt wird. Das
bedeutet, dass diese inline-Datenbank sowohl in Struktur, als auch in der
darin gehaltenen Datenmenge stark von der externen Datenbank abweichen kann.
So können Tabellen und Spalten fehlen, nur einige oder keine Datensàtze
geladen sein, Tabellen zusamengefasst sein (mit JOIN geladen). Auch
Bezeichner können zwischen inlne-Datenbank und externer Datenbank abweichen
und werden ggf. durch Mappingtabellen zugeordnet. Die inline-Datenbank kann
zusàtzliche Eigenschaften haben, für die es kein Äquivalent in der externen
Datenbank gibt. Diese zusàtzlichen Spalten können dem internen
Programmablauf im Client dienen (z.B. Ausdrucksspalten). Für die
Organisation des Datenabgleichs zwischen Client-Anwendung und externer
Datenbank bietet das Visual Studio zusàtzliche Möglichkeiten, wie die
Erzeugung Stored Procedures, die in der externen Datenbank abgespeichert
werden können.

Die obigen Darlegungen sind mein Standpunkt, den ich in vielen Jahren
Erfahrung für meine Projekte entwickelt habe. Dieser Standpunkt deckt sich
teilweise nicht mit den Standpunkten anderer Poster in dieser Newsgroup.

Viele Grüsse
Peter

Ähnliche fragen