> 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@xxxxxxxxxxxxxxxx, http://ScienceTools.com/
