List:General Discussion« Previous MessageNext Message »
From:Jerry Schwartz Date:August 23 2007 5:50pm
Subject:RE: Database architecture and security
View as plain text  
Personally, I think I'd go with one DATABASE per customer. That way the your
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 directory
outside the web server root that would have one file per customer, and would
have the customer-specific variables such as database name, password, and so
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.

Regards,

Jerry Schwartz
The Infoshop by Global Information Incorporated
195 Farmington Ave.
Farmington, CT 06032

860.674.8796 / FAX: 860.674.8341

www.the-infoshop.com
www.giiexpress.com
www.etudes-marche.com


> -----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
> records.
>
> 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
> www.raoset.com
> japruim@stripped
>
>
>



Thread
Database architecture and securityJason Pruim23 Aug
  • Re: Database architecture and securityRolando Edwards23 Aug
    • Re: Database architecture and securityJason Pruim23 Aug
  • Re: Database architecture and securityGary Josack23 Aug
    • Re: Database architecture and securityJason Pruim23 Aug
  • Re: Database architecture and securityDavid T. Ashley23 Aug
    • Re: Database architecture and securityJason Pruim23 Aug
      • Re: Database architecture and securityDavid T. Ashley23 Aug
  • RE: Database architecture and securityJerry Schwartz23 Aug
    • RE: Database architecture and securityWm Mussatto23 Aug