What's better for team focusing on DB? Could it be Local database instance for every developer or shared database?

In my opinion a team must have (a minimum of) one shared database for integraton.

Throughout development each team member must have an independed database otherwise changes of database schema could hinder other team people. These instances may be on the centralized server.

I'm able to only discuss how a team I am in presently works, which inserts our needs good enough:

We've one central data model script that updates any database instantly towards the latest schema version. Designers sign in changes for this script along with changes towards the source code (single commit on a single repository). The nightly develops update a central database copy, then a load of automated tests on that database, and also the human QA team also uses this same database the following day for those their testing.

We do not allow schema changes around the central database instance every other way than through the integration develops. For developing the schema change script, changes are developed on the separate database instance, either around the central server, or in your area (based on personal preference).

I do not think it is dependent whatsoever. Each atmosphere must have it's own database instance. Personally, I'd never reccommend that everybody around the team creates exactly the same copy from the source, and that i see the database code and instance exactly the same way.

If you're getting issues with missing database changes, this can be a characteristic of another development process problem. It might be analagous to failing to remember to include a code file to source control.

Jeff Atwood has a pretty good article on source controlling database code.

Different designers allegedly focus on different issues - how can you avoid walking on other individuals toes while unit testing?

I'd absolutely advocate an integration/test atmosphere, that is up-to-date using a Continuous Integration process. This atmosphere frequently works as a litmus test for the deployment procedure too.

At Red-colored Gate we'd suggest that each developer is offered their very own instance, as sandboxing guarantees that designers don't tread on each others' toes. However, you will find benefits and drawbacks with both models, that are layed out further in the following paragraphs:

http://www.red-gate.com/products/SQL_Source_Control/evaluation_center/database_development_models.htm

Within our experience speaking to database designers, roughly 1 / 2 of database development is carried out on the shared atmosphere, and half on the devoted per-developer atmosphere.

From experience, a shared database is much better. Our code accustomed to break constantly because someone added a column on their own local database, then submitted their new source code to SVN. Everybody else's implementation would then break until they determined what had transformed within the database.

I'd possess a shared database for development. We'd a couple of dev databases too for miscellaneous testing.

Getting seperate database instances for any developer enable them to operate in isolation however as a sizable team and focusing on multiple things in the sametime then its good to possess a shared enviornment too to ensure that all the new changes that should be shipped simultaneously aren't breaking one another as well as their dependecies may be determined properly. This will help with determining where any application may break because of a big change. So it's better to possess a shared enviornment too together with some isolated enviornment replica copy from the development enviornment just just in case we may want to test something large and complex that's very critical and want to operate anyhow.

But the only issue is simply too keep multiple enviornment synchronized with one another every missing change could be fatal.