Hi Helen,
I completely understand what yu r saying..change control..how to
implement it? Can yu pls give some suggestions?Best practices?
thks

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 09:08 PM 18/08/2005 +0000, you wrote:
> >Hi,
> >we have just completed our database design,and stored procedures
> >also.Now,there were some issues...some columns datatypee was

required

> >to be changed..but Firebird is not allowing it as it says there are
> >dependencies due to stored procedures...so we have to drop all

those

> >stored procedures..
>
> The "R" in "RDBMS" stands for "relational" in "Relational Database
> Management System". If an RDBMS is implemented soundly,

the "Management"

> will provide systemic support for all dependencies in databases.

This

> includes preventing anyone from making changes that will break

dependencies.

>
> >Our database team is worried it might become
> >difficult to maintain changes..to database and stored

procedures..are

> >their some ways to handle such scenarios?
>
> Definitely. Database teams need to follow effective organisational
> practices. The fact that the discipline of database system

integrity has

> your team worried seems to indicate that it has a need to address

change

> control.
>
>
> >P.S because of such problems..I dont like SP's...dynamicSQL using

an

> >ORM tool is the way to go..
>
> Statements like this throw me into despair. ORM tools are handy,

but they

> will never circumvent problems that arise from an inconsistent,

unstable

> design and poor object management practice. One of their worse

aspects is

> that they allow anyone to be the SYSDBA. This is antithetical to

handling

> the scenarios that have got your database team worried.
>
> One of the prime objects of a database management system is to

enable the

> abstraction of business rules so that they are enforced by the db

system,

> independently of whatever application code is thrown at it. There

*are*

> well-recognised ways to achieve this externally, through solid

design and

> careful layering of application code in a 3+n tier architecture,

with

> centurions armed and ready at the gate.
>
> In 2-tier client/server it is risky business at best to rely on

client code

> to implement rules.
>
> ./heLen