-1

I have not had to do anything like this yet so I just need a little help in what direction I should go. I have an application I am working on in java. It has quite a few variables that refer to price amounts based on amount purchased. One product has about forty values based on quantity. Also there is the option to select a user name. When the user name is selected the info is attached to the sheet of the name selected.

What I am wondering is what is the best way to handle data like this. I would like it in a separate sheet so that if a value is changed I can change it in the sheet and not in the code itself. Same goes for the user info. I would like to keep it separate as well. I am still new with a lot of this stuff. I don't want to use a database so I am wondering what the best method is.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
shinjuo
  • 20,498
  • 23
  • 73
  • 104
  • Question is very unclear. Is this a user interface design question? Or a program configuration management question? What kind of application is this (web? swing? android? command line?) – Thilo Apr 21 '13 at 07:03
  • 2
    Q: Why don't you want to use a database? All things being equal, a database sounds like it might be an *ideal* solution. – paulsm4 Apr 21 '13 at 07:04
  • 1
    If you are trying to manage a huge amount of data, you better go for a database. – Praneeth Peiris Apr 21 '13 at 07:04
  • I don't want to rely on then people using it having access to a database at all times. – shinjuo Apr 21 '13 at 07:04
  • 1
    Why not just use SQLite then? It's essentially a fully fledged Database that is all stored in one file. You don't have to worry about the user having a database or not, and connection with Java is quite easy. – Kezz Apr 21 '13 at 07:06
  • Can you pack SQLite in a runnable jar? I don't want to have the users download anything to use it – shinjuo Apr 21 '13 at 07:07
  • In the Java world I'd prefer HSQLD (or H2) over SQLite. Their SQL features are much better than SQLite's. And the database can be packaged into the jar - although that makes it' read-only unless you unpack it and store it somewhere outside the .jar file during startup. –  Apr 21 '13 at 07:07
  • The POINT of a database is that people access it all the time. If you have multiple users, you want to make sure they are LOOKING AT THE SAME PIECE OF INFORMATION. If that information can change, and it is in more than one place, you can pretty much guarantee it will get out of sync. – Floris Apr 21 '13 at 07:11
  • It won't stay in sync. They will rarely have connection to the internet or network when they are using it. – shinjuo Apr 21 '13 at 07:14
  • 1
    If your information doesn't update very often, and it isn't very large, then you could write it as a static array in a class of its own; that's its own file, and can be maintained relatively easily. It does mean that the information only updates when people get a new executable - but your "rarely connected to the internet" comment implies that is OK. You reference this class in your other code whenever you need a value from your table. I still don't understand what you want to do with the user names, and how that relates to "attaching to sheets". – Floris Apr 21 '13 at 07:16
  • It exports to a PDF the selected names info when you select that name from a list. It isn't like a log in system or anything, it is just info like phone, email, etc. This whole thing generates some info and exports it to a PDF – shinjuo Apr 21 '13 at 07:19

1 Answers1

4

A database by any other name is still a database, just not as efficient. You could keep your data in an excel spreadsheet, save it as a .csv file, and open the file in java and parse the information. In a separate file you could keep a list of the user names, appending a new name each time a new user registers.

But really - this ends up looking just like a database with two tables; except you're re-inventing a bunch of code.

If you do decide to go that route, look at Embedded java databases . The most up-voted recommendation there was to use Apache Derby.

Community
  • 1
  • 1
Floris
  • 45,857
  • 6
  • 70
  • 122
  • I May have a misconception on a database. I just need something that is easily changeable, the user doesn't have to connet using the internet or a network, and it can be packed with mg program so the user isn't forced to install something on every computer – shinjuo Apr 21 '13 at 07:10
  • I think an embedded database (did you follow my link) does all that. It adds about 2.6 MB to your file size (plus the database file that is part of the package). See http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html for an intro - maybe it is what you are looking for... – Floris Apr 21 '13 at 07:20
  • Yes that looks like it may work. I did not know there was such a thing – shinjuo Apr 21 '13 at 07:24