[development] External database handling

[David Metzler]

When  writing integration modules that are connecting to external  
data sources in non-supported drupal db languages (MSSQL, orcale,  
etc) , I have generally used a separate database abstraction layer,  
such as ADODB or PEARDB.

Or better yet, implement an xmlrpc or restxml layer between your app  
and the external database, so that the External DB doesn't even need  
to be hosted on the same box as the drupal code tree.

I wouldn't call these anointed best practices, but it certainly is  
the approach that has kept the integration code the cleanest for me.

Dave
On Aug 21, 2008, at 8:21 PM, Chris Johnson wrote:

> Is it generally desirable that contributed modules use the Drupal
> database abstraction whenever possible when accessing external
> databases?  That is, is it generally preferable to use db_query() and
> friends, instead of mysql_connect(), mysql_query(), etc. whenever
> possible?
>
> I personally think so at the moment, but would certainly like to hear
> any arguments to the contrary.  An argument that it doesn't really
> matter is an argument against generally using Drupal's DB layer.
>
> If one agrees it is generally better to use the Drupal DB layer, there
> is a significant problem to doing so.  The code which supports
> multiple databases (of which I admit to being partially the author),
> such as db_set_active(), requires the additional databases to be
> listed in an array version of the global $db_url variable (up to and
> including Drupal 6) and $databases (Drupal 7).  This array is set in
> the settings.php file.
>
> When using the Drupal 6 installer, this file can be written for the
> user doing the install.  One can assume that most installations will
> thus likely not involve someone hand editing that file.  Yet, except
> for some ugly kludges involving overwriting the $db_url or $databases
> variable (a scalar by default) with an array form including the extra
> external database(s), the only way to add an external database is to
> hand edit that file.
>
> If one wants to write a contrib module which has all the ease of
> installation which D6 and D7 core have, and which uses an external
> database, one is rather stuck.  One can either (1) kludge up the
> $db_url or $databases variable by overwriting it, (2) require the user
> to expertly hand-edit the settings.php file or (3) not use the Drupal
> DB abstraction layer.
>
> Or so it seems.  The contrib modules I've looked at so far mostly
> resort to #3, not using the DB abstraction.
>
> I'd especially like to chat with the folks working on the DB layer for
> D7.  It would be nice to provide an interface to allow adding an
> additional DB programmatically from the contrib module.
>
> ..chris