You only confirm my first-blush opinion: keep separate databases. Regarding
your second issue (joining across databases for reports), I would suggest
that these operations are best done against an OLAP database not the
numerous OLTP databases. That is, create an additional database whose sole
I have an application and database doing this right now. We run both
ways, a single db per customer and a single customer per db. Smaller
customers are in a shared enviroment and larger customers have their
own db, sometimes they even have their own server. We use a company_id
field in each table
On Mar 18, 2009, at 11:47 AM, Johnny Withers wrote:
I have an application and database doing this right now. We run both
ways, a single db per customer and a single customer per db. Smaller
customers are in a shared enviroment and larger customers have their
own db, sometimes they even have
On Wed, March 18, 2009 06:29, Johnny Withers wrote:
Everytime we make a schema change in development we save an SQL script
into
a directory named in MMDD format. The scripts are named in
MMDD_NNN_DESCRIPTION.SQL format, where NNN is the sequence number.
This
I realize its probably a
I suppose it would... but we have not (and hopefully never will) have to
release more than 12 months worth of upates at a time. If we do, can I
contact you to get all these files renamed???
I can see it causing a problem at hte end of each year though.
Dang.
-jw
On Wed, Mar 18, 2009 at 11:22 AM,
To: Daevid Vincent dae...@daevid.com
Cc: mysql mysql@lists.mysql.com
Subject: Re: Separate customer databases vs all in one
Date: Tue, 17 Mar 2009 21:17:00 -0400
Are these databases identical or merely similar? If they are structurally
identical, I'd go for one database per customer. Then you
I'm writing a report tool wherein we have many customers who subscribe
to this SaaS. There are millions of rows of data per customer. All
customers are islands from each other (of course).
Are there any major issues or benefits between storing each customer in
their own database (with their own
Are these databases identical or merely similar? If they are structurally
identical, I'd go for one database per customer. Then you have isolation,
easy structure updates and above all, consistent front-end code, in
whatever language that occurs. Just obtain the customer ID and then use the
