Re: [Treebase-devel] Utility columns in database tables?

[Hilmar L. <hl...@du...>]

I agree you want to store that in the database but I'm not sure why in  
order to do that you have to clutter the data model with properties  
(columns) that are solely needed for data migration rather than for  
genuinely representing the data.

Can you not create a separate (and possibly temporary) table that  
records the entity name, the primary key, and whatever mark you want  
to place on the record identified by the key and the entity name?

Something along those lines would probably be what I would try. I  
think it's useful to adopt the same separation of concerns that are  
commonly accepted for managing versus using a computer system. Pretend  
you can't modify the data model and that only a DBA has the privilege  
to do so, and the DBA's knee-jerk reaction to everything that  
introduces change, subsequent maintenance, idiosyncrasy, and risk, is  
'no'. Would that mean that then you can't do what you want to do?  
Probably not, you would just do in a non-invasive way. Which, I would  
argue, is in most cases the better way.

	-hilmar

On Apr 22, 2009, at 4:57 PM, Mark Dominus wrote:

> During the development of TB2 there have been several times when I
> wished that each database table had an extra scratch column.
>
> While checking and correcting the migration from TB1, I often found
> myself maintaining and merging lists of object ID numbers.  For  
> example,
>   I might have a list of objects which needed to be checked, another
> list of objects which were found to be erroneous, and so on.  Rather
> than maintaining a bunch of text files with object ID numbers, it  
> would
> have been much more convenient to be able to store this information in
> the database itself.
>
> Or another example: I have written a garbage-collection utility that
> identifies and removes inaccessible objects from the database.  The
> easiest way to do this is with a mark-and-sweep algorithm: first mark
> all the known reachable objects, then all the objects reachable from
> those, and so on; then make a second pass and delete all the unmarked
> objects.  But to implement this requires storing the mark  
> somewhere.  At
> present, the utility program keeps an external record of which objects
> have been marked.  Storing the marks in the database would be much  
> simpler.
>
> It would require a small change to the code to add an additional field
> to every persistent object table to enable this sort of use.  The
> obvious time to do it would be at the time the tables are created at
> NESCent.
>
> The obvious drawback is that it takes up storage.  (There are 3e08
> matrix element objects.)
>
> Is this a bad idea for some non-obvious reason?
>
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu :
===========================================================