views:

83

answers:

4

Hi, I'm designing a new DataBase that at the moment has 50 Tables. For many of that tables I have to eventually store a "note" for every column of every tuple. For now I found only 2 solutions:

  1. For each column of tables that needs note add a "column note" so for example:

    create table tab (id integer, A varchar(100), B varchar(200))
    

    will become:

    create table tab (id integer, A varchar(100), A_note varchar(300), B varchar(200), B_note varchar(300))
    
  2. Add a table Note that store the notes... like that:

    create table notes (id integer, table_name varchar(100), reference_id integer, reference_column varchar(100), note varchar(300)
    

Do you can suggest me other ways? If you are interested I'm using HsqlDB.

+1  A: 

Yeah, separate tables are the way to go.

I would do a comment table like cmnt_table or notes_table for each actual table. Have it with the same id as the main table and it will be easy to do a join in queries.

JNK
+2  A: 

It depends a lot on how sparse your notes are, if they are scattered occasionally across all the tables then a good solution is to have one table containing notes that indexes them by the combination of table and field name.

This moves the addition of notes to the schema out to just one table that needs maintaining without having to touch the originals. You can use a constraint on the table and fieldname columns to restrict which ones can have notes.

I have implemented a variation on that very successfully to add typed tags to a large accounting system.

If a single table is distasteful, consider applying the pattern to clusters of tables.

One big advantage of the single Notes table is that you have one table to search if people are looking by note content. This can be very useful when people put notes in the wrong place.

Extension

I read the requirement as being one Note per Column.

In the case where an optional Note (or Tag) is to be stored occasionally for odd individual row values in columns (ie: the Excel model of attaching comments) then you extend my model above by adding a regular integer key for your rows. That is actually the model I first used. I simplified it for the answer but then realised maybe the requirements were misleading.

Andy Dent
Although I think is a great solution, as I have to use HSQLDB I would like to investicate about this solution: Add a columns NOTES defined as VARCHAR ARRAY with cardinality == column count. So I will access to Column Ordinal Position stored in database metadata to access column related note. What do you think?
Neo1975
There's a superficial appeal about using the array features of HSQLDB to providing one of the layers of indexing and I would have to spend quite a bit of time studying it to be sure it was safe or not (sorry, don't have that time, although it's intriguing).My immediate feeling is that it won't work - the *combination* of table and column name identifies the columns. I also think it is terrifyingly vulnerable to be using column ordinal numbers as an index - what happens if you drop a column? Yes, I know renaming a row also breaks the index but it is a lot easier to fix safely.
Andy Dent
+1  A: 

You should store the extra data in the same table. This is a one to one relationship and you gain no benefit from splitting them, only complexity.

DanDan
+1  A: 

You don't say what these notes are for. If each note describes the column in general, for example a column named EXPIRY_DATE has a note saying "The date when the ticket expires", there is a built in solution in HSQLDB 2.0.

COMMENT ON MYTABLE.EXPRIRY_DATE IS 'The date when the ticket expires'

And you can retrieve the note for a tablename, columnname pair using a SELECT on one of the INFORMATION_SCHEMA tables.

See the Guide:

http://hsqldb.org/doc/2.0/guide/databaseobjects-chapt.html#N10D75

fredt