Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
steelkilt
Constraint Violating Yak Guru
255 Posts |
 Posted - 2002-09-19 : 13:32:23
|
| As I've noted before, several tables in my inherited database are structurally unsound. Full redesign is not an option (politics). What do you all think of an approach that uses VIEWS to dynamically "fix" such tables? For example, if demographic data is scattered unnecessarily in several tables, I create a VIEW to pull this data together. My users access the VIEW via ASP web interface and all their Update/add/delete operations are run against the VIEW, which, in turn updates the base tables.Hidden dangers?thx |
|
|
ValterBorges
Master Smack Fu Yak Hacker
1429 Posts |
Posted - 2002-09-19 : 13:58:39
|
| If you can you might want to go with Stored Procedures.There are less limitations on what you can do. |
 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-09-19 : 14:18:27
|
I agree with ValterBorges. Depending on how the tables are structured the views might help with queries but not be updateable/deleteable/insertable. In any case it would be better to work out everything in stored procedures because it will force you to examine the entire database and how it functions as a unit. You can still add views for the purposes of SELECTing, but at the same time you can do that with SPs and increase security. It will also make everything more consistent.BTW, I don't want to make your job harder, but the easy way to do things is seldom the best way to do it. If you are forced to go views-only for political reasons, and you have reservations about it, make sure your reservations are noted. Just in case in the future some dipshit end-user clobbers a view with a broad UPDATE or DELETE statement. If a stored procedure approach would've avoided that, you'll be on record for pointing out the issue(s) in advance.  |
|
|
|
|
|
|
using VIEWS to dynamically "fix" bad tables