At 14:17 11/10/01 +0200, you wrote:

>At 13:54 2001-10-11 +0200, you wrote:
>
> >However, we are about to deploy an important application (IB-PHP, (and a
> >few java soon) to answer the following question...) and I'm happy to hear
> >the problems comes with evolutions of the structure of DB, not with
> >data-working... We began to be afraid to have made a bad choice ;-)
>
>Is your application a 24x7 ? If so, you need to schedule _some_ downtime
>when you update SPs. You only need to to disconnect all users and then
>reconnect again. In your case it is a web app where I assume only the web
>server + extensions are connected. This will be easy to do as it does not
>take long to disconnect/connect. However, if you have sustained traffic, it
>might throw some users off. Check when your least traffic is.
>
>In terms of managing data, IB is superb. We have been running a
>manufacturing / financial system for 6 years now where the number of
>transactions per day are in excess of a million. The organisation has NO IT
>personnell and the system has been running with virtually no problems. In
>the 6 years, the amount of serious maintenance it required (apart from new
>stuff being implemented) is about 2 weeks (that is total hours spent). Yes,
>that is VERY good... The system now has about 300 tables and some of them
>has in excess of 10 million records. The DB size is 1 Gb, but this is small
>compared to some of the others I have heard of...
>
>I don't think you have made a bad choice, as long as you control the
>metadata updates with properly structured procedures under the right
>conditions..

Thanks a lot for those ideas/suggestions.
In fact, our IB-DB will be on the web for a small part and on the intranet
for the biggest part (2 servers. DMZ between Intra and inter)
The intranet part does not require 24x7, just 12x7, so we will be able to
work nigthly ;-)


Note : is "intranet" OK in english ? in french, it mean web limited to a
company.
--
Paul