Re: temporal database generation

From: Eric Lazarus (ericllazaru..ahoo.com)
Date: Sat Aug 26 2006 - 13:04:34 EDT

  • Next message: Mike Kienenberger: "Re: temporal database generation"

    I guess I was thinking about it done in Tomi's way but if this way can ensure that no data is ever lost, that is pretty powerful.

    What are the advantages of doing it Tomi's way?

       He can do efficient queries to see what the state of the database was at any time in the past? Is that right?

       He could efficiently materialize objects as they existed at any time in the past.

    Anything else?

    The general idea that a "fact" can be "tagged" is a general and powerful concept that OR tools perhaps should support in some way. What might one want to "tag" a "fact" with? It isn't just "time" that it makes sense to tag things with.

       Why I believe it.
       Who expressed it.
       Who believes it / does not believe it.

       What process did we use to learn/discover the fact.
       What process did we use to MAKE it true.
       Level of certainty.

       Importance / relevance.

       Implications of the fact.

       When it came to be.
       When it stopped being true.
       Why it is true.

       From what "point of view" is it true (i.e., the prosecution vs. the defense in a legal battle)

    (I guess this is somewhat related to the ideas of higher order logic, where we quantify over predicates? Hmmm...)

    Objects are not as good as relations at looking at the world as a set of facts, are they?

    It would be so cool for objects to be able to support this and still retain the clean way we model other things so nicely using objects.

    I dont currently have lots of ideas about how one would make this generally practical within the context of OO programming.

    I did consult to a consumer goods company where the tree of geographical regains was represented in the relational database with start and end dates so that areas could come into existence, be re-classified into different sub regions. I guess it had to do with who managed what sales staff member at what period of time and who got what discounts.

    Sorry if this is an example of generalizing to the point of impracticality. I have no actual near-term requirement for this sort of thing.

    E
     

    Mike Kienenberger <mkienen..mail.com> wrote: The main difference is that Tomi needs to have automatic criteria
    applied to every query he makes. Ie, a "WHERE time between
    effectivestart and effectiveend" for every select, insert, and update.

    What I need, and what Eric sounds like he needs, is for an AUDIT_LOG
    record to be created for every insert, update, and delete. Actually
    one for every field changed in an insert or update.

    For example, here's what the fields of an audit record look like for
    me (xml definition).

        
    position="5" primaryKey="true" type="INTEGER" />
        
    nullable="true" position="11" primaryKey="false" size="32"
    type="VARCHAR" />
        
    nullable="true" position="13" primaryKey="false" size="32"
    type="VARCHAR" />
        
    nullable="true" position="1" primaryKey="false" size="32"
    type="VARCHAR" />
        
    nullable="true" position="7" primaryKey="false" size="1"
    type="VARCHAR" />
        
    nullable="true" position="9" primaryKey="false" size="2000"
    type="VARCHAR" />
        
    nullable="true" position="8" primaryKey="false" size="2000"
    type="VARCHAR" />
        
    nullable="true" position="4" primaryKey="false" type="INTEGER" />
        
    nullable="true" position="3" primaryKey="false" size="200"
    type="VARCHAR" />
        
    nullable="true" position="6" primaryKey="false" size="6"
    type="TIMESTAMP" />
        
    nullable="true" position="12" primaryKey="false" type="INTEGER" />
        
    nullable="true" position="2" primaryKey="false" type="INTEGER" />
        
    nullable="true" position="10" primaryKey="false" type="INTEGER" />

    ID is meaningless primary key
    SCHEMA_NAME.TBL_NAME.COL_NAME describes path to data changed.
    MOD_TYPE is insert, delete, or update (I,D,U)
    OLD_VALUE and NEW_VALUE are the state changes.
    FOREIGN_KEY and FKEY_CONDITION are references to the record that was
    changed (FK_C is for compound keys, FK is for a single integer key).
    MOD_TIME is when the record was changed.
    SYSTEM_ID/EFFECTIVE_USER_ID/REAL_USER_ID describes where the data was
    changed. (application and user).

    On 8/25/06, Eric Lazarus wrote:
    > Tomi
    >
    > Please help me/us to understand what you need and how it differs from what I am talking about (or what additional functionality you need.)
    >
    > Thanks
    >
    > Eric
    >
    > Tomi NA wrote: On 8/25/06, Mike Kienenberger wrote:
    > > Hey Eric,
    > >
    > > By the end of the month, I will have audit logging like you've
    > > described working. Probably Monday or Tuesday. If it involves code
    > > changes to Cayenne, it'll probably take at least another week to get
    > > them committed.
    >
    > I'm looking forward to seeing how it'll work. From the JIRA issue you
    > linked to, it didn't seem like the functionality I described, but if
    > you say it's what Eric described he needed, then it's (for the most
    > part) the functionality I need, as well.
    >
    >
    >
    > ---------------------------------
    > Do you Yahoo!?
    > Everyone is raving about the all-new Yahoo! Mail.
    >

     __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com



    This archive was generated by hypermail 2.0.0 : Sat Aug 26 2006 - 13:04:58 EDT