March 17, 2012 at 10:06 am
Comments posted to this topic are about the item Disconnected database development: solving a problem that needn't exist
Best wishes,
Phil Factor
March 19, 2012 at 2:09 am
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.
March 19, 2012 at 7:12 am
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.
March 20, 2012 at 12:15 pm
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).
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply