Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Decoupling the Database Expand / Collapse
Author
Message
Posted Saturday, November 20, 2010 1:15 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, August 24, 2014 5:41 PM
Points: 13, Visits: 358
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
Post #1023964
Posted Saturday, November 20, 2010 5:40 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, September 4, 2014 8:26 AM
Points: 109, Visits: 490
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.
Post #1023982
Posted Monday, November 22, 2010 7:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, December 5, 2011 8:59 AM
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.
Post #1024339
Posted Monday, November 22, 2010 8:05 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, September 4, 2014 8:26 AM
Points: 109, Visits: 490
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".
Post #1024364
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse