<?xml version="1.0" encoding="UTF-8"?>











<rss version="2.0" xmlns:jf="http://www.jivesoftware.com/xmlns/jiveforums/rss">



<channel>
    <title>Support Forums: Message List - Patterns for versioning database entities?</title>
    <link>http://www.theserverside.com</link>
    <description>Most recent forum messages</description>
    <language>en</language>
    
        <generator>Jive Forums Silver 5.5.30 (www.jivesoftware.com)</generator>
    
    <pubDate>Sat, 18 May 2013 02:22:16 -0400</pubDate>


    <item>

        <title>more comments</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28601</link>

        

        
            <description><![CDATA[In terms of scalability I have not used JDO (the KODO implementation for<br>more than a few thousand rows. However, this would really depend on the JDO<br>vendor.<br><br>In terms of your point 1) I do not think this is viable under a relatrional model....]]></description>
        

        <pubDate>Sat, 11 Sep 2004 21:12:29 -0400</pubDate>

        

        <jf:creationDate>Sat, 11 Sep 2004 21:12:29 -0400</jf:creationDate>
        <jf:modificationDate>Sat, 11 Sep 2004 21:12:29 -0400</jf:modificationDate>
        <jf:date>Sep 11, 2004</jf:date>
        <jf:author>bruce goldstein</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>some thoughts</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28601</link>

        

        
            <description><![CDATA[Interesting, bruce. How scalable have you found JDO to be, BTW?<br><br>In terms of links, I have used two solutions:<br><br>1. reference &lt;any&gt; version of an entity<br><br>2. reference a specific version of an entity.<br><br>With (1) your links...]]></description>
        

        <pubDate>Fri, 10 Sep 2004 08:52:09 -0400</pubDate>

        

        <jf:creationDate>Fri, 10 Sep 2004 08:52:09 -0400</jf:creationDate>
        <jf:modificationDate>Fri, 10 Sep 2004 08:52:09 -0400</jf:modificationDate>
        <jf:date>Sep 10, 2004</jf:date>
        <jf:author>Chris Nappin</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>


    <item>

        <title>some thoughts</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28601</link>

        

        
            <description><![CDATA[I do something very similar. I use JDO for persistence for use the following<br>patterns:<br><br>1. Every table has a version number and a parent id (which is similir to your solution).<br>2. A use a mini-rules engine to allow for &quot;callbacks&quot;...]]></description>
        

        <pubDate>Thu, 09 Sep 2004 18:00:39 -0400</pubDate>

        

        <jf:creationDate>Thu, 09 Sep 2004 18:00:39 -0400</jf:creationDate>
        <jf:modificationDate>Thu, 09 Sep 2004 18:00:39 -0400</jf:modificationDate>
        <jf:date>Sep 9, 2004</jf:date>
        <jf:author>bruce goldstein</jf:author>
        <jf:replyCount>2</jf:replyCount>
    </item>


    <item>

        <title>Patterns for versioning database entities?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28601</link>

        

        
            <description><![CDATA[I have worked on several applications that required full versioning of all database entities, not just to meet audit log requirements but so that older versions of entities can be  viewed at any point. Often this is required for a document-based workflow...]]></description>
        

        <pubDate>Thu, 09 Sep 2004 08:08:57 -0400</pubDate>

        

        <jf:creationDate>Thu, 09 Sep 2004 08:08:57 -0400</jf:creationDate>
        <jf:modificationDate>Thu, 09 Sep 2004 08:08:57 -0400</jf:modificationDate>
        <jf:date>Sep 9, 2004</jf:date>
        <jf:author>Chris Nappin</jf:author>
        <jf:replyCount>3</jf:replyCount>
    </item>



</channel>
</rss>

