Hey Adam, That's certainly not a bad model to work on, I know I've used similar methods myself in the past, the benefits not only being the auditing but you can implement features which allow users to rollback versions of records to old ones sort of like an 'undo' feature. The problem is with this at the moment is that coupling these kinds of complex save/ delete methods with Transfer is grinding away at my brain as a bit of a pain at the moment.
interesting concept though and anything which keeps table management down is cool in book :-D Thanks, Rob On Mar 10, 1:01 pm, Adam Tuttle <[email protected]> wrote: > I've worked on applications in the past that -- instead of using a separate > audit table -- made the row insertion timestamp part of the primary key, as > a composite key, with what you would normally use, be it a surrogate or > natural key. > > In this architecture, there's no such thing as an update, only an insert. > The only thing is it requires you to add a column to indicate deleted, if > you want to allow record deletion. Personally, I really like this method > because it means 1/2 as many tables as keeping audit data separate. An extra > column is a small price to pay for that, in my opinion. > > Adam > > On Tue, Mar 10, 2009 at 6:48 AM, Sir Rawlins < > > [email protected]> wrote: > > > Hello Guys, > > > This is a revival of an old thread: > > >http://groups.google.com/group/model-glue/browse_thread/thread/b950a8... > > > Ok so this is an old thread of mine which I'm going to pull back up > > again as its on my mind this morning after playing around with the > > Broadchoice application (very very sexy stuff guys) and it regenerated > > my interest in getting something like this working within our > > application here at Think Blue. > > > The implementation you've used in the Broadchoice app really looks > > very nice. At the moment there are two main challenges for me when > > trying to figure out how to build a similar audit trail into my > > application and I'd really be interested in your thoughts on it. > > > The first is figuring out a persistence method that can effectively > > store the trail, would you be willing to give a few suggestions as to > > how this is best formed? My current train of thought leads me into > > having an audit table per audited object within the application, are > > you guys handling it like this, having a table for each object (i.e. > > notes, files, tasks) or do you have a universal audit table for all > > activity in the app? or perhaps both with a subclass approach? > > > The second element which I've struggled with is dealing with trails > > for objects that have been deleted. For instance in my tasks list the > > user can click the object they've recently edited and it takes them > > back to that edit page however if the object is then deleted the links > > to that object in the tasks list need to become inactive. This is a > > challenge I see you've solved in Broadchoice, I'd be keen to here your > > suggestions on how its best achieved. > > > If you guys don't feel happy disclosing this stuff on an open list > > then feel free to contact me direct or over IM or suchlike. > > > Cheers all, > > > Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
