Tag Info

Marking a record as deleted is known as soft-deleting. I've never heard an alternate phrase for updating, but I guess that's cause you soft-delete the old record and create a new one. It should be noted, this is a controversial technique. See links: Con vs Pro.

One of the problems with retaining a change history is that it clutters up the database and can dramatically increase its size (depending on usage patterns). So a good idea would be to store the audit trail in a separate place, and keep the actual application tables populated only with relevant data. So each time a CRUD operation is performed by the ...

EventSourcing sounds like the pattern that you may be looking for. Let's take an example using a simple "car" object that we would want to keep track of the color of (pseudo C# code follows). public class Car { public string Color { get; set; } public Car() { this.Color = "Blue"; } } With a CRUD implementation when we update the color of the car the ...

Event Sourcing is the way to go, and you should take a look at what Greg Young has to say about that. http://goodenoughsoftware.net/ Also take a look at this presentation on his Database (Event Store). You can find other videos as well. http://oredev.org/2012/sessions/a-deep-look-into-the-event-store I wouldn't go for the "soft-deletes" answer unless you ...

Not precisely your example, but in older financial systems you had WORM storage. If you needed to "update" you wrote a new record and you always referred to the last record as current but no committed data could ever be overwritten. A lot of folks carried that idea over into later systems. I have heard what you are describing referred to as WORM tables, ...

You can use "soft-deletes" as pdr suggested. As for updates, you could keep history of records, sort of like my answer here: http://dba.stackexchange.com/questions/28195/save-history-editable-data-rdbms/28201#28201 where the OP wanted to be able to keep track of all versions of certain kinds of data.

Interesting, Im developing a similar system for oil & gas, with Google Maps API v3. We chose to use CouchDB for the part of your diagram that includes GIS data, central repository, and other data sources. The idea behind this is one container to hold disparate sources of data with different types of structure, and also actual data files that represent ...

Maintaining an Audit table of denormalized DomainObject records with various user actions is the best bet. By flattening the object tree of DomainObject and storing all the data in an Audit table with user information and timestamps, then you have a complete history of all changes to DomainObject's regardless of Create, Update or Delete operations. By ...

There is a new requirement: keep track of the s that have been created since the app was opened, so that the user can see what he/she has done. I Don't fully understand you three ways But the correct way to do this is as follows. Every table in your system (The you want yo track) should have the following four fields on them: CreateDateTime ...

It seems that what you've described (i.e. Employee class having ALL possible code that you could do with an employee) is an extremely common pattern that I've personally seen quite a lot. Some of that code I've written myself before I knew any better. What starts off as a class that is supposed to represent a single entity with manageable set of methods, ...