I concur. Also it makes it easier to remove a customer if they leave.
Finally your backups will only lock up one customer's database at time and
for a much shorter period.
On Thu, August 23, 2007 10:50, Jerry Schwartz said:
> Personally, I think I'd go with one DATABASE per customer. That way the
> code would be the same, and easier to handle. It would be easier to manage
> the security at the database level, I suspect. I'd set up a ../inc
> outside the web server root that would have one file per customer, and
> have the customer-specific variables such as database name, password, and
> forth. Each file would be named after a customer. You'd prompt for a user
> name and password, include the appropriate customer-specific .inc file,
> check the password against what the user supplied, and if it passed then
> create a session with the .inc file variables stored as session variables.
> Jerry Schwartz
> The Infoshop by Global Information Incorporated
> 195 Farmington Ave.
> Farmington, CT 06032
> 860.674.8796 / FAX: 860.674.8341
>> -----Original Message-----
>> From: Jason Pruim [mailto:japruim@stripped]
>> Sent: Thursday, August 23, 2007 10:59 AM
>> To: MySQL List
>> Subject: Database architecture and security
>> Hi Everyone,
>> Just had a quick question about a database I'm working on.
>> I am planning on having the database open to customers of mine to
>> store their mailing addresses on-line, and be able to manage the
>> Is it safe, to have 1 database with lots of tables? Or am I safer
>> setting up separate databases for everyone?
>> I should mention, no one will be accessing the database directly,
>> it'll be through a web interface and php to display it.
>> Any info would be greatly appreciated!
>> Jason Pruim
>> Raoset Inc.
>> Technology Manager
>> MQC Specialist
>> 3251 132nd ave
>> Holland, MI, 49424