multiple customers account, one set of files? [system architecture] 2

[JamesGMills]

Hello...

I have a general question for you guru people...

We have a web application we have developed for a client and we have recently realised that we could actually set this up as a service for others as well as our client who we developed it for...

My question is geared more towards the system architecture.

What would be the recommended way to turn a set of php files and a database into a multi account system?

I would like the main set of php files to be a core so that all the sites run off the same files so that updates to any files are automatically avaliable to all users of teh system. So this rules out copying a set of files and creating a new URL/account on teh server.

The other thing is the database. Would you create a new database for each new customer/account and basically create a blank database from a core database. The in a settings file somewhere just see what users account the user is logged in as and then hook them up to their db copy? Then you could maybe do a db structure sync every night for developers changes?

Or would you just use one big DB and reference the users account in all records?

I am just not sure how you can use things like

http://customersaccount.mysystemdomain.com

and

http://customertwo.mysystemdomain.com

and use one set of files for everyone etc...

Like basecamphq.com

If anyone has any experience with this i would love to hear from you.

Thanks in advance,

James

------------------------

http://www.jamesmills.co.uk

 

[jpadie]

Hi

first off, what you are talking about is not only doable but eminently sensible as you then have to maintain only one codebase.

the question of databases depends rather on what type of application you are providing. splitting the database is fine but it may not be great for performance depending on how many clients you have. likewise if your database is not properly normalised you might run into scaling problems and query slowdowns if you use one database for all customers. Give us a bit more meat and we can give better responses.

on to your last question: there are three ways of handling domain names like this (that occur to me off the top of my head- bound to be many more)

method one:
point all domain names to the same folder and use $_SERVER["HTTP_HOST"] to differentiate between installations

method two:
point all domain names to different folders and in the index.php file require_once the master 'index.php' file. remember that you will need to use absolute file references throughout your application.

method three (a variant of method one)
have all domain names point to the same folder and ignore what the domain name actually is. instead use the customer login to determine which database to use for data and/or UI to display. This necessitates a single database for all customer logins. the login database does not need to be the same database (of course) as any of the substantive data databases.

 

[JamesGMills]

Hi,

Thanks for your reply. Some interesting things to think about there.

The data will be accounting information, invoices, payments, receipts etc... The structure has already been normalized but will need a little more work and I will have to use popper secondary-keys references in the mysql database setup.

I am experienced with building databases for small systems and not thinking too much about scalability. I guess mysql is capable of holding some huge amounts of data in one table etc?

I think maybe I would go down the one database route and have an account reference number column in each table to reference that data to a customer/account?

I will think about the options with domain names. We will have to have a seperate customer/account database to manage subscriptions and licences etc... so may be able to link something in with this if i point all domains to the same folder.

Stupid question but how would you point all domains to one folder? I am using apache and cPanel/WHM setup. I take it you would just setup another subdomain in the DNS and point it to the root domain?

I like the idea of also using the HTTP_HOST as this could be used to get a logo for the login screen for that account.

Thanks,

James

------------------------

http://www.jamesmills.co.uk

 

[ingresman]

I think on routing to each site would best be achieved by DNS mapping ponting at a single site. Talk to your ISP about that. Then brand the site accordingly (e.g. logo, locale, language etc) by picking up the domain name that got you here. Remember some customers might even want to host the service on thier own site and not use your servers.
It would be worthwhile putting some thought into what you might want to achieve with this venture. For example 80% of your customers may be quite happy with the default look and feel, the other 20% may be prepaired to pay to have an indival look and feel that might, for example, look like thier own site. Offering this could be a revenue stream for you. So the PHP code might need to change. This is why you often see sites using the MVC (model View Controller) design pattern to seperate the business logic (the Model) from the user interface (the View). Further more you might want to put in place some kind of persistence layer which will handle the database storage. This would enable you to use any back end DB (e.g. MYSql, Oracle, DB2) as appropriate. This leads me on the the database.
Agree with JP here, you need to understand excactly what is going on. But by putting in place a persistemce layer you do get some issolation and so make it easier to work with. If you design your data structres appropriatey you would be able to support as many client as you like in one single database which might suffice for ,again 80% of your customer base. But you may have one customer who has particular processing requirments and maybe even hits the database much harder than anyone else. This could be placed in it its own database on the server or on different server or even at a customers own data centre should they wish.
How would you charge customers ?, would it be flat fee or depend on how much resource they use ?
As you can see you have a lot to think about. In summary I would say:
Make your site brandable, perhaps by a config file driven by the URL. This would contain pointers to logo, CSS, DB connnection string etc.
Consider a MVC or simple templating to make your site visualy dynamic.
Consider a persistance layer for the data so type and location are transparent to your applicatrion.
Consider putting your business logic into classes that can be replaced or extended depending on customer needs.
I know much of this steps outside of your original question but if you want to sell to many people make your site as flexible as possible and be open to bespoke work for each customer, after all we're in it to make money after all !

 

[JamesGMills]

I wonderful reply, and again got me thinking! One of the reasons why I lose this forum is people really take the time to reply to exactly what you are asking and then go that little further and mention a few things you may or may not have thought about.

This has certainly given me some things to think about.

One of the main concerns for me is the scalability. I am thinking of looking into the Amazon Web Services for database storage.

Can I just confirm that you guys think its an ok idea to have one table called invoices, for example, and have a CustoemrID column which would link that invoice to a client/account?

This also means that, for example, the payment table would also have a CustomerID column which would do the same...

Cheers,

James

------------------------

http://www.jamesmills.co.uk

 

[ingresman]

Yes that would work ok, it's a fair enough way to keep data seperate, Just be carefull if you ever an online report building facility you will have to make sure you maintain confidentialty

 

[jpadie]

Stupid question but how would you point all domains to one folder? I am using apache and cPanel/WHM setup. I take it you would just setup another subdomain in the DNS and point it to the root domain?

i don't use cPanel but normally (for apache) you would just specify a common docroot in each virtual host.