Fragen zur Datenspeicherung

Diskutiere Fragen zur Datenspeicherung im Java Basics - Anfänger-Themen Bereich.
C

christian30251

Super danke!
Hab mich mal etwas eingelesen. So wie ich das verstehe braucht für JSON externe Libraries oder? XML würde lt. API-Doc mittels XMLDecoder bzw. XMLEncoder funktionieren. Stimmt das so in etwa?
 
H

httpdigest

Was sind denn ganz konkret überhaupt deine Anforderungen zwecks Datenformat? Soll das Ergebnis menschenlesbar sein? Hast du konkrete Anforderungen bezüglich der Elemente/Attribute, die auftauchen sollen? Javas XMLEncoder ist ja nun schon sehr "generisch" und erzeugt auch sehr generisches und "Java-spezifisches" XML, was gedacht ist, um von dem XMLDecoder verstanden zu werden. Das produzierte XML ist z.B. nicht geeignet als Datenaustauschformat zwischen zwei unabhängigen Anwendungen, sondern als Austausch zwischen einem XMLEncoder und einem XMLDecoder, die über denselben Classpath verfügen, um die Klassen entsprechend zu deserialisieren, da in das XML ja auch direkt die Java-Klassennamen reingeneriert werden. Das möchte man eventuell nicht haben. Das Format ist unter Umständen dann auch nicht "stabil", da es sich ja (wie beim ObjectOutputStream) von Java-Version zu Java-Version ändern kann.
Im Allgemeinen versucht man Datenaustauschformate unabhängig von der verwendeten Programmiersprache bzw. -pattform zu definieren.
 
C

christian30251

Also bei mir ist es so:
Ich beginne im Herbst eine Berufsausbildung zum Softwareentwickler Java, die 10 Monate dauert (berufsbegleitend). Um die Lernkurve möglichst steil zu machen, absolviere ich gerade einen Onlinekurs für Java. Und da man Coden ja bekanntlich nur durchs Coden selbst lernt, hab ich mir mal überlegt was für einen Anfänger gut umzusetzen wäre -mit meinem kleinen Projekt mit den Medikamenten habe ich einen Praxisbezug.

Ich verstehe schon einiges von Java, nicht zuletzt da der Kurs sehr gut ist, dennoch stehe ich am Anfang. Das ist mir völlig klar.
Ich habe für mein Medikamentenprogramm jetzt eine kleine GUI mit Swing gebastelt. Wo ich mir nur schwer tue ist, die GUI mit der Logik zu verknüpfen - nach dem MVC Prinzip. Daran sitze ich momentan. Die Logik ist noch nicht fertig, aber genau das möchte ich ja jetzt umsetzen (lernen). Am schwierigsten finde ich die Überlegungen, was brauche ich z. B. an Klassen, Methoden usw. Das Coden selbst ist - mMn - eigentlich nicht der schwierigste Part.

Und hier stellt sich für mich eben die Frage: Wie speichere ich die Daten, so dass sie nach dem Beenden des Programms wo gesichert sind bzw. ich sie das nächste Mal wieder öffnen/bearbeiten/ ... kann. Und als für Anfänger vorerst am einfachsten machbar erschienen mir JSON oder XML. Lasse mich aber gerne eines Besseren belehren.
:) Danke!
 
W

White_Fox

Auch nach Lesen deines Posts: Wähle CVS. Wenn du es gut machen willst, so daß es am Ende vielleicht tatsächlich sogar benutzt wird, ist das schon mehr Arbeit als man denkt.

Wenn du geschickt sein willst, dann realisiere es so daß du das Dateiformat möglichst einfach wechseln kannst. Dann hast du auch mehr gelernt als dich gleich sofort für das "richtige" Datenformat zu entscheiden - und wechseln kannst du später trotzdem noch, wenn du willst.
 
T

temi

Wenn du geschickt sein willst, dann realisiere es so daß du das Dateiformat möglichst einfach wechseln kannst.
Da stimme ich voll zu. Beginne mit einem Interface z.B. DataWriter in dem du die notwendigen Methoden deklarierst. Mach mit einer Klasse CsvDataWriter weiter, die das Interface implementiert. Dann kannst du später immer noch einen XmlDataWriter, einen JsonDataWriter oder sonstwas dagegen austauschen.
 
B

BestGoalkeeper

Auch nach Lesen deines Posts: Wähle CVS.
CSV ist obsolet. Schon seit zig Jahrzehnten. Es braucht nur mal ein Semikolon codiert werden müssen (was ja durchaus bei Medikamentennamen vorkommen kann).
Man wählt eigentlich immer json, wenn man ein einfaches und von Menschen lesbares Format haben möchte, das auch nicht an unterschiedliche Java Versionen gekoppelt ist (reines XML ist das auch nicht, aber bei der Verwendung der Bordmittel schon).
Eigentlich kannst du die Logik fürs Laden und Speichern und der Differenzenrechnung direkt meinem posting entnehmen. Aber Eigenlob soll ja bekanntlich stinken, also mach was du für richtig hältst. :D
 
T

temi

Das ist weiterhin ein beliebtes Format, um Daten aus einem Programm zu exportieren und in ein anderes zu importieren.

Außerdem solltest du berücksichtigen, dass es darum geht etwas zu Lernen, da kann man gerne einfach anfangen und sich steigern. Lernen heißt ja auch verschiedene Dinge auszuprobieren. Am Ende kann er sich ja dann an den BlockChainDataWriter setzen ;)
 
W

White_Fox

CSV ist obsolet. Schon seit zig Jahrzehnten.
Es mag zig Jahrzehnte alt sein...na und? JPEG und PNG sind eigentlich auch obsolet (vor allem da es mittlerweile um Längen besser komprimierende Formate gibt).

CSV ist aber für diesen Anwendungsfall zweckmäßig. Und das ist es doch, was zählt. Oder?
 
mrBrown

mrBrown

Es braucht nur mal ein Semikolon codiert werden müssen (was ja durchaus bei Medikamentennamen vorkommen kann).
Ist doch absolut kein Problem mit CSV.

Man wählt eigentlich immer json, wenn man ein einfaches und von Menschen lesbares Format haben möchte, das auch nicht an unterschiedliche Java Versionen gekoppelt ist (reines XML ist das auch nicht, aber bei der Verwendung der Bordmittel schon).
Schwurbel schwurbel...
 
J

JustNobody

Ist schon hart: bezüglich csv muss ich Tobias etwas Recht geben. CSV ist in meinen Augen auch keine tauglich Lösung und Gründe wurden etwas genannt. CSV habe ich schon öfters nutzen müssen und es hat sich zu oft als Krücke herausgestellt.

Dann lieber ein eigenes Textformat entwerfen so man keine externe Library verwenden möchte. (Da kann man sich was taugliches Überlegen, das keine Probleme macht.)

Ansonsten mit Library wäre XML oder Json gut. Man kann aber auch Excel nehmen so man die Daten auch mit Excel verarbeiten können möchte...

Optionen sehe ich viele und die wurden gut ausgeführt. CSV geht natürlich auch, so man sich bewusst ist wo die Grenzen sind. Aber daran würde ich nicht herum basteln sondern es hinnehmen. (Also festes Trennzeichen unabhängig von der Regionalisierung, Limitierung der Zeichen, die verwendet werden dürfen und was sonst noch so auftauchen könnte ....)

Aber egal wie Du Dich entscheidesr: leg einfach los. Du wirst auf jeden Fall dazu lernen und das ist der Hauptzweck.
Daher wäre meine Empfehlung, dass du einfach mehrere Optionen implementierst.... als Übung also auch sehr tauglich :)
 
W

White_Fox

Man wählt eigentlich immer json, wenn
Ja, ist das denn dann noch eine Wahl? Hm...

Ich schreib es im Mikrocontrollerforum oft genug:: Für gute Entwickler/Ingenieure gibt es keine Regeln oder Immer-wenn-Lösungen. Für gute Entwickler/Ingenieure gibt es Anforderungen und Umstände, die den Anforderungen entgegenstehen oder günstig sind. Und daraus wird ein Kompromiss herausgearbeitet, der der Ideallösung im besten Fall möglichst nahekommt.
 
J

JustNobody

Und jetzt stell dir mal vor, in irgendeinem String steht ein " und das soll als JSON gespeichert werden :oops:
Ja, ich mag XML zusammen mit XSD ... und dann auch die Verarbeitung per XSLT ...

Wobei das einfach daran liegt, dass ich da mehr Erfahrungen mit sammeln durfte. Gerade mit Namespaces und Co kann es ohne Erfahrung sehr herausfordernd werden...
 
J

JustNobody

Und jetzt stell dir mal vor, in irgendeinem String steht ein " und das soll als JSON gespeichert werden :oops:
Was ich vergessen hatte:
Org.json oder Jackson oder eigentlich jede JSON Library dürfte sich da problemlos drum kümmern, dass Quotes ein Escape Zeichen bekommen und so.

Das sind dann auch Dinge, wo man vorhandene Libraries nutzen wird. Sonst wäre die Erwartungshaltung bezüglich Datenbank recht hoch :)
 
J

JustNobody

Das gleiche macht allerdings auch jede Lib für CSV
Du hast massive Probleme mit der Regionalisierung bei CSV. Das hast du bei JSON und XML eben nicht. Der Deutsche Client spricht den Webservice in den USA problemlos an.

Die Rumhampelei mit CSV Dateien ist extrem und alles andere als schön. Und ich kenne keine Library, die das wirklich anfängt. Wir haben da damals teilweise selbst was geschrieben, aber das sind Krückenlösungen. Ähnlich wie die Erkennung des Zeichensatzes bei einer Datei....sa ist ein Eintrag im Kopf der Datei recht gut ... und wo ich da schon etwas vom Thema weg bin: ist im JDK schon etwas enthalten, das mit UTF BOM umgehen kann? Oder ist das immer noch dem Entwickler selbst überlassen sowas zu erkennen und heraus zu filtern?
 
J

JustNobody

Ich sehe es nicht als streiten, nur kommen da halt Erinnerungen hoch... das ist wie bei der Makler Werbung mit dem Griff in den Kaktus :)

Generell kann man einiges bauen:
Erkennung der Trennzeichen: in den ersten zwei Zeilen die , und ; zählen. Das, was konstant ist / das was größer ist dürfte das Trennzeichen sein.
Strings sind immer in Quotes (wenn man das erzwingen kann, dann ist es gut). Dann sucht man bei einem " an Anfang des Wertes nach " + Trennzeichen und damit sind ein einzelnes Quote oder , bzw; kein Problem mehr. Aber klar: ", bzw "; sind dann immer noch problematisch.

Man kriegt gute Annäherungen hin und ich meine das MS Excel damit auch klar gekommen ist.

Wenn es nur um das Speichern/Laden geht, dann kann man überlegen, bestimmte Zeichen mit Escape Zeichen zu versehen .... Das ist aber etwas, das ich so noch nicht implementiert habe (das davor durfte ich schon mit c# schreiben
 
Thema: 

Fragen zur Datenspeicherung

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben