[Javacavemaps-developers] xml, cvs, flat file, delimeted, and jdbc
Status: Pre-Alpha
Brought to you by:
caverdude
From: Larry G. <jav...@ya...> - 2008-12-24 23:51:45
|
First let me say, I do like XML and want to use it for the main type of storage until we get to the heave database work. I hope someone here is better at making DTD's than I am. I can help with some specifications for the xml files. About CVS, flat file (fixed width), and delimited(as in pipe). These are so common I feel we should keep some classes in the project for loading tabular data from them and write tabular data back to them. These are common types for exporting and importing especially from spread sheets. Cavers have learned how to use the spread sheet well for their purposes. I'm absoultely sure there is lots of data on cave surveys in spreadsheets around the world. This is trivial but Hypersonic SQL (hsqldb.sourceforge.net I think) now allows you to link a flat file, delimited file or cvs file as a database table. Later we may get into keeping database information on caves, i.e. location, type, cave life, cave formations, and much more. This will become database intensive and as there are many "Cave Surveys" around, they probably all use a Database of some kind. The Arkansas Cave Survey uses for example DBase. Since we will be coding JDBC the use of Hypersonic is not such a big deal. Its just that I like Hypersonic because its also written in Java. Now we have opened a can of worms. Someone mentioned Client Server coding which would be for the purpose of colaboration amongst cavers. This will be a last consideration after we have done everything else we can do with this project. The design of this software will be oriented towards individual use. I mean the applet calculator is not such a big deal but anything more that keeps track of data will be. There is much controversy amongst cavers reguarding the conservation of caves. It is generally felt in my home state and amongst given circles in other areas of the country that the best way to protect caves is to keep info about them totally secret and only amongst a close nit group of friends. Or give info out on a need to know basis only. Or simply limit the information released to anyone not in the click basically. You would think these groups were like crime families. Anyway, the goal is to prevent crime to and traffic in the caves. Broken formations are of the utmost concern. There is federal law protecting caves. But I have never seen a law enforcement officer at the entrance of one. Ebay was stopped early on from trading cave formations for example. So making a database for colaboration would be like making a fishing database so that everyone in the neighborhood could tell each other about the nicest fishing holes. The wouldnt colborate much if at all. Only certain close nit groups might. Having said that, before anything like this could be developed a ton of though must go into security considerations and features, as well as encryption JUnit will become necessary as this grows some more. Lets not get started on unit testing just yet. I know there are some programmers that believe in letting the test drive the coding. But I prefer to think of testing as the safety net as the project becomes more complex. Larry Gray |