Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Decoupling the Database


Decoupling the Database

Author
Message
MladenPrajdic
MladenPrajdic
Grasshopper
Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)

Group: General Forum Members
Points: 15 Visits: 383
Comments posted to this topic are about the item Decoupling the Database

_______________________________________________

Causing trouble since 1980

blog: http://weblogs.sqlteam.com/mladenp

SSMS Add-in that does a few things: www.ssmstoolspack.com
Cade Roux
Cade Roux
SSC-Enthusiastic
SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)

Group: General Forum Members
Points: 130 Visits: 491
Thank you.

I'm so tired of explaining that the database has to have a well-defined perimeter of services which it exposes.

It's not so much that the ORM code generation is horrible, but that it effectively negates security, abstraction and basically all possibility of the database being able to control the access modes effectively through SPs and views.

And the rise of NoSQL isn't helping, either.
kenny-892481
kenny-892481
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 41
I have to respectfully disagree – if the goal is to make refactoring (of anything, not just database tables) easier, then it's important that the most well-connected elements in your 'dependency tree' be stable (i.e. 'abstract'). An additional 'abstraction layer' doesn't necessarily imply that the difficulty or duration of refactoring database table designs is any less. A "native SQL Server abstraction layer" could require more work to be done because of refactored database tables than an appropriately DRY set of application components. Why are you assuming that SQL Server views or stored procedures are inherently easier to change than other application code items?
The more generally applicable goal should be to minimize 'redundant' references in all of your code (and I include database table designs as 'code'), all else being equal.
I suspect, as this is a very database-oriented site, that you're implicitly assuming that their are separate sets of responsibility for the application database and its other components. In which case it very well be more productive to maintain an explicit interface between the database and the other components – but that doesn't mean that refactoring is necessarily any easier than if such an interface is not maintained.
Cade Roux
Cade Roux
SSC-Enthusiastic
SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)

Group: General Forum Members
Points: 130 Visits: 491
kenny-892481 (11/22/2010)but that doesn't mean that refactoring is necessarily any easier than if such an interface is not maintained.


Assuming that ease of validation and acceptance and confidence in quality = "easier" and more difficult validation and acceptance and lower confidence in quality after refactoring = "harder". Also ease of determining the scope of effects of a proposed change = "easier", then having an explicit interface does mean refactoring is "easier". Refactoring cannot cross an interface boundary without breaking tests, so by definition, you have contained problems to that boundary. If you have no containment boundary, or the boundary of containment has a greater surface area, then it is "harder".
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search