Dear Tom -
(Please bear with me for a philosophical prolog.)
Tom Beidler writes:
> I'm running into more and more clients that would like to connect to
> another database. Say there inventory tracking software. I was
> wondering if there was a good book out there or a web site that
> might have some info that I can use to start thinking about
> strategies of connecting other dbs.
PROLOG (See RESPONSE to escape ranting)
This question highlights what seems to me to be a consistant theme
throughout the list that I don't understand. The DBAs I've worked
with in my career tell me that you should always err on the side of
excessively methodical. That is, don't enter commands interactively
but instead put your SQL in a script and run the script against a test
database and only execute it against the production system when you've
got it perfect. This ensures that your database machinations are
reliably repeatable.
Many of the questions on the list sound to me like "How do I write a
set of SQL commands that will confirm the validity of a credit card
number?" My confusion is, why on earth would you want to? If you're
already using a scripting language (at least sometimes) to wrap your
SQL then why don't you let it handle these sorts of problems. SQL and
the DBMS are absolutely superior at handling a FEW very specific
problems (i.e. sorting, writing, fetching). SQL is horrible at
everything else.
So, back to Tom's original question. Interfacing with other databases
potentially in other DBMSs or maybe even data that isn't in a database
is not really a database task. It's a programming task. The question
that I would want answered is "I want to merge multiple data sources
what tool will allow me to do that with all the different types of
data I'm interested in?"
RESPONSE
The answers vary, of course, depending on what the data sources are
but you should investigate what is referred to as "ETL" (Extract,
Transform, Load). There is an extensive literature around this topic
in the data warehousing realm.
I'll plug my own preferences and suggest that you solve your problem
with scripts written in perl. Perl has available with it a database
abstraction mechanism called DBI/DBD that will allow you to access
multiple databases in different DBMSs (and here's the kicker) without
having to write code that is idiosyncratic to the DBMS. That is, the
DBI abstraction allows you to write data sorting, writing, fetching
logic (see philosophical ranting above) that is independent of the
DBMS which is used to maintain the data.
Alligator Descartes & Tim Bunce, "Programming the Perl DBI" (O'Reilly,
2000), ISBN 1-56592-699-4
Yours - Billy
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
