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 1234»»»

Three Rules for Database Development Expand / Collapse
Author
Message
Posted Sunday, September 16, 2012 3:55 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 10:25 PM
Points: 33,051, Visits: 15,160
Comments posted to this topic are about the item Three Rules for Database Development






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1359874
Posted Sunday, September 16, 2012 5:00 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:06 AM
Points: 36,711, Visits: 31,161
We can define whatever standards, rules, frameworks, processes, etc. that the group wants, but once we decide, we all need to work along in the manner we've prescribed. That's worked well for me, and when everyone follow the rules we've agreed on, things run smoother.


I've found that such "committee decisions" can be horribly wrong especially when people who might not know as much about databases outnumber those that do (think lynch mob, gang rape, and Lemming mentality combined). Everyone working the same way has some very nasty ramifications if they're all doing the same wrong thing.

Rule 1 for database development should be, "Find someone that actually knows how to design databases correctly and then follow their rules."


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1359930
Posted Monday, September 17, 2012 2:22 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 3:22 AM
Points: 98, Visits: 727
Jeff Moden (9/16/2012)
[quote]"Find someone that actually knows how to design databases correctly and then follow their rules."


That will be a real world implementation of Steve's rules then...
Post #1360024
Posted Monday, September 17, 2012 3:39 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 2:37 AM
Points: 1,616, Visits: 1,063
I'm definitely happy with agreeing rules in a group and then following those rules. As long as the rules are what I want to be done and not anyone else's shoddy, half-baked ideas. Fortunately I generally have the loudest and most authoritative sounding voice...

We use a shared database model - I can see why it might be a problem, but it's always worked for us.
Post #1360053
Posted Monday, September 17, 2012 5:03 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 4:03 AM
Points: 575, Visits: 2,501
The idea of saying that one should never do shared database development is ridiculous, especially nowadays when you can have the best of both worlds and use database source control whilst doing either shared or single-user database-development, or both. The reason for doing your development work on your own server is merely to allow you to work on different versions of the database 'at once', which means that you can re-create a version from source control in your own private server and fix a bug or add a feature, without affecting your colleagues, or damaging other versions. I've always advocated doing both types of database development, depending on the task. The private databases are fine for prototyping, trying things out and doing sandbox development, whilst the shared model gives us extremely rapid integration, since we have schemas that prevent developers from banging heads too badly whilst sharing, source control allow us to roll back from a development mistake, virtualization to allow us to work on as many versions as we can tolerate.
I don't understand why there should be objection to the mixed-model of database development. I understand the build and integration problems that come from database application developments that chose to ignore the best-practice of having defined interfaces between application and database, but to try to anathemise or prescribe the perfectly reasonable practice of shared database development as a consequence, is like insisting that everyone should use crutches merely because you've shot yourself in the foot.



Best wishes,

Phil Factor
Simple Talk
Post #1360106
Posted Monday, September 17, 2012 6:38 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:06 AM
Points: 36,711, Visits: 31,161
Dalkeith (9/17/2012)
Jeff Moden (9/16/2012)
[quote]"Find someone that actually knows how to design databases correctly and then follow their rules."


That will be a real world implementation of Steve's rules then...


Possibly. I've found that's normally not true though. I've found that even if a company does have someone who really knows how to design databases, they are, many times, simply not listened to because of schedule or notions by unqualified people on what level of normalization is actually needed.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1360155
Posted Monday, September 17, 2012 7:08 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 10:25 PM
Points: 33,051, Visits: 15,160
Jeff Moden (9/16/2012)


I've found that such "committee decisions" can be horribly wrong especially when people who might not know as much about databases outnumber those that do (think lynch mob, gang rape, and Lemming mentality combined). Everyone working the same way has some very nasty ramifications if they're all doing the same wrong thing.

Rule 1 for database development should be, "Find someone that actually knows how to design databases correctly and then follow their rules."


This isn't about technical design decisions. It's more about process. We agree with naming conventions, we agree that there is a QA process. We agree developers will turn over unit tests or edge cases. We agree that new tables get a review by the group, or by a person.

We decide to work in a way that complements, rather than each person deciding how they like to work.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1360173
Posted Monday, September 17, 2012 7:21 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, June 13, 2014 12:40 PM
Points: 461, Visits: 753
Both methods have pros and cons, and probably both methods together are best. The last development job I had worked well this way.

When a developer is starting to modify or add code, and needs to change table structures, he is going to need to work on a database in order to make those changes. If during that time someone else is working on another bit of code that just happens to rely on the table structure, the second developer might end up chasing his tail trying to figure out why something isn't working, only to find out it was because developer one made a change. Not very efficient. We can't say the code should have been checked in because 1 is still working on it. In this scenario I think working on your own private copy UNTIL you get things stable is best.

Whenever system regression testing occus, it should be on a shared copy. You don't want to test on your own copy and miss changes others have made. So whomever is doing that type of work needs to have a version containing all the changes.

As with most things, it depends. Teamwork is key. After that, as long as everyone understands the guidelines, you can work through issues, but in the end I don't see how you can reliably test things without using a shared copy (or whatever name you want to give it) that contains all the code and changes that developers are finished with. Um, I mean, that developers THINK they are finished with. Testing sometimes finds bugs. Occasionally. Once in a while. Maybe only one or two...


Dave
Post #1360187
Posted Monday, September 17, 2012 8:22 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 8:37 AM
Points: 861, Visits: 2,356
My set of three rules is somewhat different - I say
0) Develop on a full size set of data that is as similar to production as possible. In particular, every wart, mole, blemish, and data violation that exist in production data should exist in your development and test environments.

2) and 3) are fine.

1) is something I personally believe in, but if your production environment is "large", 0) tends to cause 1) to be expensive. I believe in it if and only if each developer has their environment, and they can make at least one backup/snapshots of it, and restore them on their own. That lets them create wonky test cases as often as they like, and operate in a "frozen" environment when debugging certain tricky interaction effects.

1) also requires a shared integration development/test environment, of course.
Post #1360238
Posted Monday, September 17, 2012 9:46 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 9:38 AM
Points: 2,262, Visits: 1,309
Some wonder why I install SQL Server on my local box and develop against that version first. It is obvious, never develop the initial product in a shared environment is critical. I also like to have complete administrative control of the data server for the early life of the project, that way I can do what I need when I need it, and it is controlled only on my box. SO I guess I go one step further, never develop on a shared data server and only on one that you have complete control over. If possible.

The others a fine.

M.


Not all gray hairs are Dinosaurs!
Post #1360294
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse