Development Databases

DATABASE

Development Databases

Postby eoinogorman » Sat, 14 Aug 2004 01:47:31 GMT

Folks,

I am working as part of a large development project, with multiple
development streams, all of which use ingres databases.
 
Is there a best practice for providing developers with their own
development "area" within a development database?

Currently, in development we provide dba-owned "base" tables. These
tables have an extra "user" column that is not in the production
database. This column is populated with the ingres user's username. A
view is then created on the base table based on the username, thereby,
providing each developer with their own personal "slice" of the base,
dba-owned table.

The use of user-owned schema tables is currently being considered, but
this will be rejected unless there is a well-defined process for
handling table structural changes. Does anyone know of such a process?

Does anyone know of any other large Ingres-based projects that have
addressed this issue?

Thanks,

Eoin

Re: Development Databases

Postby Roy Hann » Tue, 17 Aug 2004 07:36:09 GMT






I am not sure I understand the problem.  If the developers currently use a
view of a DBA-owned base table which restricts the rows they see, then the
table they use is under the complete control of the DBA.  The DBA can add
and drop columns, change datatypes, or whatever.

If each developer is given a table in their own schema instead of a view, it
can still be under the complete control of the DBA in exactly the same way
because the DBA can always access the user's schema using the SET SESSION
AUTHORIZATION command to impersonate the user.  The script the DBA would use
to roll out changes would be a bit more complicated and a lot longer, but
nothing special.

One problem is that users could drop a table in their schema and re-create
it more to their liking with who-knows-what mutations, but they can do that
already, because any table they create in their own schema conceals a
similarly named table in the DBA's schema.

I guess the process for handling structural changes would be a script that
impersonates each developer in turn, replacing their tables with new ones.

Or am I missing the point of your question?

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"




Similar Threads:

1.Best practices for migrating a development database to a release database

I have searched the Internet... but haven't found much relating to this.

I am wondering on what the best practices are for migrating a 
developmemnt database to a release database.  Here is the simplest 
example of my situation (real world would be more complex).

Say you have two versions of your application.  A release version and a 
development version.  After a month of developing you are ready to 
release a new version.  There have been many changes to the development 
database that are not in the release database.  However, the release 
database contains all your real information (customers, etc...).  What 
is the best practice for migrating the development database to the 
release database?

I have thought of the following situations:
-Simply track all the changes you made to the development database and 
make the same changes to the release database
-Back up the release database... overwrite it with the development 
database... then copy all your real data back into the release database 
(this last step is probably quite difficult)
-Perhaps some combination of the two


Does anybody have any recommendations?

Regards,
Collin Peters

2.[Info-Ingres] Development Databases

3.Best practices for migrating a development database to a

4.Best practices for migrating a development database

Beside version controlled schema files we have a guy who writes
migration scripts based on the old schema and the new (development)
schema (frozen e.g. by branching in CVS).
Usually there are 3 steps involved:
 - a pre-migration script, which prepares the data base for the new
schema, by adding the new structures needed for the data migration;
 - a data migration script, which moves around data between the old and
the new structures;
 - a finalization script, which removes the old structures not needed
anymore;

I think there's no way to make any of these steps automatically computed
as a diff between the old and new schemas...
We usually do it anyway so that after step 1 was executed, both the old
version of the application and the new version can work at the same
time, and the new version will only use the data migrated by step 2, but
I suppose our application is not very typical (we have lots of distinct
customers which live in the same data base but have distinct data).
This also means we try to do minimal changes to the data base and we try
to only have additions, no modifications, this makes migration easier.

HTH,
Csaba.


On Sat, 2004-09-11 at 09:29, Thomas F.O'Connell wrote:
> One thing I used to do (and I won't necessarily claim it as a best 
> practice) was to maintain my entire data model (tables, functions, 
> indexes, sequences) as SQL (plus postgres extensions) CREATE statements 
> in text files that were version controlled (via CVS). I had an entire 
> set of utilities that could modify the existing database as necessary 
> to treat the SQL files as authoritative. For anything new, the create 
> statements sufficed, but for modifications, some objects had to be 
> regenerated. When it was time to release, we would export the textual 
> SQL schema to the production server, make the necessary updates using 
> my utilities, and then restart services.
> 
> Since I'm deploying postgres in new environments now, and I left these 
> utilities behind at another job (where they're still in use), I've been 
> thinking more about the concept of schema version control. But I'm 
> similarly interested in any concepts of best practices in this area.
> 
> -tfo
> 
> On Sep 10, 2004, at 1:55 PM, Collin Peters wrote:
> 
> > I have searched the Internet... but haven't found much relating to 
> > this.
> >
> > I am wondering on what the best practices are for migrating a 
> > developmemnt database to a release database.  Here is the simplest 
> > example of my situation (real world would be more complex).
> >
> > Say you have two versions of your application.  A release version and 
> > a development version.  After a month of developing you are ready to 
> > release a new version.  There have been many changes to the 
> > development database that are not in the release database.  However, 
> > the release database contains all your real information (customers, 
> > etc...).  What is the best practice for migrating the development 
> > database to the release database?
> >
> > I have thought of the following situations:
> > -Simply track all the changes you made to the development database and 
> > make the same changes to the release database
> > -Back up the release database... overwrite it with the development 
> > database... then copy all your real data back into the release 
> > database (this last step is probably quite difficult)
> > -Perhaps some combination of the two
> >
> > Does anybody have any recommendations?
> >
> > Regards,
> > Collin Peters
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to  XXXX@XXXXX.COM  so that your
      message can get through to the mailing list cleanly

5.Using a Makefile during database development

6. a database, is a database, is a err database

7. Tools for collaborative development?

8. Team Development



Return to DATABASE

 

Who is online

Users browsing this forum: No registered users and 4 guest