Datenbanken in Java - wie am besten?

[SlaterTh90]

Hallo CB-Forum,
ich brauche aktuell für ein Projekt mit Java eine Datenbank, denn ich will größere Mengen an Informationen speichern. Allerdings will ich die genaue Struktur der Datenbank nicht vorher komplett festlegen, also ehr was dynamisches. Beispiel:

Tabelle mit Namen, das ist festgelegt. Dann hat jeder dieser Einträge jedoch eine variierende Wahl an Zusatzinformationen, zB könnte einer eine Telefonnummer haben, der andere aber ne E-Mail, 2 Telefonnummern und ne Notiz.

Kann mir wer sagen wie ich das am besten realisiere? Bestenfalls sollte das ganze Lokal sein, also ohne Server auskommen.

 

[Seiyaru2208]

Also wenn ich das richtig verstanden habe willst du eine Default Datenbank haben ohne selbst eine Struktur festzulegen?

Wie viele Sollen darauf zugriff haben? Du hast ja davon gesprochen das, verschiedene User eine andere Maske bzw. Informationen erhalten sollen?

Also ich sehe da am ende nur den weg das du es auf einen Server (geht auch ein client der in den Geschäftszeiten hochgefahren ist) installierst der im Netzwerk erreichbar ist, lokal auf jedem Rechner kann der client installiert sein die DB muss aber im Netzwerk liegen meiner Meinung nach.

Am ende kannst du jeden Benutzer die Informationen filtern, dies wird aber am ende mit einem kleinen Rechtemanagement einhergehen, denn wie soll die Datenbank erkennen welcher User welche Information erhalten soll.

 

[SlaterTh90]

Also ich hab mir das so Vorgestellt:

Man fragt sozusagen nach dem Namen "Karl", dann bekommt man die ganzen Daten die dazu gehören geliefert. Was man dann bekommt will ich aber bestenfalls nicht festlegen.

Das ganze soll eigentlich nur auf einem System laufen, deswegen besser kein Server.

 

[MainframeX]

Wenn wirklich keine Zentrale Pflege der Daten nötig ist und nur lokal zugegriffen wird, dann würde ich mal SQLite in den Raum werfen.

 

[e_Lap]

Hibernate, als framework. Simpel zu nutzen, mappt dir deine objekte automatisch in tabellen.

 

[SlaterTh90]

SQLite hab ich schon gesehen, aber ich glaube man muss dort die Struktur vorher anlegen. Hibernate kenn ich noch nicht, muss ich mir gleich mal ansehen.

 

[Faust2011]

Tabelle mit Namen, das ist festgelegt. Dann hat jeder dieser Einträge jedoch eine variierende Wahl an Zusatzinformationen, zB könnte einer eine Telefonnummer haben, der andere aber ne E-Mail, 2 Telefonnummern und ne Notiz.

Kennst Du Dich denn bereits mit Datenbanken aus? Wenn ja, dann modelliere doch mal ganz abstrakt Dein Datenmodell, z. B. als ER-Diagramm. Deine Personen-Entität könnte ganz generisch auf eine Attribute-Entität verweisen (im Sinne einer 1:N Relation), die nichts weiteres als einen Key und einen Value (Datentyp CLOB) hat. Das wäre eine ganz spontane Idee, um extreme Flexibilität im Datenmodell zu bekommen. Andererseits verlierst Du damit natürlich jegliche Art von Typisierung und Informationsgehalt, d.h. alleine aus dem Datenmodell kann man später nicht mehr die Verwendung rekonstruieren.

Kann mir wer sagen wie ich das am besten realisiere? Bestenfalls sollte das ganze Lokal sein, also ohne Server auskommen.

Wäre die Frage, ob Du überhaupt eine Datenbank brauchst. Willst Du vielleicht nicht besser einfach Deine Java-Objekte serialisieren? Eine andere Idee wäre, statt einer klassischen relationalen Datenbank eine NoSQL zu verwenden. Mit einer Dokumenten-orientierten NoSQL würde Du spielend Deine geforderte Flexibilität errreichen.

 

[FUSION5]

Was Du willst klingt für mich nach einer ganz einfachen Standardlösung des Datenbankdesigns. Vielleicht solltest Du Dir dieses Wissen erstmal aneignen.

Was Du im Grunde brauchst ist eine einfache 1:N Beziehung der Datensätze.

Tabelle Kunde
ID Namen
1 Peter
2 Karl

Tabelle Telefon
ID Nummer
1 040333
1 0160123

Tabelle Email
ID Email
1 1@1.de
2 Karl@1.de
2 Karl80@gmail.com

Tabelle Adressen
ID Straße Hausnummer PLZ Ort
... usw.

Festnetznummern könnten ggf. auch den Adressen zugeordnet sein.

Im Endeffekt ist für jeden Kunden nur der Name (plus eine unique ID) notwendig. Alle anderen optionalen Daten werden über die ID zugeordnet und können N-mal vorhanden sein (müssen aber nicht). Beim Aufbau der GUI lädst Du dann einfach die entsprechenden Datensätze.

Welches DBMS Du dafür nimmst ist im Grunde egal. MySQL wäre evtl. ne Idee.

 

[SlaterTh90]

Das ich von Datenbanken noch nicht viel Ahnung hab ist schon richtig Bisher gabs noch keinen Grund sich damit zu beschäftigen.

Die beiden Vorschläge hören sich beide gut an, für mich wären serialisierbare Objekte einfacher, die Frage ist ob das von der Performance reicht. Ich rechne erstmal mit ca 500 Objekten, jeweils etwa 20-60 Eigenschaften. Ich hab keine Ahnung ob es da beim Laden Probleme geben könnte.

 

[e_Lap]

hibernate ist genau dafür da. Performace brauchst du dir da erstmal keine Gedanken zu machen. Das schafft der locker.

Du hast nen pojo und per annotations spezifizierst du, wie dieses object in ne db serialisiert werden soll.

 

[Piktogramm]

Sqlite ist recht Einfach und wenn du nur nach Namen suchen magst, dann machst du eine Tabelle mit Namen und eine Zweite als "Blob" oder Text, wo du alles reinschreiben kannst was du magst. Blob und "Name" müssen noch verknüpft werden und gut. Den Blob kannst du dann jeweils parsen wie du lustig bist.

Oder aber, bei nur 500 Datensätzen Textfile/XML schreiben und parsen.

 

[e_Lap]

Es geht ihm eher um das serialisieren von java objekten und nicht den Grundaufbau einer db.

 

[Osiris1]

Ich persönlich würds so machen vom Schema her:
(1:N Beziehung)

Person
--------------------------
ID # Name # Adresse # ...
--------------------------
1 # Karl # irgendwo # ...
2 # Hans # sonstwo # ...
...
--------------------------


ExtraAttributes
--------------------------
ID # Person.ID # Name # Value
--------------------------
1 # 1 # Name des ersten Haustiers # Mauzi
2 # 1 # Random Attribut # Random Wert
3 # 2 # Name des zweiten Hundes # Striker
...
--------------------------

In der Person Tabelle legst du für jedes Attribut das vermutlich alle haben werden (email, vor-, nachname, adresse, etc...) eine eigene Spalte an.

In der ExtraAttributes Tabelle legst du Extraeinträge an die sich schlecht kategorisieren lassen. Die bestehen immer aus einer Bezeichnung (Name) und einem Wert (Value). Name kann vom Typ her String sein. Value musst du dir überlegen. Dort musst du immerhin alle möglichen Informationen speichern können. Also fällt Long oder Int schon einmal aus. String wäre eine Möglichkeit, aber ich weiß nicht ob es die beste ist. Da solltest du recherchieren. Natürlich musst du immer noch dazu speichern zu welcher Person das Attribut gehört (Person.ID).

Auf die Art musst du die Struktur deiner Datenbank beim Speichern nicht verändern. Ich bin mir nicht einmal sicher ob das überhaupt möglich, bzw. eine gute Idee ist.

Als Datenbank würde ich SQLite verwenden und als Java-Framework Hibernate. Für Hibernate wirst du etwas Einarbeitungszeit brauchen. Aber es lohnt sich.

EDIT: Damit wirst du zwar nicht ohne Server auskommen. Aber der ist lokal in 5 min aufgesetzt. Zum Beispiel mit xamp.

 

[SlaterTh90]

Ich guck mal, sowas ähnliches teste ich gerade. Ich hab Klassen, zB Person, die dann ein Array mit Objekten vom Typ Attribut haben. In diesen Attributen ist dann jeweils ein Bezeichner, ein "Value" und noch ein paar extra Sachen zur Grafischen Darstellung gespeichert.

Die Frage ist nun, ob es sinnvoller ist die Objekte in eine Tabelle zu hauen, oder das in etwa so wie oben zu Lösen, also gemeinsames Filtern und schlecht definierbares einzeln machen.

 

[Serious_Sam]

JDBC und Apache Derby?

 

[Osiris1]

Wie meinst du die Objekte in eine Tabelle hauen? Die Telefonnummern/Adressen?

Ganz einfach:
- 1 Eintrag: zb Name, Geburstag...
- da wo du 2 oder mehr Einträge brauchst (Adresse, Telefonnummer), gibts jeweils eine eigene Tabelle.
- dann noch eine Extra Tabelle für alles nicht definierbare.

In Hibernate wird das Attribut in der Person Tabelle wohl eine ArrayList oder eine HashMap sein.

Oder hab ich das falsch verstanden?

 

[SlaterTh90]

Ne ich meinte das so stumpf wie es klingt - wirklich das ganze Object darein speichern, also ne Tabelle ID | Objekt (als Binär oder XML... )

Allerdings hab ich mich mal mit XML beschäftigt, das macht glaube ich mehr Sinn.

 

[Osiris1]

Ah okay. Das geht natürlich auch. Wäre interessant was hier bei größeren Firmen/Datenbanken best practice ist.

 

[Piktogramm]

@Osiris1

"best practice" ist, wenn möglich immer nur eindeutige Daten in einer eindeutigen Struktur mit konsistentem Datentyp vorliegen zu haben und das dann schön in normalisierten Datenbankstrukturen. Wenn das nicht möglich ist, sollte man zumindest zusehen, dass man in nicht vorhersehbare Datensätze eine Grundstruktur aufgezwungen bekommt. Der Ende dieses Posts enthält eine Möglichkeit Daten eine Struktur zu verpassen, obwohl die Datenformate nicht präzise vorhergesagt werden können.
Mitunter schreibt man so einen riesen Block an Logik die Eingaben auswertet und passend strukturiert, macht das Leben aber bei der restlichen Entwicklung deutlich einfacher.

Real gibt es Programme, wo sich an der Stelle keine Mühe gegeben wurde und wenn man den Scheiß dann administrieren oder gar weiter entwickeln soll... Naja, hat man wenigstens Gruselgeschichten für den IT-Stammtisch und Konferenzen -.-

----------------------------------------------


Objekte als Binärblob in eine Tabelle schmeißen geht bei den meisten Datenbanksystemen. Damit geht nur Struktur verloren und die Durchsuchbarkeit der Daten wird übel. An einem gewissen Punkt kann man sich dann auch sparen überhaupt eine Datenbank einzusetzen, man kann dann genausogut einen riesen Blob direkt ins Filesystem absetzen.
Das Problem ist, alles was du nicht an Struktur von Anfang an festschreibst musst du später zu Laufzeit inkl. aller möglichen Fehler selbst behandeln. Das geht normalerweise einfach nur schief.

Du kannst natürlich anstatt eines Binärblobs die Daten auch als XML bzw. ähnlich strukturieren und beispielsweise als Text (Datentyp in Sqlite) bzw. äquivalenten Datentypen in anderen DBS verwenden. Damit lassen sich die Daten dann auch suchen (wenn auch vergleichsweise langsam). Auch hier kann es durchaus die bessere Idee sein die Daten als XML einfach direkt dem Dateisystem anzuvertrauen.

Je Strukturierter du die Daten ablegst, desto eher lohnt eine Datenbank. Wenn ein Großteil der Namen sowieso eine oder mehr Telefonnummer und/oder Anschrift, Emailadresse, Geburtsdatum zugeordnet bekommen, dann sieh dafür Tabellen vor und schmeiß nur alle untypischen Erweiterungen in eine Tabelle, die XML Ähnliche Einträge aufnimmt.
Beispiel:


Dabei identifiziert Name.name_ID als Primärschlüssel die Person eindeutig. Über name_ID sind die Werte in Tabelle Ergaenzung zugeordnet. bezeichner enthält dann was es sein soll und inhalt den eigentlichen Datensatz. Könnte also so aussehen:

Ergaenzung.name_ID=1
Ergaenzung.bezeichner="Blutgruppe"
Ergaenzung.inhalt="AB"

 

[SlaterTh90]

Ich glaube ich versuche das mal so mit XML umzusetzen. Das sollte es auch möglich machen mit ner anderen Sprache wie zB C# an die Daten zu kommen.

Bei der Menge an Daten könnte man doch auch noch Sachen die man durchsuchen möchte in extra-Listen packen und sortieren für eine Binärsuche denke ich, dass wäre auf jeden Fall schnell dann.

Nachtrag:
Ich hab mal nen Test mit Beispielwerten gemacht, in einer XML-Datei sind das jetzt 30 000 Zeilen, irgendwas mit 1,32 Megabyte. Denke das sollte noch kein Gerät vor ein Problem stellen oder? (Ich hab echt keine Ahnung wie lange sowas dauert mit einladen und ab wann das zu viel wird....) Jetzt muss ich ja eigentlich das ganze nur noch in mehrere Dateien schreiben statt in eine, dann guck ich mal mit der Datenbank.