Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

Disconnected database development: solving a problem that needn't exist Expand / Collapse
Posted Saturday, March 17, 2012 10:06 AM

Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 3:10 PM
Points: 662, Visits: 2,926
Comments posted to this topic are about the item Disconnected database development: solving a problem that needn't exist

Best wishes,

Phil Factor
Simple Talk
Post #1268656
Posted Monday, March 19, 2012 2:09 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, September 7, 2016 12:35 AM
Points: 317, Visits: 1,145
Interesting editorial Phil factor.

I believe we have all seen this happen.

Where I work, we at least set up new users for each database and limits their possibilities. I find it hard to do much more than that, save for encrypting the passwords in the config files of course.

About several systems using the same database, while I am against this it can still be useful sometimes. Since I wanted to avoid this, in the latest application I was building from scratch this last year even reporting services talks with the application instead of the database directly. We have calculation logic in the application and do not want redundancy with all the issues that comes with it, so we did not duplicate the calculation logic in the database as well since it was not needed. Instead I let ssrs talk with some wcf services that I wrote. This I have to mention was somewhat annoying at first but it did work.
Post #1268829
Posted Monday, March 19, 2012 7:12 AM



Group: General Forum Members
Last Login: Tuesday, September 27, 2016 11:32 AM
Points: 24, Visits: 97
In the development environment in which I am working, We have three company's doing parallel development on web apps (modules) for one web site. While in many cases these modules implement a database comprised of data that only they use, there are several databases which provide shared data. These developers have no access to servers that can be shared with the developers from the other companies until the application is ready to be deployed on the government test server for beta testing. In addition, one of the companies has their developers working from home in another country so they don't even have access to a server that they can share the other developers in their company.

Having a defined application interface is a nice idea, but it would require centralized coordination, which here doesn't exist until the application is delivered. We have instructed that all data reads and updates are to be performed via stored procedures so to lessen the impact of the change in the data required by one application on the others sharing the data. However, there are problems when there is a need to add fields or change data types of the fields in the actual tables. We had that problem recently when the application that made primary usage of the table need to change the datatype of a field which then broke all of the reports that were accessing data from that table.

Sometime you just have to do what you can.
Post #1268944
Posted Tuesday, March 20, 2012 12:15 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, November 4, 2016 10:42 AM
Points: 3,243, Visits: 2,467
An interesting article Phil - I have seen both sides of the fence throughout my career which is why I choose to be 'pure' Production Support DBA.

That point aside, let us add one more variable to the equation - that being Vendor supplied software. Not just your typical install it, support it, patch it.

Let's call it a 'mutation' with 3 separate code bases:
- pure vendor supplied code
- pure client supplied code
- 'hybrid' code (a mix of Vendor and client based code).

It certainly makes for an interesting day at times. Even though our current charge is 'pure' Production Support, many times we have to get intimate with the code in order to identify root causes for performance based issues. So yes, even 'pure' Production Support DBAs can 'morph' into Development DBAs with the drop of a hat (or table or index).

Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #1269768
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse