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


Disconnected database development: solving a problem that needn't exist


Disconnected database development: solving a problem that needn't exist

Author
Message
Phil Factor
Phil Factor
SSC Eights!
SSC Eights! (951 reputation)SSC Eights! (951 reputation)SSC Eights! (951 reputation)SSC Eights! (951 reputation)SSC Eights! (951 reputation)SSC Eights! (951 reputation)SSC Eights! (951 reputation)SSC Eights! (951 reputation)

Group: General Forum Members
Points: 951 Visits: 2953
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
IceDread
IceDread
Old Hand
Old Hand (359 reputation)Old Hand (359 reputation)Old Hand (359 reputation)Old Hand (359 reputation)Old Hand (359 reputation)Old Hand (359 reputation)Old Hand (359 reputation)Old Hand (359 reputation)

Group: General Forum Members
Points: 359 Visits: 1145
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.
ejoell 66477
ejoell 66477
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 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.
Rudyx - the Doctor
Rudyx - the Doctor
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3560 Visits: 2478
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).

Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
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