Hi I am looking into federated databases, I understand the concept of the federated database but wondered how the population of the database occurs, i.e. does it just create the views/nicknames when the user executes a query so that no data is permanently stored in the federated database or is the federated database populated based on a schedule etc?
Also when you have two databases which have different fields in the tables how would the federated database translate from one to the other to make the data compatible?
All federation gives you is the ability to access the data that resides in one database as if it was part of another database. Think of it this way... You create a "View" of the table in Dabase A of data in batabase B. Anything you can do to the View actually impacts database B, even though you are not directly connect to it. Insert, delete, and update on the View modifies the data on database B. Like all Views you need to define it ahead of time. This is the Alias. Please read the Federation Guide fully to understand how it all works.
Data is populated like any other database (insert, update, delete). It can be done either straight to Database B, or through the federation from database A.
Can you explain your last question furthor? I do not understand what you are asking.
The second question was if you got Database A and B again, some of the data stored in A is slightly different from that stored in B i.e. A stores departure date and return date where as database B stores departure date and length of stay.
You need to replicate the data in database A into database B by means of federation or snapshots (as an exmaple) how would you achieve this, i.e. if you did it as a trigger you could have something along the lines of length_of_stay = return_date - departure_date.
It depends on you business logic. If you need to keep the two tables in sync acroos the federation, then yes a trigger can do that. You need to examine you specific needs. Federation is a great device, but it has costs associated with it--just like everything else. You need to determine the least costly way to get the data where it needs to be--and you are the only one that can determine that.