what to use to save data?
Hi,
I am writing a programm, where I have to save for each day of the year about thirty data-fields x 3 (time, text, number). It has to be an easy portable prog, where you could just copy it to the HD and start it right on.
Now my question is, what is the best way to store the data, as it has to be portable too. I was thinking about some ****sql, but the trouble with these data-bases is, that some of them are not that easy to install, which might produce troubles with some users. ;-)
My other shot was on excel (as the prog is for windows). I could just copy the excel-file in order to have it on another pc. The other thing is, that the user can have also a quick look on the excel-file, if he wants to. So you probably get the idea.
But I just wanted to ask, if there is something else, as easy as excel - with it's features - or better, I could use.
Thanks
[902 byte] By [
pir2004a] at [2007-10-2 8:37:03]
You could try .csv files
Nice and portable, so users can open them (make graphs, print
memoranda, corrupt the data etc) using their favourite software.
If you're careful even Microsoft's spreadsheet software is usable.
Libraries exist to take care of the i/o donkey work, too.
I would definitely consider storing the data in XML format, unless it's too big and the loading/saving times are actually problematic. But I don't expect it to be a problem for what you want to do.
There a great library for serializing/deserializing Java objects to/from XML, it's called X-Stream, I'd find you the URL but Google is actually down at this moment. It's so easy to use it shouldn't cost much time to try it and see if it's fast enough and the files are small enough.
Lokoa at 2007-7-16 22:38:42 >
The table I have make visible should look something like this:
Day 1 Day 2 Day 3
Time | Text | NumberTime | Text | NumberTime | Text | Number
Time | Text | NumberTime | Text | NumberTime | Text | Number
Time | Text | NumberTime | Text | NumberTime | Text | Number
Day 4 Day 5 Day 6
Time | Text | NumberTime | Text | NumberTime | Text | Number
Time | Text | NumberTime | Text | NumberTime | Text | Number
Time | Text | NumberTime | Text | NumberTime | Text | Number
....
You got the idea.
.cvs: As far as I know you just save data to any text-file, separating the information with semicolons. So in order to order the information this way, I would have to write a "filter" for example for excel too, wouldn't I? => writing code for saving data and writing code for exporting it to excel/or what ever.
XML: I have never worked with this language. Is it easy to learn? But I still would have the same "problem as with .cvs, wouldn't I?=> writing code for saving data and writing code for exporting it to excel/or what ever.
sorry for the format above
Day 1- Day 2 Day 3
Time | Text | Number-- Time | Text | Number-- Time | Text | Number
Time | Text | Number-- Time | Text | Number-- Time | Text | Number
Time | Text | Number-- Time | Text | Number-- Time | Text | Number
Day 4- Day 5 Day 6
Time | Text | Number-- Time | Text | Number-- Time | Text | Number
Time | Text | Number-- Time | Text | Number-- Time | Text | Number
Time | Text | Number-- Time | Text | Number-- Time | Text | Number
The "display" of the data should not dictate the format of how the data is actually stored. You should not concern yourself with storing the data in a human-readable form. Store it in XML or csv (actually if you're going to go the latter route I'd recommend tsv (tab- separated values) over csv (comma-), as data can easily have embedded commas in it, messing up the parsing of it).
Whatever you do, you don't want it to be stored in a human-readable way, because then your code that parses it becomes unnecessarily more complex, dealing with skipping over the human-readable markup (spaces, line feeds, etc).
The formatting of it for a human to see should be a separate concern of the application, or another application altogether.
>
> .cvs: As far as I know you just save data to any
> text-file, separating the information with
> semicolons. So in order to order the information this
> way, I would have to write a "filter" for example for
> excel too, wouldn't I? => writing code for saving
> data and writing code for exporting it to excel/or
> what ever.
>
> XML: I have never worked with this language. Is it
> easy to learn? But I still would have the same
> "problem as with .cvs, wouldn't I?=> writing code
> for saving data and writing code for exporting it to
> excel/or what ever.
Why would you need to go to "Excel or whatever"? What you want is a way to store Java objects in files, then later on you want to read the files and retrieve the objects, right? You can save your objects to XML and later on retrieve them using some library, for example the one I suggested. You wouldn't have to write any saving/loading code, you use a library that does this for you.
XML by the way is a format for storing data in 'human-readable' text files; it's quite easy in my opinion, but if you use a library you don't even have to care about what the files look like. XML itself is quite powerful and widely used for storing many kinds of data and passing it around between applications.
Lokoa at 2007-7-16 22:38:42 >
> XML by the way is a format for storing data in
> 'human-readable' text files;
No, I would not consider this to be true. Humans don't necessarily like to look at XML files -- applications do. Humans like to look at rendered data. Just hoping the OP doesn't confuse what you just said with what I said above about 'human-readable'. XML is not really in that category. It is an application-friendly form of data, which happens to be readable (in a way) by humans just because it is also text-ish.
> Whatever you do, you don't want it to be stored in a
> human-readable way, because then your code that
> parses it becomes unnecessarily more complex, dealing
> with skipping over the human-readable markup (spaces,
> line feeds, etc).
>
You shouldn't need to write any actual parsing code unless you are using your own encoding 'protocol'. And any XML parser (for example) can skip formatting characters like whitespaces. Using a library like X-Stream you don't even have to be concerned about formatting/parsing the actual XML data; you give it your objects and it returns XML and the other way around.
Lokoa at 2007-7-16 22:38:43 >
> > XML by the way is a format for storing data in
> > 'human-readable' text files;
> No, I would not consider this to be true. Humans
> don't necessarily like to look at XML files --
> applications do. Humans like to look at rendered
> data. Just hoping the OP doesn't confuse what you
> just said with what I said above about
> 'human-readable'. XML is not really in that category.
> It is an application-friendly form of data, which
> happens to be readable (in a way) by humans just
> because it is also text-ish.
Agreed it's not very human-friendly, but it is human-editable. I agree of course an end-user shouldn't have to look at it. But I would think most people with some technical background, let's say most people on this forum for example, would be able to understand the format and edit it.
Just clarifying what I meant by human-readable.
Lokoa at 2007-7-16 22:38:43 >
No one has commented on using a database to store your data. As
warnerja says the question of how you store the data is independent of
how you present it. I guess you would only go this route if you wanted
to be able to perform sql-ish queries on the data.
I took from your OP that you were writing an app that could edit and
browse the records, but wanted a data format that would enable users
to have access to the data using other software (you mentioned Excel)
as well as - or even instead of - your app. Using comma or tab
deliminated values would do this since these formats are understood
y most spreadsheet applications.
To write your data file you would take each record (which contains
dates, numbers, text etc) and turn it into a String. You separate each
entry in the record with a tab character. Things only get tricky if the entry
contains a tab character. Then you write the string to a text file ending it
with a new line.
Reading a data file is the same in reverse: read a line, split into pieces
at the tab characters, use the pieces to initialise a new record object.
You are free to edit or browse these records however you like, eg using
a JTable.
Be aware that giving the users the ability to interact with the data
outside your application could cause problems. The changes they
make might not be consistent with what your app expects.
xml does have the advantage that your records can have fields that
contain data of all sorts of types - including data with its own complex
structure. But you do lose the "inter application" flexibility.
1.)OK, so if the user shouldn't be able to edit the data, what would you use?
2.) Could you recommend a good XML (only) tutorial, as I wasn't too successful with google.
3.) Could you recommend a good. cvs tutorial.
4.)
>xml does have the advantage that your records can have fields that
>contain data of all sorts of types - including data with its own complex
>structure. But you do lose the "inter application" flexibility.
What does "inter application" flexibility mean?
>> xml does have the advantage that your records can have fields that
>> contain data of all sorts of types - including data with its own complex
>> structure. But you do lose the "inter application" flexibility.
>What does "inter application" flexibility mean?
I just meant the ability of other applications to read and manipulate your
data. This can be a good thing: a spreadsheet could add up the
numbers in "Day 5", or draw a pie chart for the totals of the 6 days.
Typical "Office" software allows such text and graphs to be embedded
in other documents. You don't have to reinvent the wheel and, even
better, the user is dealing with technology with which they are already
familiar.
> OK, so if the user shouldn't be able to edit the data,
It's very hard to stop the user ineracting with the data in destructive
ways - eg deleting the file! You could give the file a cryptic extension,
but other than that I really wouldn't worry about it. But I would be
defensive about reading the files and make no assumptions about
what they contained.
> what would you use?
File format: Based on what you describe in post 4 - tab separated
values.
Display format, ie within your app: Hard to say, but I'd guess JTables
would be involved. One if the Days contain a similar number of entries
and are fairly small. Six tables each in its own tabbed pane is more
flexible.
> Could you recommend a good XML (only) tutorial, as I wasn't too
successful with google.
No (just my ignorance), but hopefully others can. I'm picking that your
Google search was successful in indicating that there's quite a lot
of work here for the modest result of dumping your data into a file and
reading it back again.
> Could you recommend a good. cvs tutorial
(btw, comma separated values are "csv" not "cvs" - the latter will
confuse Google mightely).
http://en.wikipedia.org/wiki/Comma-separated_values describes them.
It also gives some links to reay made libraries (I have only ever used
the Ostermiller one). You may well find it more instructive to write your
own along the lines I suggested in post 10.
Make sure you are familiar with the language basics, File i/o and
JTable from the Tutorial, and you're ready to go!
