|
When developers shares a Sql Server server, you create a separate database for each developer. It is also common to have a separate database for each project each developer works on. Should the same be done in Oracle?
(comments are locked)
|
|
Creating a seperate Oracle database is much more heavy-weight than creating a SQL Server database. An Oracle database is more analogous to an instance in the SQL Server world than to an individual database, and a schema within that Oracle database would be more analogous to an individual SQL Server database. So it depends on the requirements of the projects - if they need to have different database-wide settings, then seperate databases may be required, but it is very likely that they can be best accomodated by residing in different schemas (and possibly different tablespaces) within the same database, if they would previously have been happy with different databases on the same SQL Server instance. what is the difference between a schema and a tablespace?
Oct 29 '09 at 11:58 AM
Ian Ringrose
A schema is a logical grouping of objects - so it changes how you refer to the object. A tablespace is a physical grouping of objects - it changes how the objects are actually stored on disk(s).
Oct 29 '09 at 12:03 PM
Kastaka
(comments are locked)
|
|
The normal thing with Sql Server is to install a free express edition or cheap Developer edition on each developer's work station, rather than a separate database on one common server somewhere. There's also typically a common development server, but this would be shared among developers and used for merging changes — to keep everyone in sync. so should a developer create a seperate local oracle database for each project?
Oct 29 '09 at 12:04 PM
Ian Ringrose
(comments are locked)
|
|
I would suggest creating users/schemas within a database instance to start with and then only breaking a user/schema out into a separate DB instance if they require config options incompatible with your main DB instance. At the very minimum this will reduce the complexity of any required backup/restore coverage you may wish to put in place.
(comments are locked)
|
|
We usually just create seperate schemas for each user..
(comments are locked)
|
|
As with everything else -- it depends. For SQL server, if the developers are remote with no access to a central server then using independent databases would be fine but merging changes could be a pain even with SQL Compare and SQL Data Compare. I've found it best to use a central DB and a common schema (ie app) and place more specific objects in more specific schema (ie. config, hr, sales, mkt). This give you security options (only hr employees can see/use hr objects). I'll defer to the Oracle experts however, I believe Kastaka to be correct. Regardless of the platform, developers need to be able to work and play nicely together. Forcing them into the same "logical database" (oracle schema or SQL database) is best. If the developers need a seperate sandbox for trying a few things then make that available to them with a sandbox schema/db. The final understanding needs to be that their code must integrate into the final product. Given that ALL sql is check into the souce code control system and then merged into the installer(s) to create the databases on the customers site, why is the above an issue at all?
Dec 18 '09 at 05:24 AM
Ian Ringrose
(comments are locked)
|

