XML

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi
I am builing a data application with about 40 tables and am looking for a
simple way to validate all my data.
I am wondering if it makes sense to build one dataset that represents the
entire database, build a class that handles and validates all the insert and
update events and displays user messages on invalid data. I need to be able
to change data and then cancel the changes without writing them to the
database. I also like the way a dataset allows me to use .NET code to access
relational data.
I would like to hear from anyone that has experience on this matter.
thanks
 
Nooooooooooo .. !!! Don't create a dataset with 40 tables in it.

A dataset is like a mini-rdbms in memory, that can work completely
disconnected from the database - doesn't mean that the mini d/b has to
masquerade as a full d/b. You should read as much information as you can in
one shot - but that doesn't mean that in your house you should plan for an
elephant falling on you should the elephant get scared of the mice that
might show up because of the bread you are going to buy.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Data validation is not part of the stored procedures because... well to be
honest, I am new to this. There are no stored procedures. Should there be
any? I had envisioned a simple 'get the data into vb.NET, do all the work
there, and write it back into the database' kind of object model. How do I
notify the user of the type of error when using a stored procedure(null,
non-unique...)? Do I then create a dataset for each form?
 
Thad,

My apologies for not reading this sooner, I have been in back2back meetings
all day and night, and then commitments at home.

Allright, so why stored procs??

1. Security - injection attacks
2. Security - table structure need not be exposed
3. Better architecture - table structure is owned by dbas now.
4. Many other reasons.

The errors will be raised just as the errors could be raised thru SQL
statements - nothing funky EXCEPT, you can now raise better errors, and you
can have better logic inside your TSQL.

Stored Procedure Friend, Stored procedure good.

The right solution is a good mix of work done in D/B and front end. The idea
being -- Extract as much as you can in one go - reduce the # of hits to your
D/B, but when you do hit the d/b pass in enough information so you can get a
yay or nay in one go from the d/b. Oh yes, and try passing in data to the
stored procs as XML if you are using Sql 2k+. (Strange how many folks don't
do that though, but anyway).

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
Please reply to the newsgroups instead of email so everyone can benefit from
your reply.
 
Back
Top