Thread: Transactional vs. Read-only (Retrieval) database
I'd like to get some opinions if there are any benefits (i.e. in terms of performance) of creating two separate databases, one for transactions (insert, update, delete) and the other one is for retrieval/search (select).
Thanks in advance for your input.
Sam
_________________________________________________
Expand your wireless world with Arkdom PLUS
http://www.arkdom.com/
Expand your wireless world with Arkdom PLUS
http://www.arkdom.com/
Le Jeudi 11 Avril 2002 15:14, Samuel J. Sutjiono a écrit : > I'd like to get some opinions if there are any benefits (i.e. in terms of > performance) of creating two separate databases, one for transactions > (insert, update, delete) and the other one is for retrieval/search > (select). Dear Samuel, You do not need to create two separate databases. It is possible to write server-side code to copy static data (read-only) to other tables. This can be done using triggers and/or cron jobs. A more sopisticated solution would be to store LEFT JOIN query results in the original table using triggers. For example : you have tables COMPANY and EMPLOYEE. Instead of running a LEFT JOIN on EMPLOYEE->COMPANY, it is possible to store COMPANY name in table employee using a trigger. Then, you don't need LEFT JOINS any more, simple SELECTs are enough, which is fantastic for heavy loaded databases. Same as for many operations. Try the EXPLAIN clause on a query. If too heavy, try to write some code to simplify the query using triggers... PostgreSQL is the most advanced open-source database available today. It has several server-side languages (plpgsql, plperl, plpython). Maybe you should try plpgsql which is easy to learn. Well-optimized, PostgreSQL can run 10 times faster than well-known open-source databases. If you need to test server-side programming, do not hesitate to download and install pgAdmin2 (http://pgadmin.postgresql.org), PostgreSQL Windows GUI. Cheers, Jean-Michel
Sam, > I'd like to get some opinions if there are any benefits (i.e. in > terms of performance) of creating two separate databases, one for > transactions (insert, update, delete) and the other one is for > retrieval/search (select). No. Not in Postgresql, unless you wanted to get really exotic. Also, keep in mind that you cannot join tables from seperate databases in postgresql. There are *lots* of performance advantages to be had by managing disk access and memory carefully. But not through seperate databases. -Josh Berkus