views:

181

answers:

3

I have a database with a report table. This table represents report data, and has constraints. Now the application is used by firemen, and they might have to run off and put out some fires. So in the middle of filling out data for this table, they might have to run off. What we do is when the session run out we save the data to a draft table, where we simply serialize the object graph, no constraints (since we can't know if everything is in a valid state). And when the fireman later wants to pull data back out we simply pull out the draft again.

This works fine! However the firemen now wants to be able to search the table and the draft table. So here I would like to maybe store all the data (including the draft) into one table, that I search, so I don't have to consolidate the search from two tables..

Is there some kind of database pattern for drafts? What I want is a patternfor storing data without constraints (in draft mode) and with constraints (in final mode).

+1  A: 

I dont know of a Database pattern for Drafts, but I would suggest keeping your seperate table if you require validation and simply searching on both tables.

Toby Allen
+3  A: 

I don't know if it this would qualify as a pattern, but I think that the cleanest way to go about this would be to create a view that does a union of the two tables and search against that.

Jeromy Irvine
this was also my first thought
Sem Dendoncker
+1  A: 

Go with the simple solution: create a View which is just a union of the two tables (which should be fairly straight forward as they I assume they both have (almost) identical structures) and then run searches on that as the source if they want to include both.

I wouldn't actually merge the complete and draft data at any point: the potential for error and accidental use of unvalidated data seems huge.

You wouldn't be working on an interface for the IRS in the UK at the moment, would you? If not, sounds like DK have gone for a similar (in principle) solution to this problem (I used to work for a UK Fire and Rescue Service).

mavnn
Not working on IRS no :-)Wouldn't we double our maintainance?I mean if we add a column to one table we would have to add it to the other table (and the view by the way)
khebbie
Yes, but you'll have to do that already, won't you? The union itself won't need to be amended as long as the two tables match exactly: just use "[Table1] UNION [Table2];" without specifying field names.
mavnn