On Sun, 27 Feb 2005 08:43:19 +0000, Lester Caine wrote:

>
>Fabricio Araujo wrote:
>
>> Not when the system is already composed of 6 different
>> applications - this including the simulation engine, the
>> visual interface app, the data management app, the
>> command dispatcher, and conflict calculation app.
>>
>> All of then communicating almost only by the DB.
>>
>> A 3-tier would make the persistence of all these
>> apps to be severely rewritten, Alan. Not acceptable
>> by any means.
>>
>> What I want to a later advocacy of FB adoption is a
>> DB-only migration. Rewrite the SPs and nothing more,
>> which would cost a entire month or even two of heavy work
>> OF ME and maybe more one. Believe me, is much
>> faster to achieve than make the boss buy the idea of
>> creating a 3-tier module.
>
>IF all the data is on a single machine, then there is no problem having
>it in a single database! I came from dBase and was used to having
>separate files for each table, so started by building separate databases
>for sections. There are still separate databases for some areas, but the
>main work is always to the one database, with information gathered from
>others replicated as required. THAT can then be managed between
>different machines as required, and does not get slowed down while
>waiting for network data transfers.

This system is a military simulation. Besides being much more
complex that this, I can map this to a strategy games analogy.

Have you ever played Warcraft or Heroes of Might and Magic
(just to list some)?

If you do and took sometime investigating, you'll learn that
those games allows you to create your own scenarios and campaigns.

How this is achieved? Simple: there's a (kind of) "elements" database
which the map editor (on some of these, the elements appear to be
hard coded since there's no aux files storing it) "query" to create
another
file - the scenario file.

In this analogy, the mapping is the following:
"enciclopedic" database = game "elements" database
simulation databases = game scenario files.

Actually things changed a little and we have to create a
duplication of the original "scenario" database by
backup/restore to doing some specialized analisys.
So we have 2 "scenario" databases by simulation actually.

This is the natural design for this kind of application and the reason
of my intense desire of server side multi-db SQL queries and SPs.

The second scenario is so easy to create!!!!!!!!! Just backup/restore!

>SO look at the problems of what you are asking for and consider the
>amount of work required to implement that with the same flexibility that
>Firebird currently supplies. Look at how others do it, with block copies
>of raw data between machines, and consider the performance implications.
>Can you manage those block copies better since you know WHAT data you
>want and how to configure it.

I don't have to write a line of code to enable this on MSSQL. In this
regard
it's a killing feature to me. I DON'T BELIEVE THAT I'M SAYING THIS,
but it's the truth.

*NOTE ON FIREBIRD MERITS*:

Before someone says that I'm bashing FB - I'll explain some things.
I work for a military organization (MO) called CASNAV which is the
main software house for it's military force - the Navy of Brazil. I'm
not
military - but I work for them
actually. Since I put it on my resume and my superior not oppose this,
I'll
take a word of what is it. Is a military strategy simulation system for
both
real-life analysis and teaching of naval war strategy to new superior
navy
officers. This system runs mainly on the servers of our Escola de
Guerra
Naval (EGN) - translated this name means Naval War School.

This system is based on MSSQL. FB1.0.x, when this project started,
was nothing than real early alpha release. In this case,
MSSQL2k ability of multidb server side queries allowed us a LOT of
flexibility
and my survival all these years - project started in mid 2000 if I
remember correctly
of history internal homepage. I am in project since near the end of
second quater
of 2001.

But only became the DBA on 2003. All that design that I said to you all
is
fruit of that period before I come on charge.

Where the relation with FB? Since I started
on project, I really advogate FB even before you FB Team had even a
ALPHA!!!
The fruit of that advocay happened in late 2002. Since the project
manager changed,
my ex manager asked me (the boring guy that don't loose a chance of
bashing
MSSQL and advogating FB) for a KILLING business case. One that can make
even the most resilient believe that FB must have a chance of prove its
valor.
(That I thank MUCH both Dalton Calford and Claudio Valderrama. You
saved
my reputation on that!!) With Distributel case on hand, they my ex
boss' loved
(he's a linux and open source die hard advocated) these good news.
I told to the person in charge of the new project (which was the second
DBA
on the project I work) and presented the FB to them.....ABSOLUTE
SUCCESS!!!!
I can say that today the Helen's book is the most disputed book on our
library....
And FB BANISHED MSSQL and Oracle from CASNAV for good on new projects.

Sadly my project cannot be satisfyingly ported to FB without those
features:

1 - Dynamic SQL - OK (EXECUTE STATEMENT)
2 - Temp Tables - not OK but workaroundable (if Ann's transient
datasets were available today
I'll won't need any workaround).
3 - The most important one - Multidb server side SQL queries and SPs.

The third one is carved on stone - our simulation system is based on
this
and it really gave us a edge on flexibility and maintenance.