Re: [Javacavemaps-developers] Data models?

[Larry G. <jav...@ya...>]

By datamodel I usually mean a class that wraps up the data.  I guess you meant the xml format? The specs explain what data is to be manipulated.

 Larry Gray
la...@ar...




________________________________
From: David Days <da...@is...>
To: jav...@li...
Sent: Wednesday, December 24, 2008 12:19:32 PM
Subject: [Javacavemaps-developers] Data models?

Hey, all,

I guess I'll start with a question about the stored data model.  Is 
there a plan for the format that the data will be stored in?

--XML is one possibility.  The file format would be human-readable and 
editable (if necessary).  It would also allow the format to be used in 
other applications:  web pages, javascripts, and other mapping software 
would be able to use this format easily.  It would also make the 
application web portable; storage to and retrieval from a server would 
be fairly simple.  It could also be easily changed--just add new data 
tags if there another datapoint to be stored.
    On the other hand, at lot of up-front work would have to be done to 
figure out the exact tagging and model.  The application would have to 
have a subsystem that handles the IO correctly, and would either 
gracefully fail or ignore XML tags that it doesn't understand (in the 
case of newer versions of the XML being posted.)

--Straight database is another possibility.  Data modeling is pretty 
standard, and the data could be interchanged with other flat-file 
formats.  But the user would have to have a live connection to the 
database to work the application.  One could aways use an internal 
"local" database, such as HSQLDB. 
    That would solve live connection problem, but brings up issues with 
exchanging data with another system--you'd have to come up with a data 
interchange format (even if it is a simple SQL export) that would be 
understood by all.  That would make database changes or upgrades 
difficult--the new database SQL (whatever it may be) might not be 
backwards compatible.

--Straightforward serialized object export.  This is the simplest--tell 
the app to save the serialized CaveModel or StationModel (or whatever 
higher level) into a file.  On the other hand, it would require local 
permissions for a web-enabled application (reading and writing files) 
and, in my experience, leads to dead-end errors if there is a file 
corruption--the data is saved in an unknown format, the program can't 
read it, and all you get is some kind of "unable to load" error.  You 
never know if the file is corrupted, the connection has a problem, or if 
your application is failing.

    My suggestion is to use the XML type as a basis, then write 
"connectors" or SPI (service provider interface)-type backends.  The 
application expects the data as an XML-formatted file.  If it needs to 
connect with a central repository, the repository can _be_ a database, 
but writes out its data in XML format.  This way, you can have an online 
server store the data in a database (with extraneous data like pictures, 
notes, history, etc); this makes publicizing the findings easy with a 
straightforward webapp.  But actual data is interchanged in a known format.
    Again, the workload is up front; the writeObject() and readObject() 
methods have to be written to both format the XML and "fail" (or skip) 
gracefully if it encounters something weird.  But the payoff is a more 
portable application that doesn't cause follow-on developers to have a 
migraine translating data back and forth.

Just my thoughts.
David Days
happyslayer

------------------------------------------------------------------------------
_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers