On Mon, 28 Feb 2005 07:10:26 +0000, Lester Caine wrote:

>
>Fabricio Araujo wrote:
>
>> Me and a lot of people that like to physically isolate independent
>> 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.... ;-/
>
>But at the end of the day I *STILL* see this as a third tier! We need
>some feedback from the gurus, which is why the discussion should be on
>firebird-architect.

As one of our dearest gurus said (Ann H.) , it's just a matter of
finding
the best way to put it in optimizer.

>The processing that is currently being worked on is
>'packaged' in a processing engine based on a single entity of hardware
>with a single file system structure. In order to get two different
>machines (with potentially different OS's) working together, we need
>another layer over the top of the engine(s) which carries out THAT
>processing, but which is not so relent on direct access to the file
>system? As I understand the Vulcan structure, that layer could be across
>different engines altogether, by using the right 'module', but at the
>end of the day it is just the integration of an external tier that is
>currently available of the shelf in a number of ways. MSSQL just hides
>that fact, in the same way that BDE did in the past. As we now know BDE
>was a dead end because of the way it implemented cross engine functions.
>By designing our own 'layers' we have much better control and can 'see'
>what is going on.

I don't need them to work in multiple machines. But physically
separated
that I can mantain the two db separately. If I need to use multiple
machines
I will use distributed transactions.

See Lester, the semantics of the process is that - and anyone in the
simulation arena separate the elements "db" from the scenario archive.
That arena things are played that way. In commercial arena, this is not
such a nuisance.

>
>Don't take this as my being anti the principle. I am only trying to get
>people thinking about what is involved, what the range of requirements
>is, and why it is NOT a show stopper for many of us who manage to avoid
>the 'hole' in the first place ;)

But it IS a show stopper. Maybe not to the majority of the commercial
software comunity, but this is not commercial (operational and
administrative)
software. It's a military simulation. And yes, it is a show stopper.

>Just sheepishly following MSSQL could end in the same hole as BDE - so
>just think about how you COULD do without an integrated tier, and
>implement it externally as it may result in a much faster performance
>and could mean that you could progress in stages using both MSSQL (and
>other engines) and Firebird in parallel as many of us already do. The
>information obtained would then help to move Firebird 4 ( because I
>think THAT is how far way it is ) in the right direction, but allow
>progress towards that end now.

Performance is not the main problem here, is modularity.
I need modular, context separetely dbs. I cannot mix the
the data on a one db thing.

I just need to write a sp that migrate a simulation element
from the elements database to the scenario one and then
I duplicate the scenario db to a other machine to further
analisys. I can't do this on apps.

The elements db cannot be replicated each time I create a
scenario. Strict Requisite.

Tonight I'll make a sintesis of this to FB-Architect.