Decoupling the Database

Question

Post reply

Decoupling the Database

MladenPrajdic

Old Hand

Points: 395
More actions
November 20, 2010 at 1:15 pm

#149409

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

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

Cade Roux Ten Centuries Points: 1326 More actions · Answer 1

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 SSC Journeyman Points: 91 More actions · Answer 2

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 Ten Centuries Points: 1326 More actions · Answer 3

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".