I previously asked this question on stack overflow. But have not received any responses that might help me. So I thought I would try here.
https://stackoverflow.com/questions/24883527/best-way-for-me-to-approach-storing-single-boolean-results-for-overall-table
Essentially I am creating a Java application that reads and writes form a database. In the course of the design it creates new tables with new information as well as linking the information from those tables.
Anyway, the question is, the client has requested that the JTable that I use to display the Table names from the database now include 3 columns each with a checkbox.
What would the best action be for me to store the data from these checkboxes?
Some of the methods I have considered are
- Store the information within the table in new columns (this will involve changing the code for modifying and writing of these tables, which is possible)
- Create a new table and store the other table names and the values in columns within (have it on load check the current names against the meta data and add/remove where needed)
- Create a properties file and pull the information from that, where it matches the names from the MetaData (ie. TableName=yes,no)
The option that strikes me as the easiest/fastest to do/run would be to go with option 3, and make a properties file.
NOTE: Within the application I already have methods for reading and writing from a properties file, as well as to create a new table within the database, and to write/read from the rows of each table.
1
Your first option sounds like the most sane. You have a UI component that displays records from a table, and you now need to display boolean values associated with each record and you need to persist the values that the user sets. Saving these three new values with the record makes the most sense, logically, but I don’t know enough about your system to know for certain.
Your second option involves splitting these values out to a separate table. This might make sense if there was some sort of 1:n or n:1 relationship, or these columns were very sparsely populated in a huge number of records and you were concerned about using up too much storage for them. It doesn’t sound like any of these issues are relevant here, so you probably don’t need to go this route.
Your third option invovles splitting the data out of the table and saving it in a properties file. Why split the data into such different areas? It sounds like your reason to do this is fast development time. I’d recommend against doing this, unless your deadlines are really that tight.
My recommendation is to go with your fist option, but again, there’s not enough information about your system to know if that’s really the best bet.
1
Your description sounds like you have already coded a method of saving data. In my experience, the best thing to do when working on an existing application is to follow the same pattern throughout. My advice to you is to look at how similar data is being handled by the application. Follow the same pattern that is being used there when saving the check box data.
Advantages of following existing patterns
There are a lot of good reasons to follow existing patterns when adding functionality to an existing application. One of the most important advantages is that all the code follows the same rules. If there is a couple developers that understand how the application works, they will continue to understand how the application works after you make your change. Another advantage to this is developers can learn one pattern to understand how the application saves data.
Recommendation
I recommend taking a look at what is currently being done to save data of this type. Use that as a template when adding the functionality with check boxes. I’m sure there is a pattern already established for you to mimic. You just need to find out what it is. Unfortunately, I can’t give you anymore advice than that without further understanding the application structure.
I’d skip the properties file. Since you’re keeping data about database tables, it only makes sense to keep it in the database.
If the data in the “checkbox” columns is part of the data already in the tables, then go ahead and just add the columns for it. If it’s metadata that’s not related to the data in the table, then create a separate table for it. Denormalizing your database for UI purposes is a design smell. It’s hard to give any further advice with just the information given.