# Ab wann Datenbank verwenden



## Gast (25. Dez 2006)

Hallo Zusammen,

welche Kriterien verwendet hier, um zu entscheiden, ob ihr die Daten Eueres Programms in einer Datenbank oder in Dateien speichert?

KLar die Anzahl der Datensätze, aber ab wann würde sich eine Datenbank lohnen und wann reichen Dateien?

Danke für Euere Tipps...


----------



## Wildcard (25. Dez 2006)

Unter anderem sind folgende Kriterien zu beachten:
Sind die Daten auch für andere Programme interessant
Sollen die Daten nach verschiedenen Kriterien durchsuchbar sein
Sollen die Daten zentral oder dezentral abgelegt werden.
Versionskontrolle erforderlich
Muss das System skalierbar sein


----------



## Der Programmierer (25. Dez 2006)

> Muss das System skalierbar sein



Das spielt doch keine Rolle???
Ich schreibe gerade ein Programm mit Dateisystem und es ist trotzdem sehr gut(!) skalierbar und dies war auch nur mit relativ wenig Arbeitsaufwand verbunden.


----------



## meez (26. Dez 2006)

Der Programmierer hat gesagt.:
			
		

> Das spielt doch keine Rolle???



Für HelloWorld mag das noch stimmen...Für "richtige" Business Anwendungen aber nicht mehr...


----------



## Der Programmierer (27. Dez 2006)

> Für HelloWorld mag das noch stimmen...Für "richtige" Business Anwendungen aber nicht mehr...



Also bis 50.000 Klassen funktioniert mein Schülerverwaltungssystem noch relativ schnell und es ist skalierbar!!


----------



## byte (27. Dez 2006)

Du meinst 50.000 Objekte !?


----------



## Gast (27. Dez 2006)

Also 50.000 Datensätze habe ich natürlich nicht, im Maximalfall 1000 pro Datei.

Mich würde interessieren, wie Du die Datensätze speicherst. Ein Wert pro Zeile oder mehre Werte pro Zeile, durch irgendetwas getrent? Ich habe mal irgendwo gelesen, das es problematisch sein könnte mit eine Streamtokinizer die Datensätze irgendwie zu trennen, aber wahrscheinlich nur dann wenn man vergessen hat, den User daran zu hindern das Trennezeichen selber einzugeben bzw. \n oder so...

Gruß


----------



## dhachim (27. Dez 2006)

naja es kommt ja auch drauf an ob du deine Dateien Persistent speichern willst.  --> ACID Prinzip (Transaktionen)

Ich geniese es wenn mir meine Datenbank auch kontrolliert, was ich da so ablege, und dass ich ne hohe Datensicherheit bekomme, also ich immer sicher sein kann das das was ich schreibe auch wirklich da steht wo ich es hinhaben will.

Recovery ist ja auch noch ein Thema, das man in Java Programmen nicht abfangen kann. Wenn einmal die JVM abschmiert sind auch meine geplanten Eingaben futsch.

UNd dann natürlich die Performance. Resultsets bringen ja immer mächtig speed in die Sache.


Ein weiteres Kriterium ist die komplexität der Anwendung, ich versuche immer möglichst viel auszulagern.


----------



## Gast (27. Dez 2006)

Welches Datenbanksystem verwendest Du denn?

Gruß


----------



## robertpic71 (27. Dez 2006)

byto hat gesagt.:
			
		

> Du meinst 50.000 Objekte !?



Ich denke, er meint 50.000 *Schul*klassen.  :wink: 

Anwendungen ohne Datenbank in die Micky Maus/HelloWorld-Schublade abzulegen ist sicher nicht ganz richtig. Es gibt durchaus größere Anwendungen welche große Datenmengen ohne Datenbank verwalten (z.B. Mailserver). Aber die Mailordner lassen sich auch sehr gut mit einer Verzeichnisstruktur nachbilden. Solange ich also keine übergreifenden Abfragen (über mehrere Ordner) benötige, fallen die Nachteile auch nicht groß auf.

Aber im Normalfall hat man nicht so viele "unstruktierte Daten" wie ein Mail-Server. 

Eine Datenbank "rechnet" sich (mMn) vom Aufwand schon bei kleinen Aufgaben. Viele Datenabfragen wie: "Volltextsuche, Sortierung, Gruppierung, Summenfunktionen, kleinster- und größter Wert" lassen sich meiner einer SQL-Zeile bewerkstelligen. Auch Anforderungen  wie "Gibt es diese Person/den Datensatz" oder eine Änderung für eine ganze Datengruppe produzieren wesentlich mehr Javacode als SQL-Code.

Aber die "unausweichlichen" Argumente für eine Datenbank sind:

*Mehrbenutzerbetrieb*
Wenn mehrere Programme/User das selben File ändern wollen, wird es kompliziert. Bei Files kann ich nur das gesamte File sperren, in der Datenbank kann ich einzelne Sätze sperren. 

*Transaktionskontrolle*
Zusammengehörige Updates wie z.B. eine Buchung in der Finanzbuchhaltung (Update Sollkonto + Update Habenkonto) sind eine Transaktion und werden von der DB immer ganz oder bei Fehlern gar nicht durchgeführt.

*Sicherheit*
Je gibt es noch einige Möglichkeiten die DB ausfallssicher zu machen z.B. Spiegelung.

*Performance*
Bei großen (strukurierten) Daten ist eine Datenbank mit ihren vorangelegten Suchindexen um Häuser schneller. Files kann man außerdem nur für eine Suchart struktuieren - bei Datenbanken kann ich (fast) bebliebig viele Suchwege/Indexe anlegen. 


Zum Thema Schülerverwaltung:
Bei einer Schülerverwaltung spricht normalerweise NICHTS gegen eine Datenbank. Nur weil ein Computer stark genug ist, 50.000 Schulklassen zu verwalten, ist die Lösung noch nicht automatisch "skalierbar". Eine reine Filelösung hat sicher einige Nachteile gegebenüber einer Datenbank (wie gesagt Mehrbenutzerbetrieb, Performance, Ausfallsschutz usw.). Diese Nachteile selber zu lösen, hätte was vom "Rad neu erfinden".

@Gast:
Wenn man User keine extra Installation der DB zumuten will, gibt 
es embedded Java-Datenbanken (Derby, HSQL und mein neuer Liebling H2), welche einfach mit dem Programm gebundelt werden können.

Beruflich verwende ich hauptsächlich DB2, daneben noch Oracle, MSSQL, PostgreSQL, H2 und (leider) auch Access. 
Wenn es eine eigenständig DB sein soll/darf empfehle ich PostgreSQL + pgAdmin. Ansonsten eine von den oben angeführten einbauten Javadatenbanken.

MySQL find ich nicht so toll, da der SQL-Syntax nich ANSI-SQL-Norm ist.


----------



## Balian (27. Dez 2006)

Danke erstmal für Deine Informationen...

Ich denke an eine embedded-Datenbank, bin mir nur nicht sicher welche die Richtige ist. Wichtig ist mir persönlich die Lizenzfrage. Man weis ja nir ob ein programm mal kommerziell wird und ich würde natürlich dem User nur eine .jar_datei ausliefern wollen.(nicht stisch verlinken usw)

Gruß


----------



## dhachim (28. Dez 2006)

DB2 *hust*

Unschlagbarer Vorteil von MySQl ... Plugable Storege Engines


----------



## robertpic71 (28. Dez 2006)

dhachim hat gesagt.:
			
		

> DB2 *hust*
> 
> Unschlagbarer Vorteil von MySQl ... Plugable Storege Engines



Hauptmotivation für die pluggable Storage Engines war sicher die Unabhängigkeit von InnoDB, nachdem diese ja von Oracle aufgekauft wurde.... Aber vielleicht wird ja aus MySQL mal wirklich eine Hochleistungs-Datenbank  *undwegduck* - denn auf diese Weise können sich auch andere Firmen auf den MySQL-Zug aufspringen. Aber im Moment würde ich ich das nicht unbedingt als "unschlagbaren Vorteil" sehen.

als Nachteile von MySQL sehe ich:
- SQL-Syntax nicht ANSI-Norm (nervt wenn man viel mit verschiedenen DB's arbeitet) 
- nicht wirklich frei (wie z.B. PostgreSQL)
- bei großen Datenmengen deutlich langsamer als Oracle und  MSSQL (DB2 mit Vorbehalt: wir verwenden DB2 nur auf Hostsystemen)


----------



## Guest (29. Dez 2006)

robertpic71 hat gesagt.:
			
		

> dhachim hat gesagt.:
> 
> 
> 
> ...


Die Typen von MySQL haben SAPDB an sich gekrallt. Wenn künftige Versionen von MySQL darauf 
basieren werden (z.Z. nur MaxDB), dann hast du deine Hochleisungs-Datenbank ... für Arme.


----------



## Gast (29. Dez 2006)

Sagt mal kann man PostgreSQL auch als embedded-DB verwenden?

Danke


----------



## robertpic71 (29. Dez 2006)

Gast hat gesagt.:
			
		

> Sagt mal kann man PostgreSQL auch als embedded-DB verwenden?
> 
> Danke



Dazu müsste es schon eine Java-DB sein. 

Das höchste der Gefühle wäre ein Installer, welcher auch die Installation der Postgre-Datenbank mitmacht. Das wird meiner Erfahrung nach aber eine ziemliche Bastelei und schaut für jede Plattform (Windows, Linux) komplett anders aus.

Der Betrieb wäre dann der normale Client/Server. Wenn man Pech hat, spuckt einem die lokale Firewall (beim User) in die Suppe.

Mit HSQL und Derby stehen aber 2 ausgereifte Java-DB's zur Verfügung. Die Java-DB H2 gibt es noch nicht so lange, aber Probleme hatte ich damit auch keine. H2 ist unter der Mozilla Public Lizenz und frei - auch im Einsatz von (weiterverkauften) kommerziellen Lösungen.


----------

