Shared database technique in general

public
group: Multisite
HansBKK@drupal.org - Fri, 2008-05-30 03:17

After investing a lot of time trying to figure out how to do multi-site via a shared database, I've come to the following (personal opinion) conclusion.

Just Say No

Reasons:

  • it's complex, difficult and dangerous
  • Drupal' lack of canonical schema documentation
  • problems with new module installs
  • problems with upgrades

Exceptions:

If you are already a Drupal AND a database wizard (I'm neither)

Playing around in a development environment, e.g. my current use case: in figuring out theming development, I'm installing then removing different themes, switching back and forth between them messes up my blocks, so I've got a multi-site sandbox set up sharing everything except system/layout/navigation tables. See http://groups.drupal.org/node/11795

For a production site and a relative newbie, sharing only the user-related tables seems relatively common, and in fact the v5 settings.php gives a (presumably safe) example.

Note this is just my opinion, so hopefully some more knowledgeable people will comment, either to confirm or to post known-good scenarios and sample settings.php.

I hope this will save others from wasting as much time as I have. Actually, gaining knowledge is never a waste of time, I certainly know more about the database schema than I did before, but I sure which it was properly documented in the first place!

Other techniques

HansBKK@drupal.org - Fri, 2008-05-30 03:25

I can't advise on details for these, but thought I'd at least mention some alternative techniques I've come across for others who want to research alternative ways of creating a network of affiliated sites with shared content - there are some very interesting threads out there!

Sharing EVERYTHING should be OK, and you can override variable settings with the settings.php. Apparently content can then be segmented via taxonomy term selection in site-specific php/mysql code.

Domain Access's shared table options are presumably tested and supported

MySQL Views (requires v5+)

For users - integrating outside authentication via LDAP, OpenID etc, or the Drupal-only multi-site authentication modules

Comments welcome on the I'm sure many I've missed. . .

Note

agentrickard@drupal.org's picture
agentrickard@dr... - Thu, 2008-06-05 18:04

Re: "Domain Access's shared table options are presumably tested and supported"

Domain Prefix comes with the Domain Access module, and its features work as documented. However, it does not give you any guidance about which tables to prefix, when, or why.

It can be a good way to test how table prefixing might affect your site, though, especially since it has a UI for creating, copying and dropping prefixed tables.

--
http://ken.therickards.com/


guidance about which tables to prefix, when, or why

HansBKK@drupal.org - Fri, 2008-06-06 09:04

Too bad, I was hoping it would limit the user to known safe combinations of shared vs site-specific.

Thanks for clarifying though. Sounds like DA will help in setting up / testing /fixing process, so hopefully as others find "known good" combinations they will post their settings.php examples here.

The fundamental problem - lack of available documentation by Those Who Already Know (not just on sharing tables but on the D5 database schema in general) remains, and reinforces my "Just Say No" conclusion above.

Right

agentrickard@drupal.org's picture
agentrickard@dr... - Sun, 2008-06-08 19:17

I actually wrote Domain Prefix for a specific use-case, and did not want to dictate "safe" combinations. For instance, I am fairly sure that prefixing the {system} table will do major harm to your site under DA.

There is, however, a very good feature request here: http://drupal.org/node/239243 that addresses your issue.

--
http://ken.therickards.com/


Now wouldn't it just be

sdboyer - Mon, 2008-06-09 05:43

Now wouldn't it just be fantastic if I had time to GET to that oh-so-well-intentioned-proposal...