Re: Wishing trolls away
Date: Fri, 14 May 2004 07:52:14 -0500
Message-ID: <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.
> > > 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 Cognos Impromptu provide excellent (integrated) capabilities and
> > > And on the reporting side, I think products such as Business Objects
> > > 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.
--dawn Received on Fri May 14 2004 - 14:52:14 CEST