Multiple sites single database - worth the hassle??

Monday 09 February 2004 11:57:12 pm

I'm aware that eZ Publish is capable of serving multiple web sites with a single database. I want to do this as I have a number of sites that will be using the same content classes. These sties are separate is all other aspects.

I've come up with the following pros and cons list for single database Vs a database per site.

Pros
+ only create content classes and related permissions once
+ easy setup for new sites
+ when new content types are created they are automatically available on all sites

Cons
+ risk of content "spilling" onto wrong site due to issue with poorly configured permissions.
+ difficult (impossible?) to backup single site content
+ database table size will grow as amount of content/sites increase

Can anyone shed further light on these issue?

Thanks
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

Tuesday 10 February 2004 3:44:22 am

Hi,

I hardly can imagine any advantage in using the same database for more than one site (note: I'm talking about a site not a siteaccess )

I don't see reusing content classes as pros, you can use the import/export package functionality to do this professionally

For us, a website development company, it comes naturally that one dynamic site should use its own and unique database, imagine a corrupt database scenario, if we were sharing the same tables for three clients, chances are that table corruption is originated by operations in one site, but as a result you could end we three affected clients

Nevertheless, I would like to hear of more PROS for using the same database

Lazaro
http://www.mzbusiness.com

Tuesday 10 February 2004 7:01:00 am

The acoounts could have been synced to an LDAP server, so the last argument kinda falls apart. But still - this is a taste & style issue. How to do it "right" is a bit difficult to say without knowing more about the problem domain. However, running too many different sites within one database is a bit risky.. I agree with Lazaro.. :-)

Balazs

Wednesday 11 February 2004 12:33:49 am

Hi,

we are currently developing "multi-sites in one db" and I want to share my experience.

The sites contains different content (a comedy web-site, an internet-magazine, a "corporate web-site" etc.). At the end, around 10 different sites are using one db.

The main reasons:
-) Saving marketing costs for the site owners. Or in other words: Sharing of user accounts. (It's hard and expensive to get new, registered users and it's a big benefit, if a user only needs to register once to get access to e.g. 10 sites.)

So you can also share the marketing costs between the site owners. (e.g.: A new user comes to site A. At site A you give the possibility to get the newsletter of site B. Or to sell products of site C. At site C you also give the possibility to subscribte the newsletter of site A etc.)

-) Sharing of content increases the visits of all sites. All sites have e.g. a "search" feature. If a user don't find what he is searching for at one site, maybe another site could provide the information.
You can also share the "forum" or the "shop" (and so on).

The big disadvantages:
-) Performance. (Currently, our ez db has the size of 300 MB. Before we used ez 3, the ez 2 installations only need around 40 MB all in all.) If you save content, you need patience. If the cache is empty, too. At the moment you need a very strong server if you plan to use ez3 for "big sites". (Big = many users (over 10.000 users) and much content (over 30.000 articles / content objects))

-) ez 3 don't support "multi sites / domains in one db" fully. So, it's impossible to assign content to one domain without doing some extra programming. Example: If you do a search at site A and the search result contains content of site B, it's hard to get the "domain B" in the link of the result and the information, that the content is from site B. Same thing with "related content objects" / keyword feature.

Moreover, the cron-jobs don't support "multi-sites in one db" at the moment.
Example: Notification system: If new content is published at site A, I want to send the the notification e-mail with header and footer of site A. If content is published at site B, the header / footer of site B should be provided.

Another small flaw:
Content of site A is also "reachable" at site B. Or in another words:
http://www.site-a.com/content/view/full/123 and
http://www.site-b.com/content/view/full/123
shows the same content.

You can't prevent this without doing some extra programming.

This isn't a problem, if a user don't know this. But - maybe - there could happen some "law problems".

Example: The content object (article / forum post etc.) with the id 123 contains something which disturbs somebody. And Mr. Somebody is able to sue all domain owners if he knows that the content object is reachable at each domain which uses the same db.

Why Mr. Somebody should know about the other domains? Because he uses a popular search engine like google.

There are many other (small) things to mention and I am sure there are many pro's and con's at all.

My conclusion is: Only use "multiple sites in one db" if you are able to adjust ez3 at a "deeper level" and if all "site / domain owners" have the knowledge of all possible advantages and disadvantages. (Otherwise you can run into some big troubles. And always remember Mister Murphy's law! ;-)

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Tuesday 24 February 2004 9:42:09 pm

An advantage to eZ's internal search is that results shown depend on the user's permissions. An external search index would not work well on a site with varied levels of access.