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
purpo
nal Message-
From: Arthur Fuller
To: Daevid Vincent
Cc: mysql
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 custome
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,
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
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
allows us to string the files together in the proper order to apply when an
update g
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 the
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 t
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
approp
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 ta
