Forums Neueste Beiträge
 

off-topic: Braucht jede Anwendung eine Datenbank?

04/10/2007 - 16:43 von Robert Schneider | Report spam
Hallo NG,

ich programmiere und entwerfe so vor mich hin und frage mich des öfteren ob
meine Architektur eigentlich so in Ordnung ist oder nicht. Dabei geht es mir
vor allem um eine Datenbank. Brauche ich eine, oder nicht? In meinem Fall
geht es derzeit auch ohne. Aber ich will darauf vorbereitet sein, wenn
einmal der Wunsch nach einer Datenbank kommt.

Also, irgendwie habe ich den Eindruck, dass alle Anwendungen irgendwie eine
Datenbank verwenden. Zumindestens wenn Entwickler über Architekturen
sprechen. Aber im privaten Endbenutzerbereich scheint mir das wieder anders
zu sein: Word braucht keine, Paint, der Windows-Explorer, Winamp aber auch
Visual Studio.

Es gibt doch zahlreiche Programme, bei denen die Daten direkt in Dateien
gespeichert werden. Wie funktionieren die denn im allgemeinen? Ist schon
klar, dass es da kein allgemeines Konzept gibt, aber mich würde trotzdem
interessieren, welche Möglichkeiten es zum Speichern von Daten außer in eine
DB denn noch gibt? Bei Musik-, Bild- oder Film-Angelegenheiten, wird ja eher
so Stream-màßig auf die Daten zugegriffen. Aber was ist, wenn die Daten eher
hierarchisch aufgebaut sind? Nehmen wir mal z.B. ein Programm wie AutoCAD.
Da entwirft man irgendetwas und speichert das in eine Datei. Welches Format
werden diese Daten wohl haben? Wie gelangen die Daten in die Datei? Wie wird
auf sie zugegriffen? Steckt da sehr viel Handarbeit drin oder bieten
Frameworks etwas?

Es handelt sich ja bei allen genannten Programmen eher um
Standalone-Anwendungen. D.h. eigentlich kann man ja nicht von einem
richtigen (3-)Schichtenmodell reden. Wàre es aber vielleicht dennoch
sinnvoll in dieser Weise zu denken? Zumindestens wenn es um die Datenhaltung
geht? Kommt mir aber auch wieder komisch vor, dass eine lokale Datenbank für
die Anwendung am laufen ist...

Ich vermute mal, dass XML für die Problemstellung von Hilfe sein kann. Ist
XML das richtige Werkzeug?

Und wenn XML nun brauchbar ist, wie ist es dann, wenn ich meine Objekte
(irgendwann mal in der Zukunft) in einer DB ablegen möchte? Was erfordert
das?

Noch eine blöde Frage: Wenn irgendwelche Daten in .NET verwaltet werden,
kommt man dann um den Namespace System.Data eigentlich nicht herum? Wobei
ich das insbesondere für meinen Fall frage, denn ich habe zwar einen Haufen
Daten, aber nicht so etwas wie Name, Adresse, Kundennummer, sondern eher
physikalische Größen, die auch noch teilweise von Berechnungen betroffen
sind. Mir erscheint da etwas eher datenbanktechnisches, bzw. der besagte
Namespace nicht besonders angebracht. Aber vielleicht ist es ja doch besser,
wenn Daten in DB-Strukturen gehalten werden...

Also, wie verhàlt sich das mit Daten, die vielleicht nicht unbedingt mit
einer DB etwas zu tun haben? Wie strukturieren, wie darauf zugreifen?

Hoffe, ihr könnte mir da ein wenig auf die Sprünge helfen. Dabei geht es mir
nur in zweiter Linie um .NET.

Es grüßt euch
Robert

e-mail: r_.s_chnei_der\wein_gart_ner.com (remove all '_' and replace '\'
with
'@')
 

Lesen sie die antworten

#1 Torsten Kerz
04/10/2007 - 17:26 | Warnen spam
Hallo Robert.

Also, irgendwie habe ich den Eindruck, dass alle Anwendungen irgendwie
eine Datenbank verwenden. Zumindestens wenn Entwickler über
Architekturen sprechen. Aber im privaten Endbenutzerbereich scheint mir
das wieder anders zu sein: Word braucht keine, Paint, der
Windows-Explorer, Winamp aber auch Visual Studio.



Die Aussage ist - wenn man es genau betrachtet - nur teilweise richtig. Dazu muss man nur kurz einmal nachdenken, wie
man eine Datenbank eigentlich definieren könnte. Letztendlich ist jede Datenbank "nur" ein Framework zum schnellen und
permanenten Speichern und wieder auffinden unterschiedlicher Informationen.

Mit dieser Betrachtungsweise könnte man nun schlichtweg behaupten, daß auch Word seine Dokumente in einer "Datenbank"
speichert. Nur bringt Winword dafür eben ein ganz eigenes, an die speziellenen Notwendigkeiten angepasstes Framework
mit. Selbst bei Programmen ohne eigenes Dateiformat werden zu 99% permanente Daten verwaltet - sàmtliche Einstellungen
werden in eigenen INI-/CFG-Dateien oder auch in der Registry (auch eine spezialisierte Datenbank) abgelegt.

Die einzige Frage dabei ist letztendlich lediglich, wie viel Komfort man benötigt.

Es gibt doch zahlreiche Programme, bei denen die Daten direkt in Dateien
gespeichert werden. Wie funktionieren die denn im allgemeinen? [...]
mich würde trotzdem interessieren, welche Möglichkeiten es zum Speichern
von Daten außer in eine DB denn noch gibt?



Im allgemeinen wird schlichtweg festgelegt, wie der innere Aufbau der jeweiligen Datei aussehen soll. Dabei stehen
natürlich alle Möglichkeiten von "sehr einfach" (z.B. fortlaufende Text-Liste mit Editor eingegeben) bis Hochkomplex
(Baumstrukturen mit Indizes, Allokationstabellen, Strukturbeschreibungen, etc.) zur Verfügung. Da die Struktur durch den
(oder die) Entwickler bestimmt wird, gibt es keine Grenzen.
Ansonsten kann man natürlich diverse Hilfen wie z.B. die Registry oder eben auch Datenbanken benutzen.

Welches Format werden diese Daten wohl haben? Wie gelangen
die Daten in die Datei? Wie wird auf sie zugegriffen? Steckt da sehr
viel Handarbeit drin oder bieten Frameworks etwas?



Die Formate der meisten Dateitypen können im Internet gefunden werden. Natürlich muss man sich meist einige Zeit
einarbeiten oder auch weitere Algorythmen umsetzen, um mit einigen Dateien arbeiten zu können. Als Beispiel seien
einfach mal die unterschiedlichen Bildformate genannt: hier wird mit Datenkompressionen gearbeitet, welche natürlich vor
dem Verwenden der Daten wieder rückgàngig gemacht werden muss.
Die meisten Zugriffe dieser Art dürften wohl Handarbeit sein. Allerdings gibt es auch für die unterschiedlichsten
Dateitypen bereits Codebeispiele oder gar ganze Bibliotheken zum Lesen und Schreiben im Internet.
Unter der Haube endet alles bei einem Dateizugriff. Hierfür hast Du im Dotnet-Framework durch Streams oder auch
"OPEN"-Befehle die rudimentàre Unterstützung zum Zugriff auf beliebige Dateien. Auch Datenbanken sind keine Magie, denn
letztendlich greifen auch diese nur auf Dateien zu. Das "Geheimnis" von Datenbanken ist schlichtweg ein extrem
ausgeklügeltes Dateiformat und der gesamte Verwaltungsaparat drumherum.
Die Menge der Handarbeit ist nur eine Frage des gewünschten Ziels und dessen Komplexitàt :)

Es handelt sich ja bei allen genannten Programmen eher um
Standalone-Anwendungen. D.h. eigentlich kann man ja nicht von einem
richtigen (3-)Schichtenmodell reden. Wàre es aber vielleicht dennoch
sinnvoll in dieser Weise zu denken? Zumindestens wenn es um die
Datenhaltung geht?



Ich glaube, daß diese Frage bereits erklàrt sein dürfte. :)
Prinzipiell ist es sicher kein Fehler, eine Anwendung klar in einzelne Schichten zu unterteilen.

Ich vermute mal, dass XML für die Problemstellung von Hilfe sein kann.
Ist XML das richtige Werkzeug?



So richtig oder falsch wie jedes andere Werkzeug auch.
Zuerst sollte einmal über die Anforderungen nachgedacht werden. Brauche ich Indizes? Sequentiellen oder zufàlligen
Datenzugriff? Sind große Datenmengen zu erwarten oder eher kleine? Werden die Daten über Netzwerk oder gar
DSL/ISDN/Modem übertragen?

XML mag praktisch sein, da es ein lesbares Textformat ist. Unpraktisch wirds dann aber bei der Datenübertragung, wo
binàre Datenformate bei gleichen Dateninhalt um ein vielfaches kleiner sind. Klar làsst sich XML gut komprimieren -
letztendlich wird eine XML-Struktur aber niemals so klein werden, wie ein binàre Pendant.

Und wenn XML nun brauchbar ist, wie ist es dann, wenn ich meine Objekte
(irgendwann mal in der Zukunft) in einer DB ablegen möchte? Was
erfordert das?



XML ist sicherlich brauchbar. Aber eben nicht gleichermaßen für alle Aufgaben. Ebenso kann ich mit einem Auto auch keine
30 Tonnen Sand durch die Gegend fahren (zumindest nicht ohne extreme Umbauten), im Umkehrschluss aber auch nicht mit
einem dafür geeigneten LKW 150 km in einer Stunde zurück legen. :)

Noch eine blöde Frage: Wenn irgendwelche Daten in .NET verwaltet werden,
kommt man dann um den Namespace System.Data eigentlich nicht herum?



Aber sicher doch. System.Data ist lediglich das Grundmodell von Microsoft. Entsprechende Modelle gibt es z.B. auch ganz
speziell für MySQL (deren DLL orientiert sich im Aufbau an System.Data) oder auch DB4O, was ein ganz anderes Modell
aufweist.

Also, wie verhàlt sich das mit Daten, die vielleicht nicht unbedingt mit
einer DB etwas zu tun haben? Wie strukturieren, wie darauf zugreifen?



Verwirf mal deine Trennung von "Adress-, Personen-, Rechnungsdaten etc." und "irgendwelchen Zahlenwerten". Auch
beliebige Zahlenwerte können in einer Datenbank sinnvoll untergebracht werden. So unterstützt dich eine Datenbank ja
z.B. auch dabei, wenn du den kleinsten oder größten Wert suchst oder auch die Summe benötigst.

Soweit mal,
Gruß,
Torsten.

Ähnliche fragen