Subject | Re: [firebird-support] using multiple databases |
---|---|
Author | Fabricio Araujo |
Post date | 2005-02-28T02:49:11Z |
On Sun, 27 Feb 2005 18:16:33 -0500, Doug Chamberlin wrote:
Thanks Doug
and diverse constraints database (constraints = requisites).
I have one db that I backup one time at week. And the other
during the simulation are backuped to create point-in-time
restore (like a save game feature) Plus extra auto backups a day.
In a week there's commonly from 20 to 40 backups.
Since each simulation scenario goes to a db, disk space wasted
is not a problem. If I merge the 2 on a (teorical) FB migration, each
simulation will go to point that we generate GB and GB of backups!!!
Is not only this - the maintenance would become enormously
increased... And me, actually not working overnight, will became
a true vampire.... ;-/
because of this. And the benefits of that feature is much great
than at first sight...
>God exists!! :-)))
>At 2/27/2005 01:25 PM (Sunday), Fabricio Araujo wrote:
>> > Firebird cannot be SQL Server and should not try.
>>
>>The only good thing about MSSQL2k engine, and what we don't have on
>>FB and is only attainable using application code is multidb server side
>>SQL queries.
>
>My apologies for speaking up without understanding the original context of
>the discussion. If all you are requesting is SQL queries that cross
>database boundaries, then I am in full support that this feature should be
>added to Firebird at some point.
Thanks Doug
>Me and a lot of people that like to physically isolate independent
>(I still think your argument sounded like "My app is designed to require
>this and therefore I think Firebird should have it so I can avoid
>re-design".)
and diverse constraints database (constraints = requisites).
I have one db that I backup one time at week. And the other
during the simulation are backuped to create point-in-time
restore (like a save game feature) Plus extra auto backups a day.
In a week there's commonly from 20 to 40 backups.
Since each simulation scenario goes to a db, disk space wasted
is not a problem. If I merge the 2 on a (teorical) FB migration, each
simulation will go to point that we generate GB and GB of backups!!!
Is not only this - the maintenance would become enormously
increased... And me, actually not working overnight, will became
a true vampire.... ;-/
>( This, I think, is a poor rationale to sell to the FirebirdMaybe. But I'm not the only that cannot move to FB a system
>team. Much better would be to point out that database replication and other
>generic functionality would be much easier to accomplish using
>multi-database SQL statements.)
because of this. And the benefits of that feature is much great
than at first sight...
>
>Anyway, consider me a supporter of the request for multi-database SQL
>statements (which expose the underlying capability of the engine).
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>