Re: Wishing trolls away

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news:e9d83568.0405122002.1d4676a_at_posting.google.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:<c7rio3$vd0$1_at_news.netins.net>...
> > "Leandro Guimarães Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm>
wrote
> > in message news:pan.2004.05.11.21.37.13.680915_at_dutra.fastmail.fm...
> > > I am sorely disappointed, the group has reverted to a trolling
> > > field by sellers of sad OO, MV, XML, whatever snake oil who have no
> > > interest in learning anything sane.
> > >
> > > I guess there comes a point where only *moderated* mailing
> > > lists can bear intelligent conversation.
> >
> > Sorry to disappoint, if I am among your targets for this posting. I am
> > truely, honestly, searching for why my book-knowledge and experience are
so
> > out of alignment in the area of databases, so I am guilty of bringing
> > experience into the mix.
>
> I think the key question here is how well the DB and programming
> environment are integrated, and in most cases the integration of
> SQL-products and typically used programming languages is not very
> good. It means that you have to somehow bridge the gap between two
> environments and maybe even have separate persons working on the
> different tiers, with more need for communication, training etc.

Yes, I think you are right that the integrated environment is one aspect of the reason, but I have used Java with an MV database and it provides most of the same advantages that way.

> Integrated environments have always been popular, witness the success
> of MS/Access. I think also products such as Progress have a loyal
> following (not to mention Pick and MV!). And also the fact that
> OO-people have spent lot's of effort on trying to "persist" their
> objects in an OODBMS, instead of having to save them in a normalised
> SQL-database, speaks for the desire of an integrated environment.

Agreed.

> Taking the position that the RM as a datamodel (or data meta-model) is
> desirable, what are the alternatives?
>
> - use SQL-DBMSes inspite of missing integration
> - use products where integrated environment is built ontop of
> SQL-DBMS
> for an example see
>
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246510.html?Open
> - use products built from scratch that integrate RM and application
> development envoronment, such as Dataphor
>
> Apart from the problems with integration, would it even possible to
> build large enterprise scale applications without using an SQL-DMBS?
> Would it be possible to, say, write the applications that run Amazon,
> eBay or FedEx using PICK?

Absolutely! You might even be amazed at the names on the list of PICK customers, with tens of thousands of end-users for single applications, huge volumes of data, etc. When I asked pickies where they hit limits, they provided limits they hit while building up large apps along with the methods for how they solved any such issues. For example, you would not want terabytes of data within a single logical PICK file even on the fastest hardware.

> And on the reporting side, I think products such as Business Objects
> and Cognos Impromptu provide excellent (integrated) capabilities and
> that is where the RM (and even SQL!) really shine.

That is what I used to think (and speak on). Then I had and saw teams of software developers working to make companies productive with SQL-based tools on SQL-DBMS's and the MV query language on MV databases. There really is no comparison from an "end-user" standpoint. And when trying to make companies that had been using MV query languages now happy or even satisfied with SQL-based products, it was pretty much impossible. It is my adventure with reporting tools and query languages that led me to believe that PICK had something that was both invisible to the industry and superior in many respects to what folks were doing (SQL). XML and XQuery capture some of that, but lack the end-end-user language as yet (leaving that for vendors to figure out in a proprietary GUI).

--dawn Received on Thu May 13 2004 - 15:54:48 CEST