RE: Can I SQL-query data from 2 servers at the same time?

Joe,

You're preaching to the choir here.

However, the fact remains most enterprises out there are currently 
heterogeneous and spread across multiple servers.  It doesn't matter at this 
point if the heterogeneous nature is due to poor planning, bad planning, or no 
planning.  That is the current state that we have to deal with.

We can work on improving the situation.  But management looks at the iSeries 
and sees a box that can't talk to anybody...including another iSeries!  Whereas 
Oracle and SQL Server can talk to anybody.

Sure it wouldn't matter if you could do a one-time mass consolidation of 
everything onto the iSeries.  But just how often does that happen?  On the 
other hand, if you want to incrementally consolidate; then you have to choose a 
platform other than the iSeries in order to keep talking (directly) to the rest 
of your environment.

The fact that the iSeries can't even do a join between another iSeries really 
bothers me.  I think it shows a very real limitation of DB2 for iSeries when 
compared to any other RDBMS including DB2 LUW!  Why doesn't my preferred 
platform support the "higher level of DRDA" that DB2 LUW does?

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Pluta
> Sent: Monday, June 06, 2005 11:44 PM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: Can I SQL-query data from 2 servers at the same time?
> 
> 
> > From: Wilt, Charles
> > 
> > It's no wonder people are moving data off the iSeries.  It just so
> dang
> > easy to pull the data off to another platform; whereas is impossible
> to
> > pull data back to the iSeries without big bucks.
> 
> I suppose if you're in an environment with loosely decentralized data
> that makes sense.  However, loosely decentralized environment are the
> most error prone and the least reliable of all systems, 
> primarily due to
> the existence of multiple error points for each transaction.
> 
> In fact, this is the primary reason we are beginning to see a 
> corporate
> move towards re-centralizing their data.  And if you were 
> going to store
> your data on a single machine and your requirements were things like
> robustness, reliability, accessibility, ease of use, range of 
> tools, and
> TCO, all of these point directly at the iSeries.
> 
> So, sure, in shops where the data is strewn about multiple 
> servers with
> little thought about architecture or design, then some sort of magical
> SQL engine that accesses all the machines is a nicety; in fact, it's a
> necessity borne of a horrible deployment model.  I've always said that
> tools can mask all sorts of architectural deficiencies, and SQL is one
> of the best.  In fact, I should copyright that idea: SQL, the 
> Spackle of
> Application Design!  The problem with spackle is that it 
> doesn't address
> the underlying problems, and in this case the underlying problem is
> simple: if any of the machines goes down, the entire application is
> fried.  Simple, and simply a bad idea.
> 
> On the other hand, if this were the kind of shop that was looking to
> re-engineer its IT model to a robust, forward-looking architecture
> capable of handling large volume SOA in a highly available multiple UI
> environment, then the iSeries is the direction to go.
> 
> Joe
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>