What's the difference between these multi-site setups in Drupal 6?

Question

I am migrating several Drupal 6 sites to a new host. I recall the installer automatically set up my multi-site tables with just a few settings in the installer. I couldn't find these settings while I am making this migration and discovered description of multi-site configuration.

My original multi-site is of this type: Example one (this page explains a multi-site using $db_prefix property in a site's settings.php file).

During this file migration I found this type: Example two (this page explains manually crating a database table [database_name]_shared_tables).

---

As I said, my four sites were setup as with version one above. As I work to restore these sites from the mysql dump files, I'm wondering which process will be faster? My sites work like this,

+ default.domain (main drupal app)
|- sub1.domain (separate data)
|- sub2.domain (separate data)
|- sub3.domain (separate data)

Some of the information about multi-sites is outdated. This page suggests there are tables which can not be shared. Yet my settings.php file did not have a detailed list of shared tables, and instead had a simple prefix value, and leads me to believe the first example resolves what to share for you.

Answer 1

I once wanted to do multisites but it became so difficult to share data without sharing ALL of the data that I stopped. I wanted to share forum content, but not page content which is impossible. It is all nodes or on nodes.

The biggest problem with doing the $db_prefix method is everything is done in your settings.php file. I shared the variables table which shared every module setting. This method then included overriding all every variable you care about. For me if was a different google analytics code. Since this is stored in the db and I was sharing the variables table, the analytics ID was shared.

The most important table to keep up-to-date is the sequences table (auto-number table for databases that do not auto number easily) that stores the next user id to be used. If you share users, you have to have that table in lock step with the rest. It is easily edited to change the users_uid value to be the next user id in the system.

So my answer will be another question. What do you want to be shared. Users? Roles? Taxonomy? Nodes? The more you share, the more tables have to be shared and the more overhead it is.

As a side note, the documentation is very outdated. I only recommend doing this on a dev and not production copy of your database and make sure you have a backup of a working settings.php and a full backup of the drupal database. This will help to roll back and keep your site running in the event something goes wrong.

In the settings.php I have the same $db_url as all of the sites. The exception is the below items.

$conf = array(
  'site_name' => 'My Site Name',
  'theme_default' => 'my-=sub-theme',
  'site_slogan' => 'My site slogan',
  'site_frontpage' => 'my_site_view',
  'smtp_fromname' => 'SMTP Settings From',
  'site_footer' => 'Site Footer',
  'googleanalytics_account' => 'UA-112233-1',
);

Any variable inside the variables table can be set in $conf. This helps my having a different theme on my sub domain site as well as a different frontpage view. I setup a taxonomy that puts the content into the view and then out to the frontpage. I took the example frontpage view included in views and cloned it and edited it to my needs. This was a quick and dirty solution to share the nodes but keep the frontpage content separate and track each site with its own google analytics. It works but I know there are shortcomings. The major one being that content can still be searched for on both sites that does not technically belong there.

Answer 2

I would have closed this question, but there might be some other bone head who misses both examples use the $db_prefix parameter in settings.php

(>_<)