hey everyone -- i searched, but to no avail -- and i have some specific questions.
i basically want to create a platform for dog groomers to have their site on. basically each site will have it's own images and css, but they will all use the same backend. i'd also like each site to have it's own database.
so, with that said...i have a few questions...
1) do i create a "common" directory, and then a directory for each new site?
i was thinking of having the common libraries and classes in a shared 'common' directory...then referencing those files with a "../" (for example) from each of the 'site' directories -- bad design? somtehing that would work better?
2) would virtual hosts be the best way to manage this?
What im thinking is that i would have "AshleysDogGrooming.com" go to one docroot, and "CarlasDogGrooming.com" go to another. Can i set variables in the apache config that could be read by PHP? If not than...
any ideas/suggestions?
Thank you -- my first post, and i'm looking forward to learning a few things...
*rc*
multiple sites / same codebase
Moderator: General Moderators
Re: multiple sites / same codebase
I think that's how I'd do itrobocop wrote:
1) do i create a "common" directory, and then a directory for each new site?
i was thinking of having the common libraries and classes in a shared 'common' directory...then referencing those files with a "../" (for example) from each of the 'site' directories -- bad design? somtehing that would work better?
Yeah again I'd do it like that but you wouldn't have to set a variable you could just use $_SERVER['SERVER_ADDR'] (I think that's what it isrobocop wrote: 2) would virtual hosts be the best way to manage this?
What im thinking is that i would have "AshleysDogGrooming.com" go to one docroot, and "CarlasDogGrooming.com" go to another. Can i set variables in the apache config that could be read by PHP? If not than...
any ideas/suggestions?
Thank you -- my first post, and i'm looking forward to learning a few things...
*rc*[/quote]
Re: multiple sites / same codebase
Also, if you were using a model view controller application pattern you could just use a different directory of view files for each version of the site..
Re: multiple sites / same codebase
ya know, im planning on using CakePHP, so i'll be MVC-ing it like crazy....
but, just swapping view files wont be sufficient enough as ill have to change databases, a few nomenclature items, and other things...
so what do you think, would it be better to have my SINGLE application setup, and then inside the app have different directories for stuff (an images directory with an subdirectory for each site, CSS directory with files for each, etc)
-or-
should i create MULTIPLE cake apps that share a common codebase? the first one sounds 'easier' -- just not sure if it's 'better'....
thanks everyone!
but, just swapping view files wont be sufficient enough as ill have to change databases, a few nomenclature items, and other things...
so what do you think, would it be better to have my SINGLE application setup, and then inside the app have different directories for stuff (an images directory with an subdirectory for each site, CSS directory with files for each, etc)
-or-
should i create MULTIPLE cake apps that share a common codebase? the first one sounds 'easier' -- just not sure if it's 'better'....
thanks everyone!
Re: multiple sites / same codebase
If you are offering this as a service, what you are talking about is called "multi-tenant." You may find Multi-Tentant Data Architectures a helpful overview on the DB side. For static content, consider using a CDN to distribute images, css, and javascript. I think the Amazon CDN will probably be pretty affordable and easy when its out. For the dynamic pages, I'd suggest one application that served alternate content based on domain. Your actual architecture depends alot on how much static html content you have. You can serve static content through your dynamic infrastructure and then use a front end HTTP cache to make it really fast. Wikidepedia does this and the backend code is all publicly available. For customization, you need to define "flex points" that each customer can control. Essentially you'll have customer specific code modules and plug them in based on configuration. Make your per-customer configuration dynamic from the database, rather than from files. Now you're ready to sell 10,000 dog grooming sites. 
Of course, alot depends on how many tenants you intend to have. If you use apache virtual hosts and file based management, it will become unwieldy to maintain as you add more tenants. You also have to deal with issues such as requiring a code push & apache restart to add new tenants. That puts a crimp on any self-serve plans.
Again, the architecture all depends on your goals.
Of course, alot depends on how many tenants you intend to have. If you use apache virtual hosts and file based management, it will become unwieldy to maintain as you add more tenants. You also have to deal with issues such as requiring a code push & apache restart to add new tenants. That puts a crimp on any self-serve plans.
Again, the architecture all depends on your goals.
Re: multiple sites / same codebase
Reading that link, it would appear in my system(s) I'm applying a shared schema pattern, where tenet data is partioned with a discriminator field. Using multiple databases allegedly is better in terms of performance but it breaks the rules of normalization and I haven't felt any performance aches as of yet, and if I did I would just throw some more hardware at it or implement mysql range based partitioning, which essentially segregates data rows to different quadrants of storage for faster lookup. Since everything is one database I can easily do sub queries for queries that span multiple tenets ( one user with multiple websites on the system ). If performance is an issue I could always factor out the discriminator field and implement cross database joins, the reason I haven't done so yet is I find it much conceptually cleaner to have one single schema, therefore less composition in primary keys
( things can be identified by their `id` field, if Tenant A adds a product it gets assigned product ID 1, if Tenant B adds a product it gets assigned product ID 2.. this would all be internally handled by the DBMS. Extenerally to the data the model would interact with the end user allowing them to generate their own pseudo primary key that would be enforced by the application not the database, for instance in essence a unique key has to take into account the tenant_id scope, as such unique constraints at the DBMS level become useless, Tenant A creating a product with a sku of '123' should not stop Tenant B from creating a product with the same SKU, but should be enforced within the scope of all of Tenant A's tenant accounts )
I do however like the idea of having a database for each tenent, for the security reasons discussed in the article. Once I have my system completed I might refactor to that approach. The disadvantage however is additional overhead incurred in provisioning new tenets
I've also been considering storing tenant specific metadata in it's own database from the main application, storing extensions to the domain model ( custom fields for instance ) as relational data by actually creating the field, right now I'm using an approach ala EAV for storing custom fields and things of that nature where a specific tenant needs to be able to configure the domain model
Typing this response has also made me think about the choices I made and why I made them, I think I also picked the shared schema approach because it felt more OOP to me, by that I mean it encapsulates the database, the schemas are not "generated" ( and thus all the disadvantages you get with code generation for instance, like schemas becoming out of sync with each other ).. and no domain code is ever coupled to a client customized schema, overall turnaround time for custom features has slowed which has left a lot of clients grumpy since I'm still in my startup stages, but in the long run I believe this type of approach would pay off, and very well ( 10,000 dog grooming sites at 10,000 dog biscuits per month will bring me 100,000,000 dog biscuits per month
)
( things can be identified by their `id` field, if Tenant A adds a product it gets assigned product ID 1, if Tenant B adds a product it gets assigned product ID 2.. this would all be internally handled by the DBMS. Extenerally to the data the model would interact with the end user allowing them to generate their own pseudo primary key that would be enforced by the application not the database, for instance in essence a unique key has to take into account the tenant_id scope, as such unique constraints at the DBMS level become useless, Tenant A creating a product with a sku of '123' should not stop Tenant B from creating a product with the same SKU, but should be enforced within the scope of all of Tenant A's tenant accounts )
I do however like the idea of having a database for each tenent, for the security reasons discussed in the article. Once I have my system completed I might refactor to that approach. The disadvantage however is additional overhead incurred in provisioning new tenets
I've also been considering storing tenant specific metadata in it's own database from the main application, storing extensions to the domain model ( custom fields for instance ) as relational data by actually creating the field, right now I'm using an approach ala EAV for storing custom fields and things of that nature where a specific tenant needs to be able to configure the domain model
Typing this response has also made me think about the choices I made and why I made them, I think I also picked the shared schema approach because it felt more OOP to me, by that I mean it encapsulates the database, the schemas are not "generated" ( and thus all the disadvantages you get with code generation for instance, like schemas becoming out of sync with each other ).. and no domain code is ever coupled to a client customized schema, overall turnaround time for custom features has slowed which has left a lot of clients grumpy since I'm still in my startup stages, but in the long run I believe this type of approach would pay off, and very well ( 10,000 dog grooming sites at 10,000 dog biscuits per month will bring me 100,000,000 dog biscuits per month
Re: multiple sites / same codebase
Great link, thank you! I added to my delicious.Selkirk wrote:If you are offering this as a service, what you are talking about is called "multi-tenant." You may find Multi-Tentant Data Architectures a helpful overview on the DB side.
ls.