× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



From: richard@xxxxxxxxxxx

This allows your .Net or Java layers to remain very thin and mainly
related to UI work as you mentioned. I just prefer sprocs over the data
queue method because you can plumb directly to the program calls via the
database connection instead of using data queues.

Yeah, this is the part of the argument that's really weird to me.  You seem
to imply that data queues are somehow inferior to database connections, and
that they're more complex whereas it's really just the opposite.  I prefer
data queues over stored procedures because they're native to the operating
system and I don't have the unnecessary overhead and irrelevant syntax of
the database connection.  All modern architectures (everything from OO
languages to communications protocols to Web Services) use messages, and the
fastest and simplest method for sending messages is a queue.

Using a database connection to call a program is just wrapping an extra
layer of complexity around a very basic feature, and doesn't make a lot of
sense to me.  I suppose it could be helpful to someone who is only
comfortable with database connections because that's all they've ever used;
I could see where a stored procedure might make sense to someone coming from
a pure ODBC background. 

But I've spent my entire career designing multi-tiered systems, and I
understand how they work at the lowest level.  Over the years I've probably
used every protocol imaginable to get one machine to talk to another.  And
as it became clear that result sets weren't going to work as a way to
communicate between tiers, I've watched the attempt to graft what are in
effect remote procedure calls into SQL.  It hasn't been particularly pretty
(the old horse butt bag concept).  Me, I've never liked shoehorning a
communications protocol inside ODBC syntax, especially the part where you
code the user ID and password in the clear, or get it out of a text file.

Anyway, I'm still a proponent of KISS, and unless I need result sets I don't
need a database connection.  Instead I'll stick with queues; they've been
the communications technique of choice for 45 years or so, and they seem to
be doing fine.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.