I am working in asp.net MVC 3 Website and I need to keep track of any changes made to a table/entity. Whenever on Edit view something is modified, a list of changes will display with date, changes made columns below that Edit view. Do I need to create another table with entityHistory Name or I need to insert another record in same table for that ?
Please suggest
Depends what you want to do with the history data. If you want to show the record or object graph snapshots I have found creating a History table, with the same columns as the current table, easier to work with in building up how the complete record looked after or before a certain change. This also means that you'll have duplicated tables and data.
If your needs is a pure audit requirement it is easier to have one/two tables that holds data for entity, property, old value and new value columns.
Besides Audit options, SQL Server has now CDC (Change Data Capture in SQL2008) feature which enables developers to trace data changes on a sql table
You can build a similar logging mechanism by using triggers (refer to http://www.kodyaz.com/articles/sql-trigger-sql-server-trigger-example-to-log-changes-history.aspx for a sample)
You can also check the following article for an enhanced solution for logging data changes similar to CDC in SQL2005 http://www.kodyaz.com/articles/log-data-changes-using-change-data-capture-for-sql-server-2005.aspx
Related
I'm making a table with React, where the user can add new entries, and I'm deciding what to use as a key. I'm considering these options:
Use database id. But this will force me to talk with the server every time the user wants to add a new entry, which is not ideal.
Generate a front-end id for each row and persist it in the state
Option 2 clearly seems better, but I see the React docs recommend using database id.
I've dealt with this same dilemma many times over different projects, and I've never figured out the best solution, so I decided to get it answered once and for all.
It sounds like you might want to go with Option 2 for any data that hasn't been saved yet to the DB.
Recommendation is correct to use the DB id when available, but seeing as how your requirements allow for temporary or "draft" entries then I see no problem with Option 2. Just be wary of how you generate these temp ID's as you'll want to prevent clashes with existing ID's in the array.
I am new to OR-mapping techniques. I wonder if I'm using SORM to persist data to DB, how do I handle future database schema changes?
For example,
here is the User class :
case class User(name:String, age:Int)
what if in the future I want to add one more field like gender
do I need to manually change existing tables, or does the SORM helps me do this
what's the default value for the new field
what if I want to add a non-null field?
Or it is not easy to change data schema using SORM? That seems very restricted. What's the best method to handle database schema change?
Implement a migration. Have your original model and the updated one connect to associated DBs and use them to migrate all the data from the original model to the new one. You can drop the original database afterwards.
You can implement it either as a script or some form of a migration strategy-resolving function. E.g., you could have a table bearing the current schema version information, which you could use to determine how to migrate the database to the current version.
It, of course, won't be quite as fast as manual SQL alteration, but then it's the compromise of all ORMs.
I am trying to design my database and I want to have the ability to keep a track of history of changes.
I will have a table that will have all the nutritional facts of an food. When a user makes changes to the item(say changes calories from 100 to 200). I want to make that as a new revision.
That way a person who comes along can see that it was original 100 calories and then was updated to 200 calories. I guess this would be alot like how stack does it now where you can see what has been edited.
I am wondering what is the best way to do this? I am using sql server and nhibernate.
I was thinking of have another column or something that would be revision number. Then every-time a revision is made the number is incremented. Is this a good way?
NHibernate.Envers helps you with that.
You could just do as you've written, add another revision number.
Another approach would be adding a timestamp and use that as history. Every time an item is updated you add a row with the current values and the current timestamp.
I'd normally use some form of audit table(s) to handle this. What we do where I currently work is have all our audit tables under an audit schema, and we have an audit table for every that we wish to track revisions for. We don't use NHibernate, so we simply utilise triggers to ensure that every update to a given row is recorded in the audit table along with a timestamp and user id so you can get some context and order to the way in which the revisions were made.
It seems like it is difficult using triggers with NHibernate, but you could use something like NHibernate interceptors or events as mentioned in this post. I'd say triggers would be preferable to relying on your code, but if this is the only way to go with NHibernate, then maybe it is worth a look.
Lastly, I've seen it mentioned that you can use SQL Servers native audit or trace capabilities. I've never used this myself, but do remember some post on SO suggesting that this replaced the need for creating your own manual audit tables and associated triggers. It seems to do what you want as illustrated by this quote from the link above;
The auditing of activity of users, roles, or groups on database
objects can be restricted down to the table level. That is, you can
target SQL Server Audit to track specific activities of a user or
users down to the individual table level. For example, SQL Server
Audit allows a record to be made of all the UPDATEs to the Payroll
table by DBO.
To me that sounds more like a true audit rather than just a revision history, but maybe someone with more experience in this area could comment on its feasibility to be used for revision tracking. Of course, you'd have to see what effect it had on NHibernate also.
I am developing a system with Java EE and JPA where users can make changes to entities. It is needed to trace back to the changes when needed. So the all the changes and the user have to be recorded for each occasion when en update is made. What is the best way to record the changes.
For example, there is an Entity called Investigation. It has attributes like Name, Category, Price, Volume, etc. A user can search a single investigation and change the name in one instance and in another instance, another user can change the price. All these occasions with the change done and the user who did it is needed to be traced back when needed.
One method described in this link is that to label objects as old edited and create a new object with updated values, but the problem there are several other objects from different entities referring to the old one.
Another method as described in this link is to use a versioning field in a new table. Than can be achieved in JPA by creating a new entity that extends the main entity.
Out of these methods what is the best practice? Is there any other optimized way to keep the record editing history in Java Persistence?
EclipseLink supports history.
See,
http://wiki.eclipse.org/EclipseLink/Examples/JPA/History
If you don't mind using Hibernate, Envers might be interesting for you. It performs auditing automatically, optionally appending metadata like current user.
For each audited entity it creates a history table that holds previous versions.
Hi i am developing an App in WPF who will have paginated records (i am doing the pagination myself depending on the filters or in the number of records per page the user wants to be shown).
So i have never worked serious with DataGrids and what i am asking is, what is the best approach and better politic when we work with a DataGrid to update the Table in the DB?
We detect the row who have been changed, or we update the whole Table in the DB, what is the better way?
Because the user can change one row, and then other, and imagine the user changes 50 rows, the App will have to connect 50 Times with the DB?
Unit of work is probably the most common infrastructure solution to this problem, basically it stores the changes applied to the data and when ready executes them in a transaction to the database. There are many ORM mappers like Entity Framework or nHibernate that already do this for you, so id start there.
EDIT
See this example implementation as it sounds like from your comments yould need to write your own version, but basically you build a list of inserts, updates, deletes that should happen and execute them all in a trasaction, first inserts, then updates, then deletes but Id recommend you look at an ORM like the ones i described above they already have this as a feature.