BULLETINS

As we think about developing an OTA, we need to choose a developing tool and DBMS. You then go through different stages of development and finally gets the OTA developed. Now you have an OTA and definitely will have a database to store all your data.
We normally design our database with the following points in mind. It should operate with maximum speed, size should be kept to the minimum, and should be easy to maintain. We also need to keep in mind the factors that the database may be with multiple files, they may spread over different logical partitions as multiple databases or be in different systems.
Let us go to study the phases of OTA development and see if we need a database for our reference data in addition to OTA transaction database.
Our OTA may have many verticals (modules) like Flights, Hotels, Train, etc. Each of these verticals may have its own reference data. For eg: the list of countries and cities where hotels are available or list of Airlines and sectors in which they operate, and many more data like this. You may be starting the development with any one service, for example Flights, then it will be easy to keep all the data a single database. But in future you may add more services to your system and this would grow as a big system. So keeping this point in mind how would be it if you keep these read only data in a separate database? Definitely it is good to have a reference database (read only data). This makes your database administration and backup strategy simple, a bit improvement in performance also. It is for you to decide which all data are to be considered as reference data.
As these data are for ready only purpose, you can set this as a read-only database. If you do that, Database Engine will make some assumptions about the database; the database doesn't have anybody making changes on it and so will disable locking in the database. That means less overhead, and it should speed things up a bit.  By making your database read-only you will not be able to do any static updating, database shrinking, defragmentation, etc. So we need to be prepared by applying these kinds of activities on the database before you move forward, otherwise you can’t generate full momentum of performance.
If you are working with SQL Server, this is a best place for you to implement indexing on views; it will again add a bit to performance. If you plan indexing on views, read more about the topic and find the best candidate for indexing and understand pros and cons of this scenario. Here is a link that describes the topic
http://technet.microsoft.com/en-us/library/cc917715.aspx
When we talk about reference data, the importance of LDAP comes in handy. LDAP (Lightweight Directory Access Protocol) is X.500 standards based TCP/IP protocol. This protocol is a database like information directory that supports cross- platforms reference. It is heavily optimized for read performance and so it is best suited for reference data. As this can hold any type of data, documents, images, etc., this will help us with speedy retrieval of custom type data.
As you move on, there should be need for updating the reference data, and we will have to add data for new verticals that come in. A metadata of the database (which all tables are updated and when) can be maintained for your future reference that makes it possible for quick and easy updating in future. I hope you may be using various third party tools for supporting database development and administration. These kinds of tools will help you more in keeping the metadata of the changes in data.
Gain maximum speed! Save administration cost! Save storage cost!