Re: Parsing Table columns?

Bryan Pendleton wrote:

> Are there any guideline articles or books that will help me in designing my tables?

Here's a good place to start:
http://www.google.com/search?q=data+normalization

Bryan,
I found the following link via the link you provided:
http://www.agiledata.org/essays/dataNormalization.html

The above link gave me a nice understanding of the “#NF” Database normalization states.

I am sure that, as a minimum, I have a 1NF Database normalization design in that there is no redundant data.

My Derby usage is a little different than most. I currently have a HDD driven system where there is an Address Book HDD file and a HDD file for each form of my “Form Centric”  Java stand alone application. By design the form classes have system unique names and each field of a form has a unique name. The concatenations of the form ID and the field ID yield a unique ID for any field of the Application. Kinda like a primary Database key.

The stand alone application produces a series for reports derived as a function of the form data fields. I need to produce the same reports from the stand alone application or from a web page. Therefore, the web implementation requires the Address Book and the form field values to exist via my server.

I am installing the Derby  Database to implement form field and Address Book parameters persistence and to make this data available in both the stand alone and web environments to my Report Generator.

Currently I envision 5 Database Table types:
        1) Address Book
  2) System Parameters
        3) Form Fields
        4) Form Info
        5) Form State

There shall be a Derby  Database Table for each data entry form [3) above]. Each form table shall consist of an ordered pair [key/value] where the key is the unique field ID and the value is the current value assigned to the associated field in Java String format.

Before I read your referenced link I had planned to let the “Form Fields” table contain ordered pairs for the forms two inner classes [info | state] that would have been stored in the form table value column in the inner class ‘toString’ format.

Now I think a table for each with a row for each form is more efficient. The form ID shall be the key and inner class specific columns will be designed.

I do not know how to evaluate this design for the 2NF or 3NF normalization formats but I think the above table layout does the job for me.

Various columns of the Form State table [5) above] will be updated each time the application end user moves to a new form field. It is this table that I was primarily concerned about when I started this thread. I think I’ll implement each row as a series of state field columns and see if any additional tweaking is required later.

Another unmentioned requirement for my Derby  Database implementation is the need to be able to recreate the HDD files if they are unavailable for some reason. I think I am OK there and the Database table design is not important for this recovery processing.

Thanks for your help,
Jim...