Subject | Re: [firebird-support] using multiple databases |
---|---|
Author | Fabricio Araujo |
Post date | 2005-02-27T18:48:06Z |
In the last post, I forgot being technical about this, but for the
advantages to ISVs are very clear: modularity.
You can plug your app db on the customer server, create a dozen
of SPs and voila your product is customized to the customer data.
Ask for customer DBA create a after update trigger to update
critical data on your db and you won't ever need write access to their
db.
Much more easier than rewrite all your code just to create a "3-tier"
like Alan said.
Detail: you app code (which take much more create and maintain)
doesn't have to know of the existance of the customer's DB.
advantages to ISVs are very clear: modularity.
You can plug your app db on the customer server, create a dozen
of SPs and voila your product is customized to the customer data.
Ask for customer DBA create a after update trigger to update
critical data on your db and you won't ever need write access to their
db.
Much more easier than rewrite all your code just to create a "3-tier"
like Alan said.
Detail: you app code (which take much more create and maintain)
doesn't have to know of the existance of the customer's DB.
On Sun, 27 Feb 2005 08:23:16 -0500, Doug Chamberlin wrote:
>
>There is really nothing fundamentally wrong with building your application
>the way you have but given your design you *do* severely limit your ability
>to change databases easily. If current Firebird does not fit your
>application structure, then Firebird may not be a candidate for your use.
>Unfortunate for both you and the Firebird team, but nothing to lose sleep over.
>
>I don't think the Firebird team should worry about enhancing its database
>to handle your design needs. Firebird cannot be SQL Server and should not try.
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>