I like doing both. But the difference (to me) is that in one case, your application is preventing itself from inserting bad data. In the other case, the database is preventing ANY application from inserting bad data.
I can't tell you how many times I've had to fix data because someone hand-tweaked data in Enterprise Manager (or Access or Foxpro) directly without going through an app. On 7/27/05, Marlon Moyer <[EMAIL PROTECTED]> wrote: > I've just recently noticed that one of our databases in sqlserver has > no relationships defined. I talked with the 'dba' about this and he > told me that all of that logic is contained in the VB app that updates > the data. I'm not saying that there aren't any foreign keys defined, > just that he's not specified that relationship inside of the db. So I > talked with my supervisor and he wanted some examples of why we should > move the logic out of VB and into the database. > > Aside from the obvious reason of keeping the db logic inside of the db > and built in referential integrity, I was stumped. I thought given > the relationships, sqlserver gets hints as to how to speed up joins > and such. I've already suggested that different programs that use the > data wouldn't have to recreate the integrity logic, but I need > more.........or maybe I don't. Maybe it's fine to keep this in VB? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Purchase Homesite Plus with Dreamweaver from House of Fusion, a Macromedia Authorized Affiliate and support the CF community. http://www.houseoffusion.com/banners/view.cfm?bannerid=55 Message: http://www.houseoffusion.com/lists.cfm/link=i:5:166792 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/5 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:5 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.5 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
