views:

22

answers:

1

I am looking for a quick way of enabling data entry to a well structured SQL database.

We have defined all our data entry rules (by that I meean validation, mandatory fields etc.) and we're now looking for a tool to make it as easy as possible to have this database populated.

The database is largely product orientated, so the ability to add/edit products is important. Whenever a change to a field is made, it should be validated against the data rules to ensure it 'makes sense' before being written to the database. The ability for us to run reports on historical information is important, so the database must hang onto all of the products historical attirbutes too.

Eventually this data will be used for some standard reporting, and will be made available via a dashboard style reporting service that we will one day be able to afford! (hopefully)

Would Infopath be a good way of doing this? Are there any articles around the place that discuss a similar approach and how they were able to do it?

If not, what would users here suggest?

Background: I am from a business/product background and am trying to do some leg work myself to get a good outcome.

+1  A: 

Regarding Infopath - I think it will depend on the complexity of your rules.

Regardless, you will need your database design to be able to record history - have you already determined a database design which is able to meet your requirements for storing the historical attributes?

You should consider your business requirements for reporting and any point-in-time consistency and the architecture should follow. Like you said, you've got a proper IT guy, so if you've got your business rules all sorted out, they should be able to critically evaluate it and expose any things you haven't thought about. I've become a big fan of having a transactional operational database (perhaps retaining full history, but not providing rich access to it) with limited reporting capabilities and a reporting database with a model (like Kimball's dimensional data warehouse) conducive to point-in-time reporting etc.

Cade Roux
I've got a proper IT guy designing that. Any pointers for what I should look for in his design to confirm its on track?
anthon
@anthon - Have a look at this KB article: http://support.microsoft.com/kb/827007 You're going to need to ensure that when a user edits a product that the changes are logged. One way to do that is to use triggers to get an audit trail. Another is to require access through stored procedures which keep versions - there's lots of ways to skin that cat. If the database simply enforces it, it doesn't matter what client tool you use. If you rely on the client tool to log versions, then you potentially could miss changes which go around the tool.
Cade Roux
And how do you then report on those historical changes over say, a time series? Is this something that needs to be defined now or is that ok to add in time?
anthon
@anthon Adding to answer
Cade Roux