Re: Wishing trolls away
Date: Fri, 14 May 2004 16:13:06 +0300
Message-ID: <40a4c569$1_at_post.usenet.com>
- Post for FREE via your newsreader at post.usenet.com ****
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c82fed$857$1_at_news.netins.net...
> "Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message
> news:e9d83568.0405131054.5eb17b4c_at_posting.google.com...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:<c7vune$nm8$1_at_news.netins.net>...
> > > "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...
> <snip>
> > So what do you think the "magic formula" of Pick is when comparing
> > to SQL? Is it one spesific feature, or is it a set of features?
> > To put it another way, what should be added to SQL to give it
> > the same advantages?
>
> I really don't know and that is my search right now. It is also
conceivable
> that it is only my perception (and that of others) that there are
> significant advantages to using non-SQL-based databases such as PICK and
> perhaps there is an experiment that could convince me otherwise. I'm
still
> digging, reading, thinking, testing and walking around this question from
> all angles I can find.
>> > > > build large enterprise scale applications without using an SQL-DMBS?
> > > > Apart from the problems with integration, would it even possible to
> > > > 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.
> >
> > Can you give an example? Again, what were the features in the Pick
> > environment that differentiated it from the SQL environment? What
> > should be added to SQL so that it would be on par with Pick?
>
> I suspect that having a vocabulary with which to work and then a separate
> vocabulary for each "entity" so that the end-user doesn't have such
complex
> queries once the data dictionaries have been prepared for them. Each user
> might see all of the data they would need for their job through a small
set
> of entities, with a dictionary for each (that is NOT just the "base" or
> stored fields related to that entity). There is work to set up dictionary
> items which are derived data (virtual fields, UDFs, or however you want to
> describe them). The user really does think of fields like GPA being
> associated with a STUDENT even if there is considerable code behind the
GPA
> virtual field.
>
> Also, there is often a two pass approach to queries that makes complete
> sense to the users. After all students are registered, for example, they
> might save a list of the record IDs (every file is a function mapping
record
> ID to other values) of all registered students and then from that point on
> in the semester always run reports only on those selected records. So,
> again where they might otherwise have some complexity in selecting only a
> subset of students, the do that once and then execute easy queries on that
> set -- for example
>
> GET-LIST REGISTERED_STUDENTS
> LIST STUDENTS GPA
>
> This is similar to working with views, but both conceptually and from a
> performance perspective, it really is different and users like it better,
> from my experience. Please recognize that I started out by doing
everything
> I could to make SQL more attractive to them. I couldn't imagine that a
> 40-year old non-industry-standard language would outshine the industry
> standard. But it beat me and so now I'm trying to figure out why.
How about a FORTH like language as a host language for Relational Algebra ?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=