Thread: partitions versus databases
have an db with about 15 tables that will handle many companies. no data overlap between companies. is it more efficientrun-time to use one database and index each row by company id, and one database and partition each table by companyid, or to create a database for each company? it is a web-based app using persistent connections. no copying.
On 12/08/2011 10:26 PM, chester c young wrote: <blockquote cite="mid:1323354369.98656.YahooMailClassic@web161406.mail.bf1.yahoo.com"type="cite"><pre wrap="">have an db with about 15tables that will handle many companies. no data overlap between companies. is it more efficient run-time to use one databaseand index each row by company id, and one database and partition each table by company id, or to create a databasefor each company? it is a web-based app using persistent connections. no copying. </pre></blockquote><br /> If you post a question on Stack Overflow and on the mailing list, please link to your stack overflowquestion from your mailing list post!<br /><br /> <a href="http://stackoverflow.com/questions/8432636/in-postgresql-are-partitions-or-multiple-databases-more-efficient/">http://stackoverflow.com/questions/8432636/in-postgresql-are-partitions-or-multiple-databases-more-efficient/</a><br /><br/> That'll help avoid duplication of effort, and make it easier for people searching for similar topics later to findout more.<br /><br /> --<br /> Craig Ringer<br />
On 2011-12-08, chester c young <chestercyoung@yahoo.com> wrote: > have an db with about 15 tables that will handle many companies. no data overlap between companies. is it more efficientrun-time to use one database and index each row by company id, and one database and partition each table by companyid, or to create a database for each company? > > it is a web-based app using persistent connections. no copying. > if you know you will never want to aggregate data across several companies. databases are cheap, portable, easily duplicated, and self-contained, can easily be dumped, restored, and dropped individually, go with one per company. if there's a possibility you may want to merge two companies, or aggregate data in some other way you want to put them all in the same database so that sequences can be shared to ensure that ids are unique etc... you still have the option of partitioning by schema, table name, or just by tagging each record. -- ⚂⚃ 100% natural