> On 01/30/07 14:41, Tony Caduto wrote:
> > Mark Walker wrote:
> >> It's sort of a matter of taste, but there are lots of people who like
> >> to keep there logic on the server or at least within sql statements,
> >> so there's probably a good sized market that your not reaching if you
> >> ignore it.
> >>
> > That is a good point, I and many developers I know like to keep all the
> > business logic on the server in stored procedure and functions and
> > having this ability as a native part of Postgresql would be a huge
> > advantage.
> > DBlink is a decent workaround,but it becomes a pain having to wrap
> > everything with the dblink syntax, plus there is a little bit of
> > overhead involved creating a connection over TCP/IP to run a query on
> > the same server. DBlink is great when you need to connect to a
> > different server though.
"Business logic on the server" - heh. If you want to know where all such
ideas came from, think cynically.
...Originally, back in the day, the goal of creating "stored procedures",
in particular, and aiding and abeting features like "triggers", had
nothing to do with performance or clean architectures, rather the DBMS
vendors figured this was a good way to trap customers into only being able
to use their database engine. The more DBMS-engine-unique features a
customer used the more expensive it would be for them to switch to another
DBMS engine. The lack of standards regarding such "business logic" is
precisely because the vendors didn't want portability.
'Course, in a mature market (like the RDBMS) this mostly benefits the
largest vendors as gaining market share requires customers to convert. And
so today we have companies like ANTs Software absorbing the costs of
porting such features to their ANTs Data Server - last I heard they'd do
the conversion for free.
These days with good open source choices, things are a bit different, but
that doesn't mean it's always good to go hog wild with any particular tool
set just because you can. Sometimes people over-use engine-side features,
forgetting that there are nearly always more cycles available on clients
than servers...
Richard
--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy@ScienceTools.com, http://ScienceTools.com/
