Dimitry Sibiryakov írta:

>> As I mentioned in the subject, I would like to ask you, if there are any
>> plans to move Firebird in the direction of distributed database
>> management systems?
>>
>
> What kind of "distribution" you have in mind and for what purpose?
>
> SY, SD.
>
>

Below is a classification, and momentally I would need mixture of DB1
type, that is some data are replicated from a central location, and DB2
type, where some distant locations have their own data, that they can
read and write. Of course I would try to find some kind of a general
solution, where decentralization parameters could be set up, even on
table level. Unfortunately SQL is prepared for handling such situations,
so this seems to me as a rather difficult problem.

E.g.: Costumers are stored centrally, and are replicated to all distant
locations. On the other hand, Orders are stored locally, and each
distant location can place a new order to its own database instance. Of
course a query like SELECT SUM(TOTAL) FROM ORDERS WHERE ORDERDATE...
issued from the central location should collect data from all distant
locations.

Best regards, Zsolt


Decentralized database types - based on data and index location


DB0 - central database

Located within one computer system. We have only one copy of data and index.


DB1 - replicated database

Central database is copied on multiple computers. We have to assure
consistency - it means that all copies are identical DB_i = DB_j . This
type is good if reading (r) is main operation on the database. Problem
emerges when users change contents of database (add, update or delete).
In this case local indexes and data on all locations have to be renewed
(if we update only index has to be renewed).


DB2 - central database with subsets

Subsets contain their own data of specified location. Other data can be
found in central DB when need for that emerges.


DB3 - central database with intersecting subsets

DB3 works like DB2. The main difference is when data is being changed.
In DB2 we only have to renew at one location. In DB3 we have to know
locations where particular data is stored and renew those locations as
well - data consistency is very hard to maintain. DB3 type is highly
avoided.


DB4 - central index with subsets

We don't have central data anymore, only index stays central.


DB5 - central index with intersecting subsets

Same as above DB4 type. However same data can appear on multiple
locations. When reading we get multiple locations where data is stored.
When changing we have to update data on all locations, central and local
indexes as well.


DB6 - partitioned database

Database without central data or index. In this type is impossible to
plan search procedures that would be consistent and defined in advance.
Change data is simple (done only in one place) when we found its location.


DB7 - intersecting database

Same as DB6 - we don't have central data or index. We have however
additional problems because data can be stored at different locations
(when changing we have to update them all).