On 17 Jul 2014, at 8:43pm, Tristan Van Berkom <tris...@upstairslabs.com> wrote:
> The objective is to keep a revisioned history of 'E' whenever 'E' has > changed, or any of it's 'P' counterparts have changed, ideally without > storing a duplicate row for the one 'E' and every one of its 'P's every > time anything changes. I assume that an event is created knowing what participants it has, and that these participants never change over the lifetime of the events. Most of your design criteria depend on knowing these two things: (A) Are you making few changes and doing lots of SELECTing, or making lots and lots of changes and only occasionally needing to look things up ? (B) When you do SELECTing, do you mostly need to know about the data as it is right now, or are most SELECTs about previous versions and not the current version ? Once you know those two things you can decide whether most of the work should be done when a change occurs, or whether you should make noting a change as easy as possibly, and do all the hard work when you need to look things up. You will also know whether you need just a copy of each row with the change-timestamp, or whether it's useful to keep another copy with just 'data as it is now' in it for fast reference when you need current data. > SELECT * FROM 'E(h)' Just a warning that you can't use single quotes as identifiers in SQLite. Nor can you have the name of a table as a variable. Apart from that, you seem to have figured out all the usable strategies, you just need to know how the data will be used to pick between them. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
