Don't try to find simple solution. It's business requirement clearly. So
approach it in business way. What data you need to keep in history? What are
changes you want to display, to whom, when, what for? UI doesn't matter much
here. Much more important is database design.
Person is id. Id has attributes. Some are changeable some not. Who will
enter the changes? How valid will be input? Do you have some forms, like
paper ones, which can help you to define which fields and events you have to
track? And what is "track" in your case? Another record or set of records?
One simple recommendation is - keep active data separate from historical
ones. You can have hierarchy of history tables or one table. The rest is
standard - and RDBMS dependent. Of course I am assuming you will use
relational DB for data storage.
Good luck!
HTH
Alex
"fred tate via .NET 247" <an*******@dotnet247.com> wrote in message
news:uG**************@TK2MSFTNGP09.phx.gbl...
I'm working on a project that will track a great deal of data for
individuals and will keep track of users for a very long time (5 - 10)
years. I'm looking for options as far as tracking and displaying changes to
the data. Any suggestions for both the UI and the Data Storage aspects of
tracking long term changes to data would be helpful.
Fred Tate
--------------------------------
From: fred tate
-----------------------
Posted by a user from .NET 247 (
http://www.dotnet247.com/)
<Id>PQuAkU7D3kumXqTDcXHsUQ==</Id>
