need tool for managing database object ownership

26 Jun 2006 3:01 PM

batman

we have a group of developers which have created and asked us (DBAs) to
create many objects in the databases including tables / stored
procedures / functions / etc.

since our company is growing, however we have an increasing amount of
objects that have either been abandoned or have several versions.

in an effort to clean of the huge amount of clutter and anytime that
something simple like a stored proc needs to change, it is almost
impossible to predict exactly where we will see negative effects of
this change.

i am looking for a system (preferably without developing our own tool)
that would keep track of history of database objects (in terms of who
created it and what purpose it has) as well as link that to all the
developers/users we might need to notify of any changes to that object.
Also, this should be linked to the application which rely on the
object.

bottom line... every object in the database needs to have at least 1
corresponding contact as well as the applications which us it.

with this information, we can much more easily maintain objects in our
DBs.

thx

26 Jun 2006 6:36 PM

Tibor Karaszi

Possibly this can be of help. Seems it isn't released quite yet, though:

http://msdn.microsoft.com/vstudio/teamsystem/products/dbpro/default.aspx

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/

Show quote

"batman" <uspen***@gmail.com> wrote in message
news:1151334096.716911.238760@i40g2000cwc.googlegroups.com...
> we have a group of developers which have created and asked us (DBAs) to
> create many objects in the databases including tables / stored
> procedures / functions / etc.
>
> since our company is growing, however we have an increasing amount of
> objects that have either been abandoned or have several versions.
>
> in an effort to clean of the huge amount of clutter and anytime that
> something simple like a stored proc needs to change, it is almost
> impossible to predict exactly where we will see negative effects of
> this change.
>
> i am looking for a system (preferably without developing our own tool)
> that would keep track of history of database objects (in terms of who
> created it and what purpose it has) as well as link that to all the
> developers/users we might need to notify of any changes to that object.
> Also, this should be linked to the application which rely on the
> object.
>
> bottom line... every object in the database needs to have at least 1
> corresponding contact as well as the applications which us it.
>
> with this information, we can much more easily maintain objects in our
> DBs.
>
> thx
>

26 Jun 2006 10:40 PM

Erland Sommarskog

batman (uspen***@gmail.com) writes:
Show quote

> we have a group of developers which have created and asked us (DBAs) to
> create many objects in the databases including tables / stored
> procedures / functions / etc.
>
> since our company is growing, however we have an increasing amount of
> objects that have either been abandoned or have several versions.
>
> in an effort to clean of the huge amount of clutter and anytime that
> something simple like a stored proc needs to change, it is almost
> impossible to predict exactly where we will see negative effects of
> this change.
>
> i am looking for a system (preferably without developing our own tool)
> that would keep track of history of database objects (in terms of who
> created it and what purpose it has) as well as link that to all the
> developers/users we might need to notify of any changes to that object.
> Also, this should be linked to the application which rely on the
> object.
>
> bottom line... every object in the database needs to have at least 1
> corresponding contact as well as the applications which us it.

In one word: put everything under version control. If does not exist in
the version-control system, it does not exist at all. From tyhe version-
control system your build your baselines, and any changes to objects
requires you check out code from the version control system and and
check it in again, once the change has passed the module test.

The database should be seen as respository for binary objects and
you should be able to wipe it out at any time, to build a new database
from the version-control system. Developers who have neglected to
check out and in, will lose their changes.

A tip is to have several databases, that makes it easier for people
to understand that they need to use the version-control system.

--
Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

28 Jun 2006 8:47 PM

Paul

Erland Sommarskog <esq***@sommarskog.se> wrote:

> In one word: put everything under version control.

"put everything under version control" is one word? Seems like 5 to
me!

8-)

Paul...

--

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2,

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.

Furthermore, as a courtesy to those who spend
time analysing and attempting to help, please
do not top post.