Unidata vs Oracle??
James Tarin
----------------------------------------------------------
As a marketing manager rather than an IT specialist I am looking for some
impartial advice on the selection of large relational databases.
My organisation (a large UK Charity) currently runs an Oracle based system
on a UNIX machine. We have approximately 700,000 individual supporter
records, with many millions of associated financial transactions. A
potential new supplier is offering a software package that runs on a
Unidata Database.
Can anyone give me some idea on,
1. The strengths and weaknesses of Unidata.
2. How does it compare to Oracle in terms of performance and functionality.
3. Which of the two systems are technically superior and why
4. What are the main criteria that we should judge the two databases
5. What would you buy and why?
6. Are there any Unidata problems that we should be aware of?
7. Can Unidata be used with Cognos Impromptu V3 and Cognos Plowerplay V4.1
Any help would be really appreciated.
Many thanks
James Tarin
Jeff Schasny
ja...@chilcott.demon.co.uk (James Tarin) writes:
>Comparison between Leading Databases (Oracle and Unidata)
>----------------------------------------------------------
>As a marketing manager rather than an IT specialist I am looking for some
>impartial advice on the selection of large relational databases.
Why is a marketing manager making I.S. decisions? Hmmmm... Oh well, just
a favorite rant of mine.
[currrent system (oracle/unix) description snipped]
>Can anyone give me some idea on,
>1. The strengths and weaknesses of Unidata.
On the same hardware platform, it will run more efficiently than Oracle,
support more users, allow faster development, require less maintenance,
reduce staffing requirements, and allow for more flexible ad-hoc reporting.
>2. How does it compare to Oracle in terms of performance and functionality.
see above
>3. Which of the two systems are technically superior and why
Well, since you're a marketing guy, I'm not going to get into a long winded
discussion of the relative merits of relational vs the Pick/NF2 model. But
suffice to say that "Father" of the relational model (E.F.Codd) has recently
said that the relational model is less efficient than the NF2 model for
use with "real world data"
>4. What are the main criteria that we should judge the two databases
Ohh... how about "what does this buy me?" and "how does it affect my bottom
line over a 5 year period?"
>5. What would you buy and why?
Actualy I'd buy Universe :) but hey, it's just my opinion.
>6. Are there any Unidata problems that we should be aware of?
No significant ones, especialy if you are used to the level of buggyness
inherent in Oracle.
>7. Can Unidata be used with Cognos Impromptu V3 and Cognos Plowerplay V4.1
Uhhh... Nope..but then, you wont need those anymore with Unidata.
regards,
Jeff
===================================================
Jeff Schasny | DoD# 1735
jsc...@rmii.com | http://rainbow.rmii.com/~jschas
===================================================
Jackie Burhans
: In article <james-04099...@chilcott.demon.co.uk>
: ja...@chilcott.demon.co.uk (James Tarin) writes:
: >Comparison between Leading Databases (Oracle and Unidata)
: >----------------------------------------------------------
: >7. Can Unidata be used with Cognos Impromptu V3 and Cognos Plowerplay V4.1
: Uhhh... Nope..but then, you wont need those anymore with Unidata.
Uhhh.. Yep. At least Cognos Impromptu V3 we have and have tested. Connects
good fine via UniDesktop/ODBC. Mayhaps Plowerplay (excellent name!) will
work that way too.
It seems though that Impromptu is sensitive to _ in your view names so you
may want to avoid that.
: Jeff
Paul Beardsell
> In article <james-04099...@chilcott.demon.co.uk>
> ja...@chilcott.demon.co.uk (James Tarin) writes:
>
> >Comparison between Leading Databases (Oracle and Unidata)
> >----------------------------------------------------------
Firstly, if the definition of "Leading" is "known by most" or
"respected by all" then Unidata does not deserve that description.
Oracle is to database management systems as Hoover is to vacuum
cleaner. And even Jeff prefers UniVerse to Unidata.
> >As a marketing manager rather than an IT specialist I am looking for some
> >impartial advice on the selection of large relational databases.
A database is either relational or it is not. Is Post Relational
relational? What are the attributes of a good database? A good
database satisfies all the ACID properties. Unidata does not.
What are the ACID properties? Briefly they are properties which
simplify the development of, improve the reliability of, ensure the
consistency of and improve the concurrency of database applications.
ACID=Atomicity+Consistency+Isolation+Durability
* Atomicity: All changes made in a database transaction are either
all applied (committed) or none of them are applied. Not so in Pick.
* Consistency: A programmer may ensure application consistency by placing
together in one database transaction all the updates/inserts which
logically fit together. [Arguably limited support is provided for this
by some Pick databases.]
* Isolation: Database changes are invisible to other users until committed.
* Durability: Once database changes are committed then they are
GUARANTEED to be on the disk. And can be safely backed up.
What are the consequences of the lack of support of ACID by Pick?
* Oracle can be backed up in a application _consistent_ state while it
being used and while being updated. Not so Pick. In Pick restoring
a database so backed up will restore broken files and incomplete
transactions. A Pick database must be taken offline to be backed up.
Your question is re large databases. One of my UniVerse customers has
a six hour downtime every night just to get the data on to tape. And
every other weekend the files are resized to maintain performance.
Neither procedure is required for Oracle.
* In a Pick environment a power failure will often leave the database
in a broken state (GFE or equivalent). Not so with Oracle. In five
years I have NEVER (literally) experienced the Oracle equivalent of
a Pick GFE. In Pick the GFE is known by name to even the user
community!
* Oracle automatically rolls back uncommitted transactions upon failure
of a program. Upon the rare (i.e. "never" happens) Oracle failure
uncommitted transactions are automatically rolled back upon the
database being brought back up. Same for O/S, machine or power failure.
Pick does none of that except it fails more often!
* If at any time the app or o/s or machine or power fails before a
transaction is finally committed then all the data remains unchanged.
E.g. If an application (say, a banking money transfer program) fails then
one must make sure that every debited amount has been credited and
vice versa. In Oracle one simply puts each maching DR and CR in one
database transaction. How does one ensure this with Pick? You call
in the support programmer to check.
* While the above application is running a customer phones in and asks
for the balances of his accounts. An enquiry is run. The answer is:
"In account A $1000 dollars and in account B $500." But the customer
knows that he has $2000! What has gone wrong? The above application
is busy transferring money from account A to account B. The application
is written in Pick! If the application were written in Oracle the
debit would not be visible until it had been committed ATOMICALLY with
its corresponding credit. (Atomicity! Consistency!) Not even locking
the records helps in Pick - a record is only locked against WRITE - you
can still read the effects of a transaction before it is complete.
Note that in Oracle no locking would be specified by the Programmer -
the database would do it all. But the "before image" would never be
locked! What does that give you? CONCURRENCY!
* A program hits an error condition (e.g. overdrawn balance) that means
the updates performed so far must be undone. In Oracle you simply
ROLLBACK. No other user has seen the bad updates (Isolation!)
and the data is left unchanged. What do you do in Pick or Unidata?
> Why is a marketing manager making I.S. decisions? Hmmmm... Oh well, just
> a favorite rant of mine.
He is looking for advice. More power to his elbow, say I. Pity
you will not provide the _impartial_ advice he is looking for.
Worse than that: Misinformation is what you supply.
> [currrent system (oracle/unix) description snipped]
>
> >Can anyone give me some idea on,
>
> >1. The strengths and weaknesses of Unidata.
>
> On the same hardware platform, it will run more efficiently than Oracle,
> support more users, allow faster development, require less maintenance,
> reduce staffing requirements, and allow for more flexible ad-hoc reporting.
I will concede that Oracle requires more memory than Unidata. But
so what? Memory is cheap. The runtime performance claim is not
backed up by any figures or benchmarks. I wrote applications for
seven years using Pick R83, Ultimate and UniVerse. Now I write
Oracle applications and BELIEVE ME they FLY!
Pick traditionally only supported quick access to a record if you
knew the key to the record . In Oracle any column can be used for
access. And any column can be indexed. Unidata might have secondary
indexes but they better work better than UniVerse's. Unidata indexes
are not used automatically by applifcation programs. In Oracle
any access uses the best available index. In Oracle indexes can
be removed or added at will (and while the database is running and
being updated) WITHOUT changing any form, report or program and all
Oracle apps will use the new index if it provides a better path to the
data.
Pick can perform better than Oracle in certain restricted queries.
But for flexible ad-hoc reporting a PROPER relational database will
ALWAYS beat a record-based keyed database like Pick.
Pick provides faster development? Pah! Why are there no Pick
entrants in the rapid development contest currently being advertised
in this and the other database newsgroups? The tools provided by
Oracle (Forms, Reports, Graphics, Browser) are perhaps not the best
available but they're a damn site nicer and easier than anything
available for Pick. System Builder? Visual Basic and Hyperstar?
All of those are pretty appalling!
Gone are the days when Pick provided the best devt environment. In 1986
Pick (in combination with Systemn Builder) won all the devt competitions.
It is now 1996 and things have moved on (unless you a Luddite Pickie).
Pick is literally anochronistic. It was the best. It is no longer
the best.
> >2. How does it compare to Oracle in terms of performance and functionality.
>
> see above
Yes. See above!
> >3. Which of the two systems are technically superior and why
>
> Well, since you're a marketing guy, I'm not going to get into a long winded
> discussion of the relative merits of relational vs the Pick/NF2 model. But
> suffice to say that "Father" of the relational model (E.F.Codd) has recently
> said that the relational model is less efficient than the NF2 model for
> use with "real world data"
The Pick community call their database model Post Relational.
If anything it is a pre-relational database. They harp on about
the advantages of their data model (which they term NF2) based on one
small quote by Codd. But then they never do actually provide the
quote but paraphrase it - and every time I see yet another
iteration of the paraphrase it becomes more outlandish.
Most of the things said by Codd, a pioneer of relational databases,
about databases do not show Pick-like databases in a good light.
One should not be surprised that Codd has said _one_ thing
that can be paraphrased in such a way to make Pick look good:
Codd says lots of things!
"Real world data"? What is that? Since when is the real world
anything like ASCII? Because that is what we store in our databases.
That Pick can store repeating groups in its attributes is good for
certain types of queries. But ask a different query and the
whole Pick database has to be scanned. And Oracle DOES support
efficient access to repeating groups: The Oracle CLUSTER mechanism
can beat Pick repeating groups in both performance and flexibility.
> >4. What are the main criteria that we should judge the two databases
>
> Ohh... how about "what does this buy me?" and "how does it affect my bottom
> line over a 5 year period?"
How much are you prepared to pay for 24hr availability? Not having to
resize your files? Not having to call in support to fix the database
[corrupted files] or the application [missing credit] after a power
failure?
Oracle is not cheap but then it isn't that expensive either.
> >5. What would you buy and why?
>
> Actualy I'd buy Universe :) but hey, it's just my opinion.
You only answered half the question. Why would anyone buy Pick?
Because they have a legacy Pick application that cannot be easily
redeveloped. Nobody but a fool ports an Oracle application to
Pick. That is what is being proposed to the marketing guy. I know
nobody who has ever done so. Why? Because it would be silly!
> >6. Are there any Unidata problems that we should be aware of?
>
> No significant ones, especialy if you are used to the level of buggyness
> inherent in Oracle.
What buggyness? The above statement is made in ignorance or it
is deliberate misinformation. My Oracle customers do not experience
Oracle bugs. There are some small bugs in the latest versions of the
devt tools but otherwise nothing!
Those I know who run Pick (native or UniVerse) suffer bugs that cause
significant downtime. And the unavailability of the system during
backups and routine maintenance.
> >7. Can Unidata be used with Cognos Impromptu V3 and Cognos Plowerplay V4.1
>
> Uhhh... Nope..but then, you wont need those anymore with Unidata.
>
> regards,
> Jeff
Have you ANY Oracle experience? It seems not. Or, if you have,
you have tried to use it as if it were Pick. Those who moved to Pick
in the late 70s and 80s had to learn a new way of thinking. Moving
to Oracle from Pick requires a similar shift in order to gain benefit
from the move. But benefits there are. Plenty of them.
--
Paul Beardsell SAM Business Systems Ltd
~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
pbear...@cix.compulink.co.uk London, N1-6BN, UK.
p...@sambusys.demon.co.uk (+44 or 0)71 608-2391
Jackie Burhans
: In article <jschas.80...@rmii.com> Jeff did write:
: > In article <james-04099...@chilcott.demon.co.uk>
: > ja...@chilcott.demon.co.uk (James Tarin) writes:
: >
: > >Comparison between Leading Databases (Oracle and Unidata)
: > >----------------------------------------------------------
: Firstly, if the definition of "Leading" is "known by most" or
: "respected by all" then Unidata does not deserve that description.
Yeah well I was excited to see them lumped together that way but
didn't put too much stock that the whole rest of the world would
suddenly think of us in the same breath as Oracle. :-)
: > >As a marketing manager rather than an IT specialist I am looking for some
: > >impartial advice on the selection of large relational databases.
: A database is either relational or it is not. Is Post Relational
: relational? What are the attributes of a good database? A good
: database satisfies all the ACID properties. Unidata does not.
: What are the ACID properties?
Ahem. Unidata 3.3 supports Transaction Processing with a Recoverable File
system which DOES provide for FULL ACID compliance.
: ACID=Atomicity+Consistency+Isolation+Durability
: * Atomicity: All changes made in a database transaction are either
: all applied (committed) or none of them are applied. Not so in Pick.
Perhaps not in Pick but yes, so, in Unidata.
: * Oracle can be backed up in a application _consistent_ state while it
: being used and while being updated. Not so Pick. In Pick restoring
: a database so backed up will restore broken files and incomplete
: transactions. A Pick database must be taken offline to be backed up.
Unidata provides for on-line backup.
: Your question is re large databases. One of my UniVerse customers has
: a six hour downtime every night just to get the data on to tape. And
: every other weekend the files are resized to maintain performance.
: Neither procedure is required for Oracle.
Unidata supports large dynamic files up to 256GB. Whether that is considered
large depends on your point of view.
: * In a Pick environment a power failure will often leave the database
: in a broken state (GFE or equivalent). Not so with Oracle. In five
: years I have NEVER (literally) experienced the Oracle equivalent of
: a Pick GFE. In Pick the GFE is known by name to even the user
: community!
Well we don't call 'em GFE's in UniData :-). And if you use TP/RFS a power
failure will not leave your tables in a broken state.
: * Oracle automatically rolls back uncommitted transactions upon failure
: of a program. Upon the rare (i.e. "never" happens) Oracle failure
: uncommitted transactions are automatically rolled back upon the
: database being brought back up. Same for O/S, machine or power failure.
: Pick does none of that except it fails more often!
Unidata rolls back uncommitted transactions upon program, process or system
failure. Unidata TP/RFS automatically rolls back transactions if need be
upon recovery from system or media failure.
: * If at any time the app or o/s or machine or power fails before a
: transaction is finally committed then all the data remains unchanged.
: E.g. If an application (say, a banking money transfer program) fails then
: one must make sure that every debited amount has been credited and
: vice versa. In Oracle one simply puts each maching DR and CR in one
: database transaction. How does one ensure this with Pick? You call
: in the support programmer to check.
Unidata provides for TRANSACTION BEGIN/TRANSACTION END statements to
bracket multiple I/O's into a single transaction.
: * While the above application is running a customer phones in and asks
: for the balances of his accounts. An enquiry is run. The answer is:
: "In account A $1000 dollars and in account B $500." But the customer
: knows that he has $2000! What has gone wrong? The above application
: is busy transferring money from account A to account B. The application
: is written in Pick! If the application were written in Oracle the
: debit would not be visible until it had been committed ATOMICALLY with
: its corresponding credit. (Atomicity! Consistency!) Not even locking
: the records helps in Pick - a record is only locked against WRITE - you
: can still read the effects of a transaction before it is complete.
: Note that in Oracle no locking would be specified by the Programmer -
: the database would do it all. But the "before image" would never be
: locked! What does that give you? CONCURRENCY!
With UniData TP you will see none of the writes before the transaction
commits.
: * A program hits an error condition (e.g. overdrawn balance) that means
: the updates performed so far must be undone. In Oracle you simply
: ROLLBACK. No other user has seen the bad updates (Isolation!)
: and the data is left unchanged. What do you do in Pick or Unidata?
Well in Unidata if you hit an error condition you would not COMMIT the
transaction and none of the writes would be made.
: > >Can anyone give me some idea on,
: >
: > >1. The strengths and weaknesses of Unidata.
: >
: > On the same hardware platform, it will run more efficiently than Oracle,
: > support more users, allow faster development, require less maintenance,
: > reduce staffing requirements, and allow for more flexible ad-hoc
reporting.
: I will concede that Oracle requires more memory than Unidata. But
: so what? Memory is cheap. The runtime performance claim is not
: backed up by any figures or benchmarks. I wrote applications for
: seven years using Pick R83, Ultimate and UniVerse. Now I write
: Oracle applications and BELIEVE ME they FLY!
In addition to memory, there will be reduced disk storage due to
less redundant data. Of course, you can argue that disk is cheap
too. One could argue that development is "faster" due to a more
natural data model.
One could argue against that citing programmer ability etc etc etc.
: Pick traditionally only supported quick access to a record if you
: knew the key to the record . In Oracle any column can be used for
: access. And any column can be indexed. Unidata might have secondary
: indexes but they better work better than UniVerse's. Unidata indexes
: are not used automatically by applifcation programs. In Oracle
: any access uses the best available index. In Oracle indexes can
: be removed or added at will (and while the database is running and
: being updated) WITHOUT changing any form, report or program and all
: Oracle apps will use the new index if it provides a better path to the
: data.
Any query to a Unidata table will use the index automatically if one exists;
Unidata will choose to use a certain index over another or even not
use an index according to a set of self-optimizing algorithms. Direct I/O
via UniBasic will not use the index unless you code it to do so. I don't know
what facilities for direct I/O are allowed in Oracle.
: Pick can perform better than Oracle in certain restricted queries.
: But for flexible ad-hoc reporting a PROPER relational database will
: ALWAYS beat a record-based keyed database like Pick.
Why?
: Pick provides faster development? Pah! Why are there no Pick
: entrants in the rapid development contest currently being advertised
: in this and the other database newsgroups? The tools provided by
: Oracle (Forms, Reports, Graphics, Browser) are perhaps not the best
: available but they're a damn site nicer and easier than anything
: available for Pick. System Builder? Visual Basic and Hyperstar?
: All of those are pretty appalling!
The fact that there are no Pick entrants in the RAD contest does not, to
me at least, inherently prove or disprove anything. Pick systems in general
and Unidata in specific provide access to a number of tools which people will
like or dislike according to their own tastes. One of the arguments in favor
of rapid development in a "Pick" environment is the more "natural"
data model-- less need for data normalization. There are, of course,
counter arguments.
: Gone are the days when Pick provided the best devt environment. In 1986
: Pick (in combination with Systemn Builder) won all the devt competitions.
: It is now 1996 and things have moved on (unless you a Luddite Pickie).
Yes true. And Pick has moved on. And Unidata has moved on. etc.
: Pick is literally anochronistic. It was the best. It is no longer
: the best.
Ok, its a subjective judgement it seems to me. And always was and always
will be.
: > >3. Which of the two systems are technically superior and why
: >
: > Well, since you're a marketing guy, I'm not going to get into a
long winded
: > discussion of the relative merits of relational vs the Pick/NF2
model. But : > suffice to say that "Father" of the relational model
(E.F.Codd) has recently : > said that the relational model is less
efficient than the NF2 model for : > use with "real world data"
: The Pick community call their database model Post Relational.
: If anything it is a pre-relational database. They harp on about
: the advantages of their data model (which they term NF2) based on one
: small quote by Codd. But then they never do actually provide the
: quote but paraphrase it - and every time I see yet another
: iteration of the paraphrase it becomes more outlandish.
: Most of the things said by Codd, a pioneer of relational databases,
: about databases do not show Pick-like databases in a good light.
: One should not be surprised that Codd has said _one_ thing
: that can be paraphrased in such a way to make Pick look good:
: Codd says lots of things!
The quote we use is:
Relational databases ... were never meant to provide the intensive data
synthesis, analysis and consolidation that are provided by multi-dimensional
databases. Source:E.F. Codd & Associates Computerworld, July 1993
--pardon if my quote is not perfectly exact but I found it in one of my
slide shows for LatinAmerica and I had to translate it back from Spanish.
: "Real world data"? What is that? Since when is the real world
: anything like ASCII? Because that is what we store in our databases.
: That Pick can store repeating groups in its attributes is good for
: certain types of queries. But ask a different query and the
: whole Pick database has to be scanned. And Oracle DOES support
: efficient access to repeating groups: The Oracle CLUSTER mechanism
: can beat Pick repeating groups in both performance and flexibility.
Doesn't the Oracle CLUSTER mechanism simply denormalize the data model or
pre-join tables? I'm not an Oracle person as you can plainly see.
: > >4. What are the main criteria that we should judge the two databases
: >
: > Ohh... how about "what does this buy me?" and "how does it
affect my bottom
: > line over a 5 year period?"
: How much are you prepared to pay for 24hr availability? Not having to
: resize your files? Not having to call in support to fix the database
: [corrupted files] or the application [missing credit] after a power
: failure?
: Oracle is not cheap but then it isn't that expensive either.
: > >5. What would you buy and why?
: >
: > Actualy I'd buy Universe :) but hey, it's just my opinion.
: You only answered half the question. Why would anyone buy Pick?
: Because they have a legacy Pick application that cannot be easily
: redeveloped. Nobody but a fool ports an Oracle application to
: Pick. That is what is being proposed to the marketing guy. I know
: nobody who has ever done so. Why? Because it would be silly!
I know one company in the process of doing something like this. Not
porting Oracle to Unidata per se but implementing a Unidata solution because
the Oracle one didn't work.
: > >6. Are there any Unidata problems that we should be aware of?
: >
: > No significant ones, especialy if you are used to the level of buggyness
: > inherent in Oracle.
: What buggyness? The above statement is made in ignorance or it
: is deliberate misinformation. My Oracle customers do not experience
: Oracle bugs. There are some small bugs in the latest versions of the
: devt tools but otherwise nothing!
All software I have ever used has had some bug or another in it. All. As
long as the bug is minor or gets fixed real darn quick, I generally deal
with it.
: Those I know who run Pick (native or UniVerse) suffer bugs that cause
: significant downtime. And the unavailability of the system during
: backups and routine maintenance.
: > >7. Can Unidata be used with Cognos Impromptu V3 and Cognos
Plowerplay V4.1
: >
: > Uhhh... Nope..but then, you wont need those anymore with Unidata.
: >
: > regards,
: > Jeff
: Have you ANY Oracle experience? It seems not. Or, if you have,
: you have tried to use it as if it were Pick. Those who moved to Pick
: in the late 70s and 80s had to learn a new way of thinking. Moving
: to Oracle from Pick requires a similar shift in order to gain benefit
: from the move. But benefits there are. Plenty of them.
: --
: Paul Beardsell SAM Business Systems Ltd
: ~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
: pbear...@cix.compulink.co.uk London, N1-6BN, UK.
: p...@sambusys.demon.co.uk (+44 or 0)71 608-2391
Nor have I much Oracle experience. A tad but only a tad. My only purpose
in responding to your message was to clarify any questions about UniData's
features and functionality because that is what I have a lot of recent
experience with. By the way to be perfectly fair, I believe that
uniVerse also supports TP and claims ACID compliance. Pick may as well.
I'm not trying to speak to their product features as that is not where
my knowledge lies.
Nor is my response meant to compare and/or compete head to head with
Oracle. We recognize their position and importance in that database
industry. In fact we make sure that we are compatible and can co-exist
happily in an Oracle environment from offering a direct I/O interface
via UniBasic with our Open File System technology or access via
client/server mechanisms such as the Sybase Open Client/Open Server
technology (both UNIX based (allowing access through gateway products
like SQL/Net) and Windows-based (allowing synthesis of data via desktop
tools like Forest & Trees et al which can access both UniData and
Oracle simultaneously.)
Jackie Burhans
Technical Account Manager
Unidata, Inc.
Ian McGowan
[much stuff, mostly unarguable, cut]
: * While the above application is running a customer phones in and asks
: for the balances of his accounts. An enquiry is run. The answer is:
: "In account A $1000 dollars and in account B $500." But the customer
: knows that he has $2000! What has gone wrong? The above application
: is busy transferring money from account A to account B. The application
: is written in Pick! If the application were written in Oracle the
: debit would not be visible until it had been committed ATOMICALLY with
: its corresponding credit. (Atomicity! Consistency!) Not even locking
: the records helps in Pick - a record is only locked against WRITE - you
: can still read the effects of a transaction before it is complete.
: Note that in Oracle no locking would be specified by the Programmer -
: the database would do it all. But the "before image" would never be
: locked! What does that give you? CONCURRENCY!
Uh, what if the customer withdraws money from A while this is happening?
Do you check twice, once at the start and then again before COMMIT'ing? Or
am I missing something totally obvious...
Just for the record, has anyone reading converted from oracle|sybase|
informix _to_ pick or a pick-a-like? Or know of anyone who has?
--
work <- j...@bfr.com Practice random lane changes and
play <- i...@netcom.com commit senseless bursts of acceleration
Jeffrey W. Janner
[lots of pontificating deleted]
* Oracle automatically rolls back uncommitted transactions upon failure
of a program. Upon the rare (i.e. "never" happens) Oracle failure
uncommitted transactions are automatically rolled back upon the
database being brought back up. Same for O/S, machine or power failure.
Pick does none of that except it fails more often!
Excuse me, but this is a load of whooey! My former company had 100's of
Pick-based installations that all-together failed less times is 6 months
than my wife's Oracle database did in two weeks. And it sometimes took
her more than 8 hours to get the databasse back up and useful.
* If at any time the app or o/s or machine or power fails before a
transaction is finally committed then all the data remains unchanged.
E.g. If an application (say, a banking money transfer program) fails then
one must make sure that every debited amount has been credited and
vice versa. In Oracle one simply puts each maching DR and CR in one
database transaction. How does one ensure this with Pick? You call
in the support programmer to check.
* While the above application is running a customer phones in and asks
for the balances of his accounts. An enquiry is run. The answer is:
"In account A $1000 dollars and in account B $500." But the customer
knows that he has $2000! What has gone wrong? The above application
is busy transferring money from account A to account B. The application
is written in Pick! If the application were written in Oracle the
debit would not be visible until it had been committed ATOMICALLY with
its corresponding credit. (Atomicity! Consistency!) Not even locking
the records helps in Pick - a record is only locked against WRITE - you
can still read the effects of a transaction before it is complete.
Note that in Oracle no locking would be specified by the Programmer -
the database would do it all. But the "before image" would never be
locked! What does that give you? CONCURRENCY!
More whooey! Many, if not most, implementations of Pick are starting to
support some for of transactioning. Plus server, such as universe,
support a shared-READ lock such that if someone has a record locked for
WRITE then the readers wait for completion. Now on to the general locking
question? How does one insure that the user is applying the correct
change based on the data? Scenario: User A reads account 123 with balance
$200, User B reads 123 with $200 balance and adds $100 to it. User A then
deducts $50 from the account. What is the new balance? ($150 or $250, or
some other figure?) Or does Oracle just up-chuck and make use A have to
redo all his work?
[snip]
> Why is a marketing manager making I.S. decisions? Hmmmm... Oh well, just
> a favorite rant of mine.
He is looking for advice. More power to his elbow, say I. Pity
you will not provide the _impartial_ advice he is looking for.
Worse than that: Misinformation is what you supply.
You really missed the point of the original comment, didn't you! (but
since you're probably a marketing guy yourself, that's understandable).
His point was why is a non-technical person attempting to make a
technical decision that will most likely affect whether the business
prospers or fails?
(oops, just noticed you claimed to be developer below. Sorry if the above
is a slight.)
[...snip...]
Pick can perform better than Oracle in certain restricted queries.
But for flexible ad-hoc reporting a PROPER relational database will
ALWAYS beat a record-based keyed database like Pick.
Sounds like your saying that R-DBMS are not keyed. I seem to recall that
you have to provide a primary key for every table in Oracle. Am I wrong?
The method of access and storage may be a little different, but you still
have to get at the row (record), often via the primary key, eventually.
Pick provides faster development? Pah! Why are there no Pick
entrants in the rapid development contest currently being advertised
in this and the other database newsgroups? The tools provided by
Oracle (Forms, Reports, Graphics, Browser) are perhaps not the best
available but they're a damn site nicer and easier than anything
available for Pick. System Builder? Visual Basic and Hyperstar?
All of those are pretty appalling!
I'll admit that the tools are scarce and possibly of less than stellar
quality. However, most are attempting to "bolt-on" some kind of SQL-like
or industry standard protocol that was developed for SQL databases and not
Pick databases, thus being hampered by the limitations of the protocol.
Of course, when you have tons of monetoary resources to throw at your
development, you generally get a better product. (Kinda makes you wonder
why Oracle's are reputed to be so bad?)
[...snip for space...]
"Real world data"? What is that? Since when is the real world
anything like ASCII? Because that is what we store in our databases.
Uh, "rwd" is what your attempting to store and having to code into ASCII.
The purpose of DBMS is to "emulate the real world" as close as possible.
That was Codd's intention in developing the relational model and the
normalization rules. (go look it up)
[...final snippage...]
The author made some valid criticisms of Pick-like databases, but some of
them with obvious ignorance of the current Pick market. Judging from his
comments, he hasn't dealt with Pick in over 10 years. Yes there is still
plenty of room for improvement in the database and hopefully, now that the
"great-god" is no longer with us, perhaps there can finally be some
movement forward. Perhaps the warind Pick vendors can start fighting over
their measly share of the DBMS market & start cooperating again to develop
and improve some standards (like at least supporting all of SPECTRUM).
They need to wake-up and realize that the enemy is not the other Pick
vendors out there, but the hordes of R-DBMS vendors out there and the
general trade press (who generally promote the hell out of the latest
*neat, new* trendy thing, whether there's any real benefit or not).
Lastly, perhaps they could try to get some coverage in some college
textbooks, so that people will know there are other options that SQL and
ancient IBM databases.
BTW: I once developed a university transcript system using a RDBMS that I
later realized I could have developed in half the time using a Pick-like
database and it would have run faster by about a power of 10. The RDBMS
took about an hour just to do all the joins, etc. associated with just
starting up every morning. Admittedly, this was about 10 years ago when
RDBMS was still in it's infancy. They've since added indexes and a better
query language so it would probably be faster now (but it would have
needed to be re-written). Remember, a lot of changes have occurred in the
PICK market it that time frame as well.
--
Jeff Janner | "Nothing is foolproof to a
jwja...@tamu.edu | sufficiently talented fool." - Anon
Jeffrey W. Janner
Just for the record, has anyone reading converted from oracle|sybase|
informix _to_ pick or a pick-a-like? Or know of anyone who has?
I've heard a few people out there post that they had, but I couldn't say
who. Here's one little bit of industry news: Back in March, I got a call
from a former manager of mine. Seems our old company (a national temp.
agency) had decided to convert their internal worker-placement system from
a Prime INFORMATION system to some unspecified system running Oracle. Two
years, 15 programmers, and several million dollars later, they still did
not have a working system (much less a prototype). The INFORMATION system
was being maintained and upgraded by a staff of only two programmers (who
worked mainly 8-5 as opposed to the Oracle team).
Just thought I'd pass that along.
Rich Ahrens
: Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
: : relational? What are the attributes of a good database? A good
: : database satisfies all the ACID properties. Unidata does not.
: : What are the ACID properties?
: Ahem. Unidata 3.3 supports Transaction Processing with a Recoverable File
: system which DOES provide for FULL ACID compliance.
I'd be interested in hearing from real-world users running the RFS on a
sizeable system (say, more than 500 users) in production. This is not a
critique, but a serious desire to talk to experienced users of the
product.
: : ACID=Atomicity+Consistency+Isolation+Durability
: : * Atomicity: All changes made in a database transaction are either
: : all applied (committed) or none of them are applied. Not so in Pick.
: Perhaps not in Pick but yes, so, in Unidata.
If specifically coded with transaction semantics.
: : * Oracle can be backed up in a application _consistent_ state while it
: : being used and while being updated. Not so Pick. In Pick restoring
: : a database so backed up will restore broken files and incomplete
: : transactions. A Pick database must be taken offline to be backed up.
: Unidata provides for on-line backup.
Not as an available product. The last I asked, it had not even been
decided what release would include it. It is definitely not available on
3.3.2, according to at least two of your VPs.
: : Your question is re large databases. One of my UniVerse customers has
: : a six hour downtime every night just to get the data on to tape. And
: : every other weekend the files are resized to maintain performance.
: : Neither procedure is required for Oracle.
: Unidata supports large dynamic files up to 256GB. Whether that is considered
: large depends on your point of view.
Hey, don't be modest. I thought 3.3 allows up to 255 each of the dat and
ovf partitions. Each of those being a Unix file, with a typical
limitation of 2 GB per file, you should be able to get up to just under
a terabyte in a single dynamic file. I'd hate to have to back it up,
though. :-)
: Any query to a Unidata table will use the index automatically if one exists;
: Unidata will choose to use a certain index over another or even not
: use an index according to a set of self-optimizing algorithms. Direct I/O
: via UniBasic will not use the index unless you code it to do so. I don't know
: what facilities for direct I/O are allowed in Oracle.
*Any* query? According to what I've been told and have confirmed with
testing, that's a long way from reality. You're limited to one key per
select to be able to use indexes, and the select cannot be based on a
list so you can't do it in multiple steps to get around that limitation.
Assuming DATE and CUSTOMER are indexed attributes, the following won't
use the indexes:
SELECT HISTORY BY DATE BY CUSTOMER
SELECT HISTORY WITH DATE BETWEEN "01/01/94" "12/31/94"
GET-LIST CURRENT.MONTH
>SELECT HISTORY BY DATE
Any Oracle jocks want to tell us what it would do with the equivalent
queries?
----------------------------------------------------------------------
|Rich Ahrens | Homepage: http://www.winternet.com/~rma/ |
|r...@winternet.com|--------------------------------------------------|
|r...@netcom.com | "Philosophy is useless, theology is worse" - M.K.|
----------------------------------------------------------------------
Jackie Burhans
: Jackie Burhans (bur...@rainbow.rmii.com) wrote:
: I'd be interested in hearing from real-world users running the RFS on a
: sizeable system (say, more than 500 users) in production. This is not a
: critique, but a serious desire to talk to experienced users of the
: product.
Contact your salesrep to see if they can give you a specific site name. I know
we have 2 in the process of implementing with users of 800 to 1500 users. I
don't know where they are in the process. But your salesrep (I'm assuming
you have one? ) is usually the one who can give you the reference account name.
If not sales then marketing can assist you with reference account info.
: : : ACID=Atomicity+Consistency+Isolation+Durability
: : : * Atomicity: All changes made in a database transaction are either
: : : all applied (committed) or none of them are applied. Not so in Pick.
: : Perhaps not in Pick but yes, so, in Unidata.
: If specifically coded with transaction semantics.
Yes. You do have to code for it. Don't you in Oracle, et al?
: : : * Oracle can be backed up in a application _consistent_ state while it
: : : being used and while being updated. Not so Pick. In Pick restoring
: : : a database so backed up will restore broken files and incomplete
: : : transactions. A Pick database must be taken offline to be backed up.
: : Unidata provides for on-line backup.
: Not as an available product. The last I asked, it had not even been
: decided what release would include it. It is definitely not available on
: 3.3.2, according to at least two of your VPs.
Not 3.3.2 we do have a site I believe implementing it on a beta basis. Again
if you need a reference we can get that to you off-line.
: : Any query to a Unidata table will use the index automatically if one exists;
: : Unidata will choose to use a certain index over another or even not
: : use an index according to a set of self-optimizing algorithms. Direct I/O
: : via UniBasic will not use the index unless you code it to do so. I don't know
: : what facilities for direct I/O are allowed in Oracle.
: *Any* query? According to what I've been told and have confirmed with
: testing, that's a long way from reality. You're limited to one key per
: select to be able to use indexes, and the select cannot be based on a
: list so you can't do it in multiple steps to get around that limitation.
: Assuming DATE and CUSTOMER are indexed attributes, the following won't
: use the indexes:
If you take my *two* statements together, I stand by this. What I was
trying to say is that any query will use the indexes if it can. The if
it can part is based on these self-optimizing algorithms. These rules are
documented in the manuals.
: SELECT HISTORY BY DATE BY CUSTOMER
My understanding in general from the engineers is that if you sort a
field and that field is indexed (that means its already stored in
sorted order essentialy via the Btree) we will use the index to assist
in the sort. Is that what you were getting at? or did you mean having
one select folow another? In which case see below.
: SELECT HISTORY WITH DATE BETWEEN "01/01/94" "12/31/94"
I believe this *will* use the index. The general rule is that we will
use one index field to do the initial select (which one, first
available from left to right with a preference for a condition with "="
rather than ">" etc.) Additional conditions will be resolved by reading the
record and examining the data. The exception is if its that same data field
and you are doing a "between" type function. If perchance I am mistaken
about BETWEEN working (and I'm so rarely wrong...) than certainly the
following will work:
SELECT HISTORY WITH DATE >= XXX AND DATE <= yyy
which gives the same functionality as BETWEEN.
: GET-LIST CURRENT.MONTH
: >SELECT HISTORY BY DATE
Yes this is one of the "rules". If you have an active select list we
will use it in preference to the index under the assumption that you
already have the recors you want in the select list.
Certainly this tracks with how it used to work for me in the old Prime
days under INFORMATION--they had their "rules" which are
somewhat different from ours based on the type of indexing they used.
We try to set up and use the indexes somewhat sensibly.
: Any Oracle jocks want to tell us what it would do with the equivalent
: queries?
Anyway hope this clarifies anthing that was unclarified.
Jackie
Paul Beardsell
> Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
> [much stuff, mostly unarguable, cut]
> : * While the above application is running a customer phones in and asks
> : for the balances of his accounts. An enquiry is run. The answer is:
> : "In account A $1000 dollars and in account B $500." But the customer
> : knows that he has $2000! What has gone wrong? The above application
> : is busy transferring money from account A to account B. The application
> : is written in Pick! If the application were written in Oracle the
> : debit would not be visible until it had been committed ATOMICALLY with
> : its corresponding credit. (Atomicity! Consistency!) Not even locking
> : the records helps in Pick - a record is only locked against WRITE - you
> : can still read the effects of a transaction before it is complete.
> : Note that in Oracle no locking would be specified by the Programmer -
> : the database would do it all. But the "before image" would never be
> : locked! What does that give you? CONCURRENCY!
>
> Uh, what if the customer withdraws money from A while this is happening?
> Do you check twice, once at the start and then again before COMMIT'ing? Or
> am I missing something totally obvious...
Good question! And answering it allows me to demonstrate a feature
of the paradigm shift you must make when moving from Pick to Oracle.
You only need check the balance once and you need not explicitly set
any lock in order to correctly process the money transfer. Forgive the 'C'
and the GOTO but otherwise I would have to explain the syntax of PL/SQL:
int Transfer( acct_a, acct_b, amount)
{
EXEC SQL WHENEVER NOT FOUND GOTO NO_SUCH_ROW;
/* Above exception fires if a SQL statement operates on zero rows. */
EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE - :amount
WHERE ACCOUNT_ID = :acct_a AND BALANCE >= :amount;
EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE + :amount
WHERE ACCOUNT_ID = :acct_b;
EXEC SQL COMMIT WORK;
return SUCCESS;
NO_SUCH_ROW:
EXEC SQL ROLLBACK WORK;
return FAIL;
}
The above code would give the greatest concurrency. Note that the database
does the necessary locks and that until the COMMIT is executed no one
else can see the UPDATEs - they see the "before image".
The following is equivalent functionally but is less efficient
(more database accesses, locks held longer and therefore worse
concurrency). And the following is typical of that written by those
moving to Oracle from environments such as Pick:
int Transfer( acct_a, acct_b, amount)
{
EXEC SQL WHENEVER NOT FOUND GOTO NO_SUCH_ROW;
EXEC SQL SELECT BALANCE INTO :balance
WHERE ACCOUNT_ID = :acct_a
FOR UPDATE OF BALANCE; /* <-- sets lock */
if( balance <= amount) {
EXEC SQL ROLLBACK WORK;
return FAIL;
}
EXEC SQL UPDATE ACCOUNT SET BALANCE = :balance - :amount
WHERE ACCOUNT_ID = :acct_a AND BALANCE >= :amount;
EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE + :amount
WHERE ACCOUNT_ID = :acct_b;
EXEC SQL COMMIT WORK;
return SUCCESS;
NO_SUCH_ROW:
EXEC SQL ROLLBACK WORK;
return FAIL;
}
> Just for the record, has anyone reading converted from oracle|sybase|
> informix _to_ pick or a pick-a-like? Or know of anyone who has?
> --
> work <- j...@bfr.com Practice random lane changes and
> play <- i...@netcom.com commit senseless bursts of acceleration
--
Paul Beardsell
If Unidata does support fully the ACID properties then perhaps it
is a viable alternative to Oracle for modern TP applications.
Is anybody using the TP / ACID etc properties of the latest Unidata
releases? Do they work?
> : a Pick GFE. In Pick the GFE is known by name to even the user
> : community!
> Well we don't call 'em GFE's in UniData :-). And if you use TP/RFS a power
> failure will not leave your tables in a broken state.
Is TP/RFS something I turn on and make mandatory for the whole database
or would I turn it on application program by app. program? In other
words will one legacy program risk my tables being broken upon a power
failure?
Does TP/RFS impose restrictions on the programmer? I.e. Can s/he still
code as before without breaking TP/RFS? If s/he uses READ and WRITE
instead of SQL is TP/RFS broken?
> Any query to a Unidata table will use the index automatically if one exists;
> Unidata will choose to use a certain index over another or even not
> use an index according to a set of self-optimizing algorithms. Direct I/O
> via UniBasic will not use the index unless you code it to do so. I don't know
> what facilities for direct I/O are allowed in Oracle.
In Oracle Direct I/O is provided via SQL. The best available index(es)
are always used.
> : Pick can perform better than Oracle in certain restricted queries.
> : But for flexible ad-hoc reporting a PROPER relational database will
> : ALWAYS beat a record-based keyed database like Pick.
> Why?
Because a truly ad hoc query is unlikely to be via the key.
> : > >3. Which of the two systems are technically superior and why
> : >
> : > Well, since you're a marketing guy, I'm not going to get into a
> long winded
> : > discussion of the relative merits of relational vs the Pick/NF2
> model. But : > suffice to say that "Father" of the relational model
> (E.F.Codd) has recently : > said that the relational model is less
> efficient than the NF2 model for : > use with "real world data"
>
> : The Pick community call their database model Post Relational.
> : If anything it is a pre-relational database. They harp on about
> : the advantages of their data model (which they term NF2) based on one
> : small quote by Codd. But then they never do actually provide the
> : quote but paraphrase it - and every time I see yet another
> : iteration of the paraphrase it becomes more outlandish.
> : Most of the things said by Codd, a pioneer of relational databases,
> : about databases do not show Pick-like databases in a good light.
> : One should not be surprised that Codd has said _one_ thing
> : that can be paraphrased in such a way to make Pick look good:
> : Codd says lots of things!
> The quote we use is:
>
> Relational databases ... were never meant to provide the intensive data
> synthesis, analysis and consolidation that are provided by multi-dimensional
> databases. Source:E.F. Codd & Associates Computerworld, July 1993
Aha! Multi-dimensional databases: What makes anyone think Pick is
a multidimensional database? How many dimensions does Pick cater for?
If a relational database is two-dimensional then Pick is (at best)
four-dimensional (values and sub-values). Four is hardly multiple!
But before you say 4 is better than 2 read on: What are good examples of
multi-dimensional databases (MDDB)? IXI is one and MD2(?) is another.
What is so good about them? Well one feature is that you can choose to
look at the MDDB from different perspectives. Hold the 5th dimension
constant and slide thru the others. Another query comes along - look
at your data from another axis. Pick doesn't provide for this. In Pick
the data can only be viewed from one "angle". The multi-values & sub-
values are fixed in their association with each other and the other
attributes.
Pick only allows you one perspective on the 4 dimensional data. To
obtain another perspective you must re-organise the data resulting
in a different key structure & the grouping of different attributes into
multi-values fields.
The Pick data model isn't normalised! The Relational data model is
normalised! What does this mean? Relational data can be viewed
from another perspective without re-writing the data in a different
format to obtain efficient queries because the data is already
normalised. But nevertheless a RDBMS does not have the flexibility
or efficiency of a Multi Dimensional Database when it comes to allowing
the user to dynamically select another "angle" on his/her data.
Oracle is not a MDDB. And neither is Pick.
Codd is being taken out of context. Codd did NOT say: "The Pick data
model is superior to the Relational data model." And Pickies who think
he did have horizons so narrow that they don't know what a MDDB is!
> --pardon if my quote is not perfectly exact but I found it in one of my
> slide shows for LatinAmerica and I had to translate it back from Spanish.
>
> : "Real world data"? What is that? Since when is the real world
> : anything like ASCII? Because that is what we store in our databases.
> : That Pick can store repeating groups in its attributes is good for
> : certain types of queries. But ask a different query and the
> : whole Pick database has to be scanned. And Oracle DOES support
> : efficient access to repeating groups: The Oracle CLUSTER mechanism
> : can beat Pick repeating groups in both performance and flexibility.
> Doesn't the Oracle CLUSTER mechanism simply denormalize the data model or
> pre-join tables? I'm not an Oracle person as you can plainly see.
Yes! But I thought you Pickies thought that that was a good idea!
But better than Pick the data is manipulated as if it were in distinct
tables and looks as if it is in distinct tables yet internally the
tables are pre-joined. This allows the DBA to pre-join where necessary
for performance reasons without requiring program changes! Pick like
features without the Pick-style hang ups. For example: It is a piece
of cake to insert a set of parallel multi-values in an Oracle cluster:
Just INSERT the set in one statement. Not in Pick: LOCATE followed by an
INSERT for each multi-value. :-(
> Nor have I much Oracle experience. A tad but only a tad. My only purpose
> in responding to your message was to clarify any questions about UniData's
> features and functionality because that is what I have a lot of recent
> experience with. By the way to be perfectly fair, I believe that
> uniVerse also supports TP and claims ACID compliance. Pick may as well.
> I'm not trying to speak to their product features as that is not where
> my knowledge lies.
>
> Nor is my response meant to compare and/or compete head to head with
> Oracle. We recognize their position and importance in that database
> industry. In fact we make sure that we are compatible and can co-exist
> happily in an Oracle environment from offering a direct I/O interface
> via UniBasic with our Open File System technology or access via
> client/server mechanisms such as the Sybase Open Client/Open Server
> technology (both UNIX based (allowing access through gateway products
> like SQL/Net) and Windows-based (allowing synthesis of data via desktop
> tools like Forest & Trees et al which can access both UniData and
> Oracle simultaneously.)
I have criticised Unidata as if it were Pick. Undeservedly, it would seem.
Sorry.
But does the Unidata SQL INSERT statement work on multi-valued data yet?
> Jackie Burhans
> Technical Account Manager
> Unidata, Inc.
--
Steven H. Edwards
>Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
>: In article <jschas.80...@rmii.com> Jeff did write:
>
>: > In article <james-04099...@chilcott.demon.co.uk>
>: > ja...@chilcott.demon.co.uk (James Tarin) writes:
[snip]
>: > No significant ones, especialy if you are used to the level of buggyness
>: > inherent in Oracle.
>
>: What buggyness? The above statement is made in ignorance or it
>: is deliberate misinformation. My Oracle customers do not experience
>: Oracle bugs. There are some small bugs in the latest versions of the
>: devt tools but otherwise nothing!
[snip]
>: Those I know who run Pick (native or UniVerse) suffer bugs that cause
>: significant downtime. And the unavailability of the system during
>: backups and routine maintenance.
Back when I worked for Prime Customer Service I had to do international support for Prime
INFORMATION as well as Oracle. Oracle was a nightmare. When I would try to follow up a bug
report with Oracle for one of our customers, the response I would most often get was "Gee, it
doesn't fail that way on a xxxx machine." Oracle had done the port, so I thought they would be
able to take care of their own database problems. Think again. I found the product to be at
least as buggy as any other database I have ever worked with.
>: > >7. Can Unidata be used with Cognos Impromptu V3 and Cognos
>Plowerplay V4.1
>: >
>: > Uhhh... Nope..but then, you wont need those anymore with Unidata.
Just an FYI, uniVerse can be used with both ofthe above products via the HyperStar product.. And
uniVerse has displaced Oracle, at least at one VAR in the UK.
Steve
Sahgal
hour availability is needed. Well, refer to the position announcement below:
>Unidata Pick Programmer needed to continue maintaining and developing
>software used by 911 fire/ems dispatch and fire records personnel. This
>position is available immediately. Working environment is relaxed and
>secure. Position requires experience in Pick programming and preferably
>experience with interfacing to other vendor equipment. E-mail interest to
>PH...@aol.com.
I pass this along without comments.
Prashant Sahgal
psa...@hoffman.ds.adp.com
Jeffrey W. Janner
} In article <ianDEr...@netcom.com> i...@netcom.com "Ian McGowan" writes:
}
} > Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
} > [much stuff, mostly unarguable, cut]
} > : * While the above application is running a customer phones in and asks
} > : for the balances of his accounts. An enquiry is run. The answer is:
} > : "In account A $1000 dollars and in account B $500." But the customer
} > : knows that he has $2000! What has gone wrong? The above application
} > : is busy transferring money from account A to account B. The application
} > : is written in Pick! If the application were written in Oracle the
} > : debit would not be visible until it had been committed ATOMICALLY with
} > : its corresponding credit. (Atomicity! Consistency!) Not even locking
} > : the records helps in Pick - a record is only locked against WRITE - you
} > : can still read the effects of a transaction before it is complete.
} > : Note that in Oracle no locking would be specified by the Programmer -
} > : the database would do it all. But the "before image" would never be
} > : locked! What does that give you? CONCURRENCY!
} >
} > Uh, what if the customer withdraws money from A while this is happening?
} > Do you check twice, once at the start and then again before COMMIT'ing? Or
} > am I missing something totally obvious...
}
} Good question! And answering it allows me to demonstrate a feature
} of the paradigm shift you must make when moving from Pick to Oracle.
}
} You only need check the balance once and you need not explicitly set
} any lock in order to correctly process the money transfer. Forgive the 'C'
} and the GOTO but otherwise I would have to explain the syntax of PL/SQL:
}
} int Transfer( acct_a, acct_b, amount)
} {
} EXEC SQL WHENEVER NOT FOUND GOTO NO_SUCH_ROW;
} /* Above exception fires if a SQL statement operates on zero rows. */
} EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE - :amount
} WHERE ACCOUNT_ID = :acct_a AND BALANCE >= :amount;
} EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE + :amount
} WHERE ACCOUNT_ID = :acct_b;
} EXEC SQL COMMIT WORK;
} return SUCCESS;
} NO_SUCH_ROW:
} EXEC SQL ROLLBACK WORK;
} return FAIL;
} }
}
No, no, no! The question was withdrawal, not transfer. At what point
does the user get his money? Or the ATM machine spit it out.
} The above code would give the greatest concurrency. Note that the database
} does the necessary locks and that until the COMMIT is executed no one
} else can see the UPDATEs - they see the "before image".
}
So the teller sees the *before* image that says he has enough money and
give him more, even though the above update may bring the balance below
available funds?
At least under Pick you could display message, if necessary, that an
update was pending, please wait for completion. ('Course we're talking
banking here, were most of the updates are still posted in "batch mode"
around midnight, even if you deposit cash.)
} The following is equivalent functionally but is less efficient
} (more database accesses, locks held longer and therefore worse
} concurrency). And the following is typical of that written by those
} moving to Oracle from environments such as Pick:
}
} int Transfer( acct_a, acct_b, amount)
} {
} EXEC SQL WHENEVER NOT FOUND GOTO NO_SUCH_ROW;
} EXEC SQL SELECT BALANCE INTO :balance
} WHERE ACCOUNT_ID = :acct_a
} FOR UPDATE OF BALANCE; /* <-- sets lock */
} if( balance <= amount) {
} EXEC SQL ROLLBACK WORK;
} return FAIL;
} }
} EXEC SQL UPDATE ACCOUNT SET BALANCE = :balance - :amount
} WHERE ACCOUNT_ID = :acct_a AND BALANCE >= :amount;
} EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE + :amount
} WHERE ACCOUNT_ID = :acct_b;
} EXEC SQL COMMIT WORK;
} return SUCCESS;
} NO_SUCH_ROW:
} EXEC SQL ROLLBACK WORK;
} return FAIL;
Personally, I prefer this version. It explicitly states what is being
done and the casual reader understands what is happening. (I'm assuming
that the ROLLBACK is taking care of releasing the lock?)
Jeffrey W. Janner
} The Pick data model isn't normalised! The Relational data model is
} normalised! What does this mean? Relational data can be viewed
Sorry, gotta interject here. No data model is "normalized". Your data
storage format is normalized. It's just that the Relational Model
*forces* you to normalize in order to store certain data structures.
There is absolutley no reason that you cannot normalize a database in Pick
just as you would an Oracle database. And I'd be willing to bet that the
Pick database would still be more efficient.
OH COME ON! Youj still have to list each field in the SQL statement.
That's all the INSERT (or better record<attr#,pos#> =) is doing. There is
still roughly the same amount of specification involved. (and before you
get on about needing to know the attr#, a good design will have them in a
file that can be $INCLUDEd and the programmer stiull does not need to know
the exact position. Though I will give lip service to the standard RDBMS
requirement of not needing to recompile.) I do have just one question.
If a DBA decides to move a field to another or new table, does not the
program need to be re-written to reference it? Or does the DBA just spend
a few hours dropping & re-adding tables & views?
Bryan Buchanan
> [snipped]
>
>ACID=Atomicity+Consistency+Isolation+Durability
>
>* Atomicity: All changes made in a database transaction are either
> all applied (committed) or none of them are applied. Not so in Pick.
>
>* Consistency: A programmer may ensure application consistency by placing
> together in one database transaction all the updates/inserts which
> logically fit together. [Arguably limited support is provided for this
> by some Pick databases.]
>
>* Isolation: Database changes are invisible to other users until committed.
>
>* Durability: Once database changes are committed then they are
> GUARANTEED to be on the disk. And can be safely backed up.
Does anyone know of any good references on how these things are
implimented by a DBMS ?
In a situation where you have, say,
Application --> Database Manager --> O/S file buffers --> hardware disk cache
at what point is the transaction "guaranteed" to be on the disk ?
Bryan
Jeffrey W. Janner
Jeffrey W. Janner
--
Rich Ahrens
: Some body wrote in this long thread that a PICK system is not ideal when 24
Well, I can't resist commenting, as I knew this site and application
pretty intimately in a previous life. They used to run Reality with
transaction logging and a P-LAN switch. Essentially, they had a hot
backup machine with a replicated database that they could fall back on
if the the primary system failed. (Some non-critical users ran on each
and would be displaced if the fail-over required.) I would really like
to hear how they are accomplishing this with Unidata. I suspect they are
doing the replication at the application level now, as the VAR was
working on that at one time to gain independence from Reality's superior
functionality. (Gee, I wonder why?) That could certainly be done with
Unidata. But how are they doing consistent backups?
The point I would make is that you can't assume that just because this
is a life-critical, round-the-clock application the database they've
chosen is appropriate to it.
Jackie Burhans
: Is TP/RFS something I turn on and make mandatory for the whole database
: or would I turn it on application program by app. program? In other
: words will one legacy program risk my tables being broken upon a power
: failure?
You turn RFS on for the whole system. You can then enable it on a file by
file basis by creating or declaring the file to be "recoverable" you can
add TP syntax to your application programs as you like. So no having
one legacy program will not break the whole thing.
: Does TP/RFS impose restrictions on the programmer? I.e. Can s/he still
: code as before without breaking TP/RFS? If s/he uses READ and WRITE
: instead of SQL is TP/RFS broken?
The TRANSACTION BEGIN/END statements can bracket READ/WRITEs. Any any code
without these statements works as before.
: In Oracle Direct I/O is provided via SQL. The best available index(es)
: are always used.
Hmm. I guess that I wasn't thinking of SQL *as* direct I/O.
: > : Pick can perform better than Oracle in certain restricted queries.
: > : But for flexible ad-hoc reporting a PROPER relational database will
: > : ALWAYS beat a record-based keyed database like Pick.
: > Why?
: Because a truly ad hoc query is unlikely to be via the key.
Yes...but you can query a Pick or UniData database table by non-key
attributes which can be indexed. And the result set if you have multi
valued fields will display all the header/detail info withh one read.
Maybe I'm not understanding your perspective?
: > The quote we use is:
: >
: > Relational databases ... were never meant to provide the intensive data
: > synthesis, analysis and consolidation that are provided by multi-dimensional
: > databases. Source:E.F. Codd & Associates Computerworld, July 1993
: Aha! Multi-dimensional databases: What makes anyone think Pick is
: a multidimensional database? How many dimensions does Pick cater for?
: If a relational database is two-dimensional then Pick is (at best)
: four-dimensional (values and sub-values). Four is hardly multiple!
Gee four seems multiple to me. Of course two, strictly speaking is multple.
: But before you say 4 is better than 2 read on: What are good examples of
: multi-dimensional databases (MDDB)? IXI is one and MD2(?) is another.
: What is so good about them? Well one feature is that you can choose to
: look at the MDDB from different perspectives. Hold the 5th dimension
: constant and slide thru the others. Another query comes along - look
: at your data from another axis. Pick doesn't provide for this. In Pick
: the data can only be viewed from one "angle". The multi-values & sub-
: values are fixed in their association with each other and the other
: attributes.
: Pick only allows you one perspective on the 4 dimensional data. To
: obtain another perspective you must re-organise the data resulting
: in a different key structure & the grouping of different attributes into
: multi-values fields.
Well I'm just not sure I understand the distiction you are making.
Perhaps you could give a specific example. In terms of looking at stuff
from different perspectives UniSQL allows you to access multiple tables
on the fly joining by non-key attributes including multi-valued ones.
Too darned many perspectives if you ask me.
: The Pick data model isn't normalised! The Relational data model is
: normalised! What does this mean? Relational data can be viewed
: from another perspective without re-writing the data in a different
: format to obtain efficient queries because the data is already
: normalised. But nevertheless a RDBMS does not have the flexibility
: or efficiency of a Multi Dimensional Database when it comes to allowing
: the user to dynamically select another "angle" on his/her data.
: Oracle is not a MDDB. And neither is Pick.
You can store data in a completely normalized form in Pick/UniData etc.
Doesn't oracle now come with a multi-dimensional add-on component?
: Codd is being taken out of context. Codd did NOT say: "The Pick data
: model is superior to the Relational data model." And Pickies who think
: he did have horizons so narrow that they don't know what a MDDB is!
No Codd didn't mention Pick specifically. In another book on databases
Codd or maybe C.J.Date was asked about nested relational databases and
databases with multi-valued fields. An interesting dialog followed
where he (whoever he he was) ceded that they were interesting had some
advantages but couldn't quite get to the point of advising people to
use them. Something like Recent Database Writings was the book, I was
checking the index for nested relational.
[oops snipped my own question about Oracle CLUSTER stuff]
: Yes! But I thought you Pickies thought that that was a good idea!
Right. Maybe I was too subtle. If Oracle clusters stuff to denormalize and
prejoin tables and that is a good thing why isn't multivalued/subvalued
a good thing since it effectively stores the data as "materialized joins"
: But better than Pick the data is manipulated as if it were in distinct
: tables and looks as if it is in distinct tables yet internally the
: tables are pre-joined. This allows the DBA to pre-join where necessary
: for performance reasons without requiring program changes! Pick like
: features without the Pick-style hang ups.o
Yay, Pick-like features!
: For example: It is a piece
: of cake to insert a set of parallel multi-values in an Oracle cluster:
: Just INSERT the set in one statement. Not in Pick: LOCATE followed by an
: INSERT for each multi-value. :-(
Can also do this nicely with UniSQL.
: I have criticised Unidata as if it were Pick. Undeservedly, it would seem.
: Sorry.
No harm taken. No harm done.
: But does the Unidata SQL INSERT statement work on multi-valued data yet?
Did it not before? I checked the manual (a rare effort for me) and Insert
supports multi-values as does UPDATE, DELETE and SELECT and does so quite
intelligently I am pleased to find (not that I ever doubted it but SQL is
not my native language so I had to check.
: > Jackie Burhans
Rich Ahrens
: : Not as an available product. The last I asked, it had not even been
: : decided what release would include it. It is definitely not available on
: : 3.3.2, according to at least two of your VPs.
: Not 3.3.2 we do have a site I believe implementing it on a beta basis. Again
Which was my point. Your original statement didn't sound like a future
but indicated an existing capability in the released product. And as of
yesterday or the day before, it is not close to being released.
: If you take my *two* statements together, I stand by this. What I was
: trying to say is that any query will use the indexes if it can. The if
: it can part is based on these self-optimizing algorithms. These rules are
: documented in the manuals.
Not in the ones I have. At any rate, what I'm trying to understand is
the difference between Oracle and Unidata in this respect. Unidata is
extremely limited in the manner in which it will use an alternate key
index in a query. Paul has made some sweeping statements as to Oracle's
widespread use of its indexes, and I'd like to know if it is any better
at using them.
: : SELECT HISTORY BY DATE BY CUSTOMER
: My understanding in general from the engineers is that if you sort a
: field and that field is indexed (that means its already stored in
: sorted order essentialy via the Btree) we will use the index to assist
: in the sort. Is that what you were getting at? or did you mean having
: one select folow another? In which case see below.
I meant, given that explicit UniQuery statement, with indexes on either
or both of the dictionary items used, Unidata will *not* utilize the
index(es). I am told that the parser determines there is a sort on more
than one attribute and, whether or not using an index would speed up the
process, it won't use one.
: : SELECT HISTORY WITH DATE BETWEEN "01/01/94" "12/31/94"
: I believe this *will* use the index. The general rule is that we will
: use one index field to do the initial select (which one, first
: available from left to right with a preference for a condition with "="
: rather than ">" etc.) Additional conditions will be resolved by reading the
: record and examining the data. The exception is if its that same data field
: and you are doing a "between" type function. If perchance I am mistaken
: about BETWEEN working (and I'm so rarely wrong...) than certainly the
: following will work:
: SELECT HISTORY WITH DATE >= XXX AND DATE <= yyy
: which gives the same functionality as BETWEEN.
Yep, they're identical, and no, the last time I tested the index was not
used.
Richard Williamson
> : : ACID=Atomicity+Consistency+Isolation+Durability
> : : * Atomicity: All changes made in a database transaction are either
> : : all applied (committed) or none of them are applied. Not so in Pick.
> : Perhaps not in Pick but yes, so, in Unidata.
>
> If specifically coded with transaction semantics.
Sounds like a four bit way of saying the programmer must use begin/end
statements to identify the set of writes that are to be included in a
transaction. Is that what you meant? If so, is that not true of all
transaction processing systems? How else is the TP manager to know what
constitutes a transaction?
--
Richard Williamson - Portland, Oregon - ri...@europa.com
Lee J. Krawczyk
have worked consistently for five years on projects using INFORMIX,
Sybase, PICK, and PICK-likes. I have done no work with ORACLE. The
differences that I have found between RDBMS and post relational are
these.
1) Any application developed in RDBMS takes at least three times
longer to achieve.
2) Every application that came up where I could compare the two
database technologies on even ground ran slower when using RDBMS.
3) The money people are willing to spend to maintain their RDBMS
solution vastly outweighs the post relational solution expense.
I won't waste anybody's time debating the advantages and disadvantages of
one over the other. For me post relational has always made sense whereas
RDBMS seems to be the long way around the mountain.
The biggest difference which no one can debate is the marketing money
(advertising) that has gone into RDBMS. I think that if AT&T had picked
up PICK rather than UNIX in the beginning we'd all be wondering about
UNIX's viability today rather than PICK's.
In the meantime, I'll continue to make an excellent living supporting
RDBMS.
Lee J. Krawczyk
Multi-User Solutions Information Consortium, Inc.
(dba MuSIC)
Phoenix, AZ 85048
Phone: (602) 460 - 1805
FAX : (602) 894 - 8105
Email: ye...@imap1.asu.edu
Jackie Burhans
: Which was my point. Your original statement didn't sound like a future
: but indicated an existing capability in the released product. And as of
: yesterday or the day before, it is not close to being released.
using it so I thought it was further along.
: : it can part is based on these self-optimizing algorithms. These rules are
: : documented in the manuals.
: Not in the ones I have.
I know I've seen it written down on paper. I used to teach courses for Unidata
and have *taught* these evaluation rules. So I checked and found it listed in
the ED100 (Overview of Unidata) course manual. I have an email into the Product
Information to ask if they are hiding it in one of their manuals or if they
would like to add it. If you or anyone else is interested in the rules I would
be happy to fax you a copy of the 5-6 pages.
[oops I accidentally deleted your example but I think it looked like this]
SELECT HISTORY BY F1 BY F2
: : My understanding in general from the engineers is that if you sort a
: : field and that field is indexed (that means its already stored in
: : sorted order essentialy via the Btree) we will use the index to assist
: : in the sort. Is that what you were getting at? or did you mean having
: : one select folow another? In which case see below.
: I meant, given that explicit UniQuery statement, with indexes on either
: or both of the dictionary items used, Unidata will *not* utilize the
: index(es). I am told that the parser determines there is a sort on more
: than one attribute and, whether or not using an index would speed up the
: process, it won't use one.
This one is tough for me to test so I have a question in to the indexing
engineer. You have piqued my interest. Alas he confirms your statement--the
above SELECT statement does not use the indexes. He claims it would not be
an advantage to how sorts are handled now.
: : : SELECT HISTORY WITH DATE BETWEEN "01/01/94" "12/31/94"
: : I believe this *will* use the index. The general rule is that we will
: : use one index field to do the initial select (which one, first
: : available from left to right with a preference for a condition with "="
: : rather than ">" etc.) Additional conditions will be resolved by reading the
: : record and examining the data. The exception is if its that same data field
: : and you are doing a "between" type function. If perchance I am mistaken
: : about BETWEEN working (and I'm so rarely wrong...) than certainly the
: : following will work:
: : SELECT HISTORY WITH DATE >= XXX AND DATE <= yyy
: : which gives the same functionality as BETWEEN.
: Yep, they're identical, and no, the last time I tested the index was not
: used.
Hm. I don't know how you tested by I tried on our demo CUSTOMER file
with DATE_OUT as and indexed field:
SELECT CUSTOMER REQUIRE.INDEX WITH DATE_OUT >= "03/29/94" AND
DATE_OUT <= "04/24/94"
And the query was executed. If no index was used the query would not
execute at all. There is no way for me to make UniData tell be its using
the index for both parts of the query but this is what the engineers tell
me it does. The idea is if you start to traverse a B-Tree you can quickly
get to the first value ("03/29/94") and keep traversing the nodes til you
get to the last value ("04/24/94").
Did you try something different and/or have different results?
Jackie Burhans
Paul Beardsell
jwja...@tamu.edu "Jeffrey W. Janner" writes:
> In article <810719...@sambusys.demon.co.uk>, p...@sambusys.demon.co.uk wrote:
>
> [lots of pontificating deleted]
>
> * Oracle automatically rolls back uncommitted transactions upon failure
> of a program. Upon the rare (i.e. "never" happens) Oracle failure
> uncommitted transactions are automatically rolled back upon the
> database being brought back up. Same for O/S, machine or power failure.
> Pick does none of that except it fails more often!
>
> Excuse me, but this is a load of whooey! My former company had 100's of
> Pick-based installations that all-together failed less times is 6 months
> than my wife's Oracle database did in two weeks. And it sometimes took
> her more than 8 hours to get the databasse back up and useful.
Such experience is not typical. I have lots of experience of both Oracle
and various flavours of Pick and the Oracle RDBMS is 100% reliable IN MY
EXPERIENCE. [There are some bugs in the tools and in the reportwriter but
they don't effect the reliability of the RDBMS and they all have work-
arounds.] Sure I have heard of some experiencing Oracle problems but
they are not TYPICAL. Unusual would be a better word.
On the other hand I have worked alongside some of the most talented
Pick people in the UK in Pick, Ultimate and UniVerse and each site
experience strange, repeatable AND random problems with the DATABASE.
Never mind bugs in Basic or Proc or Access etc: None of those Pick
environments has had a reliable DATABASE.
Admittedly my Pick involvement reduced dramatically two years ago
so I am unaware of recent improvements to UniVerse or Unidata. But
some of the features being claimed by Unidata and UniVerse are not
yet released! Never mind compliance with the ACID properties: In
the pub the other day I heard yet another horror story re UniVerse
secondary indexes! And Unidata SQL still cannot properly update
items with repeating groups!
Don't tell me about the as yet unreleased versions. All the features
of Oracle that I have been discussing in this and other
threads (such as ACID, Clusters, etc) are established features that have
proven their reliability over years!
> * If at any time the app or o/s or machine or power fails before a
> transaction is finally committed then all the data remains unchanged.
> E.g. If an application (say, a banking money transfer program) fails then
> one must make sure that every debited amount has been credited and
> vice versa. In Oracle one simply puts each maching DR and CR in one
> database transaction. How does one ensure this with Pick? You call
> in the support programmer to check.
>
> * While the above application is running a customer phones in and asks
> for the balances of his accounts. An enquiry is run. The answer is:
> "In account A $1000 dollars and in account B $500." But the customer
> knows that he has $2000! What has gone wrong? The above application
> is busy transferring money from account A to account B. The application
> is written in Pick! If the application were written in Oracle the
> debit would not be visible until it had been committed ATOMICALLY with
> its corresponding credit. (Atomicity! Consistency!) Not even locking
> the records helps in Pick - a record is only locked against WRITE - you
> can still read the effects of a transaction before it is complete.
> Note that in Oracle no locking would be specified by the Programmer -
> the database would do it all. But the "before image" would never be
> locked! What does that give you? CONCURRENCY!
>
> More whooey! Many, if not most, implementations of Pick are starting to
> support some for of transactioning. Plus server, such as universe,
> support a shared-READ lock such that if someone has a record locked for
> WRITE then the readers wait for completion. Now...
In Oracle proper concurrency is provided by the database without the
need for the programmer to specify locking. The default action of
the database is enough, mostly.
> ...tion. Now on to the general locking
> question? How does one insure that the user is applying the correct
> change based on the data? Scenario: User A reads account 123 with balance
> $200, User B reads 123 with $200 balance and adds $100 to it. User A then
> deducts $50 from the account. What is the new balance? ($150 or $250, or
> some other figure?) Or does Oracle just up-chuck and make use A have to
> redo all his work?
The above question is just dealt with differently in Oracle. A paradigm
shift is required. The following statements can be submitted in any order
or simultaneously and Oracle will ensure that the end result is the same.
[Of course, if the balance of the account is less than 50 and User A's
transaction is attempted first then it will fail.]
User A:
UPDATE ACCOUNT SET BALANCE = BALANCE - 50
WHERE BALANCE >= 50
AND ACCOUNT_ID = 'FRED';
COMMIT;
User B:
UPDATE ACCOUNT SET BALANCE = BALANCE + 100
WHERE ACCOUNT_ID = 'FRED';
COMMIT;
> [snip]
>
> > Why is a marketing manager making I.S. decisions? Hmmmm... Oh well, just
> > a favorite rant of mine.
>
> He is looking for advice. More power to his elbow, say I. Pity
> you will not provide the _impartial_ advice he is looking for.
> Worse than that: Misinformation is what you supply.
>
> You really missed the point of the original comment, didn't you! (but
> since you're probably a marketing guy yourself, that's understandable).
> His point was why is a non-technical person attempting to make a
> technical decision that will most likely affect whether the business
> prospers or fails?
> (oops, just noticed you claimed to be developer below. Sorry if the above
> is a slight.)
I am a developer but, unlike you, I wouldn't look down my nose at
marketing people. Indeed, if you and other Pickies are to be
believed, it is only good marketing that Pick has lacked. Marketing
is often defined as the "positioning of product". What has failed
Pick? Its positioning or the product?
> [...snip...]
>
> Pick can perform better than Oracle in certain restricted queries.
> But for flexible ad-hoc reporting a PROPER relational database will
> ALWAYS beat a record-based keyed database like Pick.
>
> Sounds like your saying that R-DBMS are not keyed. I seem to recall that
> you have to provide a primary key for every table in Oracle. Am I wrong?
> The method of access and storage may be a little different, but you still
> have to get at the row (record), often via the primary key, eventually.
Yes. You are wrong. Relational purists don't like it but the Oracle
database does not insist that a table has a primary key or any key at all.
But if you designate a column or combination of columns to be a key and
you later change your mind and wish to designate another column(s) as the
key then just do so - no change to application programs required.
> Pick provides faster development? Pah! Why are there no Pick
> entrants in the rapid development contest currently being advertised
> in this and the other database newsgroups? The tools provided by
> Oracle (Forms, Reports, Graphics, Browser) are perhaps not the best
> available but they're a damn site nicer and easier than anything
> available for Pick. System Builder? Visual Basic and Hyperstar?
> All of those are pretty appalling!
>
> I'll admit that the tools are scarce and possibly of less than stellar
> quality. However, most are attempting to "bolt-on" some kind of SQL-like
> or industry standard protocol that was developed for SQL databases and not
> Pick databases, thus being hampered by the limitations of the protocol.
> Of course, when you have tons of monetoary resources to throw at your
> development, you generally get a better product. (Kinda makes you wonder
> why Oracle's are reputed to be so bad?)
I keep my ear to the ground and have not been aware of such a reputation.
Certainly they cannot be said to be BAD. And they make a load of other
tools look rather damned sick!
> [...snip for space...]
>
> "Real world data"? What is that? Since when is the real world
> anything like ASCII? Because that is what we store in our databases.
>
> Uh, "rwd" is what your attempting to store and having to code into ASCII.
> The purpose of DBMS is to "emulate the real world" as close as possible.
> That was Codd's intention in developing the relational model and the
> normalization rules. (go look it up)
If that were their intention then why didn't they end up with the Pick
data model? :-)
> [...final snippage...]
>
> The author made some valid criticisms of Pick-like databases, but some of
> them with obvious ignorance of the current Pick market. Judging from his
> comments, he hasn't dealt with Pick in over 10 years. Yes there is still
2 years actually
> plenty of room for improvement in the database and hopefully, now that the
> "great-god" is no longer with us, perhaps there can finally be some
Who? Dick Pick? Blasphemy alert!
> movement forward. Perhaps the warind Pick vendors can start fighting over
> their measly share of the DBMS market & start cooperating again to develop
> and improve some standards (like at least supporting all of SPECTRUM).
> They need to wake-up and realize that the enemy is not the other Pick
> vendors out there, but the hordes of R-DBMS vendors out there and the
> general trade press (who generally promote the hell out of the latest
> *neat, new* trendy thing, whether there's any real benefit or not).
> Lastly, perhaps they could try to get some coverage in some college
> textbooks, so that people will know there are other options that SQL and
Even the Pick vendors are promoting SQL.
> ancient IBM databases.
Yeah. In the meantime we'll live on the empty promises by Pick vendors
of wonderful functionality that never gets delivered or, if it does, it
doesn't work.
> BTW: I once developed a university transcript system using a RDBMS that I
> later realized I could have developed in half the time using a Pick-like
> database and it would have run faster by about a power of 10. The ...
But you're knowledge of how simple transaction processing (see above
example) means that perhaps you didn't do it PROPERLY.
> ... The RDBMS
> took about an hour just to do all the joins, etc. associated with just
> starting up every morning. Admittedly, this was about 10 years ago when
> RDBMS was still in it's infancy. They've since added indexes and a better
> query language so it would probably be faster now (but it would have
> needed to be re-written). Remember, a lot of changes have occurred in the
> PICK market it that time frame as well.
Oh no they haven't! You yourself call for the Pick vendors to DO something.
> --
> Jeff Janner | "Nothing is foolproof to a
> jwja...@tamu.edu | sufficiently talented fool." - Anon
By their sigs let them be known. - Paul Beardsell, late 20th century.
--
Paul Beardsell SAM Business Systems Ltd
~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
pbear...@cix.compulink.co.uk London, N1-6BN, UK.
p...@sambusys.demon.co.uk (+44 or 0)171 608-2391
Henry Eggers
: : : relational? What are the attributes of a good database? A good
: : : database satisfies all the ACID properties. Unidata does not.
: : : What are the ACID properties?
: : Ahem. Unidata 3.3 supports Transaction Processing with a Recoverable File
: : system which DOES provide for FULL ACID compliance.
: : Any query to a Unidata table will use the index automatically if one
: : exists: Unidata will choose to use a certain index over another or even
: : not use an index according to a set of self-optimizing algorithms. Direct
: : I/O via UniBasic will not use the index unless you code it to do so. I
: : don't know what facilities for direct I/O are allowed in Oracle.
: *Any* query? According to what I've been told and have confirmed with
: testing, that's a long way from reality. You're limited to one key per
: select to be able to use indexes, and the select cannot be based on a
: list so you can't do it in multiple steps to get around that limitation.
: Assuming DATE and CUSTOMER are indexed attributes, the following won't
: use the indexes:
: SSELECT HISTORY BY DATE BY CUSTOMER
On MDIS 7.3 this will be selected by index, if the index is constructed
on the key " BY DATE BY CUSTOMER", which can be done, because an index
can be constructed based on any selection and collation sequence
specifiable in English.
: SELECT HISTORY WITH DATE BETWEEN "01/01/94" "12/31/94"
On MDIS 7.3 this will be selected if there is an index on DATE.
: GET-LIST CURRENT.MONTH
: >SSELECT HISTORY BY DATE
This could be done, but probably isn't, by traversing the index, and
checking each record key for presence in 'current.month'. The complexity
is related to the GET-LIST ; T-LOAD ; considered here a few months ago:
The complexity is N**2, while retrieving the specified items and sorting
them is MlnM, where M < N or M << N. Therefore, MlnM << N**2 in general.
If, on the other hand, we _knew_ that the 'current.month' was generated by
SELECT HISTORY WITH DATE > "31 AUG 1995" and < "30 SEP 1995", then
SSELECT HISTORY WITH DATE ... BY DATE, given an index on Date, should
be instant.
Regards, hve.
Henry Eggers
: Some body wrote in this long thread that a PICK system is not ideal when 24
: hour availability is needed. Well, refer to the position announcement below:
: >Unidata Pick Programmer needed to continue maintaining and developing
: >software used by 911 fire/ems dispatch and fire records personnel. This
: >position is available immediately. Working environment is relaxed and
: >secure. Position requires experience in Pick programming and preferably
: >experience with interfacing to other vendor equipment. E-mail interest to
: >PH...@aol.com.
: I pass this along without comments.
Oh, well. These sites originally ran on dual Pegasus MDIS machines with
transaction logging between them and automatic switch-over if anything
bad happened.
["Anything bad" is a fairly broad category here. Basically there
was a 'box' between the two machines, which would sense that each machine
was up and operating 'normally', because each machine would tell it every
(user configurable) second. 'Normally' included (user configurable) disk
errors per unit time, and lots of other silly stuff which, blessedly, slips
my mind.]
The arrangement autoswitched the lines, made the secondary machine
'consistent' and told the operators to restart their current 'transaction'.
[This has been extended on CORA successors to take the users back to the
last field entered, to avoid the case of the same constable going two
places at the same time, or having two constables go to the same place.]
The same application was also sold on Sequoia's, which are a bit more
non-stop. :-) And I am _presuming_ that this is the same application,
migrated to Unidata, rather than another instance.
Paul wrote that Pick machines had to be shut down for the save. This
seems to have been a UK aberration. I don't know of anyone in the US
who shut down to do the save, other than doing it in off-hours, or who
felt a need to restore weekly, or who felt a need to have the machine
automatically restore after the save -- unattended, and no matter how
much mayhem had gone on during the save, without anyone noticing....
Historically, the machine was saved with people running, except in the
case of an intended restore, which are necessary about once ever six
months, presuming enough disk space and reasonable allocations. The
problem wasn't that there might be an ambiguity on the tape, when the
machine crashed hard at 5PM the next afternoon. The problem was the
loss of a whole day's work.
The 'solution' to this problem appears to me to be the redundant saving
of all updates somewhere else -- like tape. It is convenient that this
allow 'transactions' and the semantics of transactions for use in
application programming. [If EXEC SQL COMMIT WORK isn't a 'semantic'
in the application program, I'm hard put to think of what might be.]
This requires that the file save be started with no transactions open.
It would be convenient if there were no 'long' transactions about in the
application. The transaction tape needs to be marked with 'file save
start'. Then run both. To restore, restore the save tape, and then
run the transactions from the 'file save start' point. The issue is
that the file save will have already saved some items before they
were updated, and others after, so that transactions will not be
consistent. Simply making all updates over the top of the saved
data, which were made during the save, in order, should generate the
desired result, including roll-backs: Roll-backs have to be logged
as updates if the 'after' image is visible on file, and is therefore
on the save tape. The availablity of Roll-backs depends on the
Transaction system retaining the 'before' and 'after' images until
commit or abort.
The point is then to keep the transaction tape running, in order to
be able to bring the machine back to the point where it crashed.
In passing, I would note that incremental save is of marginal utility: The
time problem of the save was disk access, not tape writing. It is the
case that incremental save allowed running the whole save to one tape.
The approach which we took was to put the last update date on all items,
preserve earliest and newest date in the STAT-FILE entry for each file,
make SAVE a TCL-II verb: SAVE * or SAVE <account-list>; and partition
the machine into active and archived.
So, as far as I'm concerned, these things are 24-hours-a-day and consistent.
Regards, hve.
Jeff A. Schasny
>
>In article <jwjanner-110...@ppp02-08.rns.tamu.edu>
> jwja...@tamu.edu "Jeffrey W. Janner" writes:
>
>> In article <810719...@sambusys.demon.co.uk>, p...@sambusys.demon.co.uk wrote:
>>
>> [lots of pontificating deleted]
>>
>> * Oracle automatically rolls back uncommitted transactions upon failure
>> of a program. Upon the rare (i.e. "never" happens) Oracle failure
>> uncommitted transactions are automatically rolled back upon the
>> database being brought back up. Same for O/S, machine or power failure.
>> Pick does none of that except it fails more often!
>>
>> Excuse me, but this is a load of whooey! My former company had 100's of
>> Pick-based installations that all-together failed less times is 6 months
>> than my wife's Oracle database did in two weeks. And it sometimes took
>> her more than 8 hours to get the databasse back up and useful.
>
>Such experience is not typical. I have lots of experience of both Oracle
>and various flavours of Pick and the Oracle RDBMS is 100% reliable IN MY
>EXPERIENCE. [There are some bugs in the tools and in the reportwriter but
>they don't effect the reliability of the RDBMS and they all have work-
>arounds.] Sure I have heard of some experiencing Oracle problems but
>they are not TYPICAL. Unusual would be a better word.
Perhaps your "experience" is somewhat colored by the fact that you sell
the thing???... MY experience, and that of MANY others (judging from the
mail I have received lately) supports Mr Janner's views on this subject
rather that yours.
[SNIP]
>In Oracle proper concurrency is provided by the database without the
>need for the programmer to specify locking. The default action of
>the database is enough, mostly.
>
The statement above is utter bullshit... and you are being knowingly misleading
Mr Beardsell (or you are woefully ignorant, which I doubt). If concurrency
is to be insured at the database engine level, by means of constraints, the
constraints must be implemented (i.e. programmed) by someone. The "default"
action of the database engine on a table without constraints is to allow
updates and/or inserts without regard for any logical concurrency.
[SNIP]
>> "Real world data"? What is that? Since when is the real world
>> anything like ASCII? Because that is what we store in our databases.
>>
>> Uh, "rwd" is what your attempting to store and having to code into ASCII.
>> The purpose of DBMS is to "emulate the real world" as close as possible.
>> That was Codd's intention in developing the relational model and the
>> normalization rules. (go look it up)
>
>If that were their intention then why didn't they end up with the Pick
>data model? :-)
Because they were trying to create a theortical mathmatical model rather
than a system for managing data, and they did a rather nice job of defining
their mathmatical model. The problem came when some idiot actualy tried to
implement this as a DBMS.
[SNIP]
>> took about an hour just to do all the joins, etc. associated with just
>> starting up every morning. Admittedly, this was about 10 years ago when
>> RDBMS was still in it's infancy. They've since added indexes and a better
>> query language so it would probably be faster now (but it would have
>> needed to be re-written). Remember, a lot of changes have occurred in the
>> PICK market it that time frame as well.
>
>Oh no they haven't! You yourself call for the Pick vendors to DO something.
>
>> --
>> Jeff Janner | "Nothing is foolproof to a
>> jwja...@tamu.edu | sufficiently talented fool." - Anon
>
>By their sigs let them be known. - Paul Beardsell, late 20th century.
>
>
You know, your "nah-nah, it's so because I say it is" attitude is just a bit
less obnoxious than your (admitted) ingorance of the products which you attempt
to berate. Universe, Unidata, and yes even Pick from Pick systems are viable
products which are regularly selected for their ability to allow companies to
run their business with the minimum of information systems expense, and the
maximum information systems performance. If you wish to continue extolling the
virtues of the relational model to groups of uninformed amatures who will
undoubtably believe you, by all means do so. Just dont try to convince those
of us who know better, because you invariably come out looking like a fool.
OBTW... your little personal sniping pisses me off too... so, to put it in a
phrase I'm sure you hear often... bugger off, you insolent twit.
Jeff
--
===============http://www.rmii.com/~jschas=============================
Jeff Schasny : jsch...@alert.com : "They say time loves a hero,"
Berger & Co. : jsc...@rmii.com : "but only time will tell"
Denver, Colorado : jsc...@aol.com : - Lowell George
======================================================================
Jackie Burhans
: Admittedly my Pick involvement reduced dramatically two years ago
: so I am unaware of recent improvements to UniVerse or Unidata. But
: some of the features being claimed by Unidata and UniVerse are not
: yet released! Never mind compliance with the ACID properties: In
: the pub the other day I heard yet another horror story re UniVerse
: secondary indexes! And Unidata SQL still cannot properly update
: items with repeating groups!
delivered. On-line Backup--not quite yet :-S
Now about Unidata SQL being unable to properly update items with
repeating groups--please give more info. Do you have a specific
example of something you tried to do but couldn't , think it should
do but doesn't? I would really like to know. Perhaps this is old information
and I can check in the current version whether all is well. My
recent experience with SQL and repeating groups in Unidata looks
very promising, would love to apply it to your problem.
: Even the Pick vendors are promoting SQL.
UniData has supported SQL since version 1; it support it even
better in version 3.3.2--very possibly even to handling updates
with repeating groups! :-) SQL certainly is a standard for database
query and especially important for connectivity. And yet still even
so there are additional options...
Jackie Burhans
Unidata, Inc.
I speak only by myself
Martin Taylor
p...@sambusys.demon.co.uk "Paul Beardsell" writes:
[snip]
>
> On the other hand I have worked alongside some of the most talented
> Pick people in the UK in Pick, Ultimate and UniVerse and each site
> experience strange, repeatable AND random problems with the DATABASE.
> Never mind bugs in Basic or Proc or Access etc: None of those Pick
> environments has had a reliable DATABASE.
>
I have no wish to get involved in the arguments here except to say
that *I* have never heard of this person :).
The above paragraph, as a general statement of *problems* is a gross
misrepresentation.
Why Mr Beardsell contributes to cdp beats me.
--
Martin Taylor (Author of "Pick for Users")
Datamatters Ltd
13 Market Place, Heywood, Lancashire, UK
+44 (0) 1706 625478 fax +44 (0) 1706 625740 mar...@dmatters.demon.co.uk
Jeffrey W. Janner
Well, let's see what I remember of the app. A "master" student file and a
file containing their grade reports. Reporting requirements: semesterly
grade reports with GPR & overall GPR. Kinda hard to screw up this design,
eh?
--
Jeff Janner | jwja...@tamu.edu
Windows 95 is like a Centauri. It's very stylish, relatively powerless, and tends to fall over a lot.
Paul Beardsell
Let's examine Isolation.
User 1 User 2
=================================== ==================================
1) begin transaction
2) update taba set col1 = 'Z'
where col2 = 'X'
3) end transaction
4) begin transaction
5) update taba set col1 = 'Y'
where col2 = 'X'
6) begin transaction
7) update tabb set coly = 1 where 'Y' =
(select col1 from taba
where col2 = 'X')
8) end transaction
9) rollback
Assuming Unidata supports rollback does Unidata hide the update
in step 5 from the subquery in step 7 ?
--
Paul Beardsell SAM Business Systems Ltd
~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
pbear...@cix.compulink.co.uk London, N1-6BN, UK.
p...@sambusys.demon.co.uk (+44 or 0)171 608-2391
Paul Beardsell
jwja...@tamu.edu "Jeffrey W. Janner" writes:
We can do withdrawal examples if you like but my example is a transfer.
> } The above code would give the greatest concurrency. Note that the database
> } does the necessary locks and that until the COMMIT is executed no one
> } else can see the UPDATEs - they see the "before image".
>
> So the teller sees the *before* image that says he has enough money and
> give him more, even though the above update may bring the balance below
> available funds?
> At least under Pick you could display message, if necessary, that an
> update was pending, please wait for completion. ('Course we're talking
> banking here, were most of the updates are still posted in "batch mode"
> around midnight, even if you deposit cash.)
In an on-line, real time transaction processing environment you want to
keep the lock current for the shortest possible time so as to allow the
greatest concurrency.
In my Oracle application NEVER will the program say "sorry, record is
locked". But we could have hundreds, nay thousands, of concurrent
transactions. Try doing the same in Pick.
In my example the way of getting the greatest thru'put is to allow
the update to barf and rollback when a balance is insufficient to allow
the transaction. As only a small proportion of transactions will be
for an amount which is too large this is much better than reading and
locking every record before the update. We rely upon ACID to look
after the mechanics of the transaction in the most efficient way
and we treat attempted overdrawing of an account like the exception
it really is.
> } The following is equivalent functionally but is less efficient
> } (more database accesses, locks held longer and therefore worse
> } concurrency). And the following is typical of that written by those
> } moving to Oracle from environments such as Pick:
> }
> } int Transfer( acct_a, acct_b, amount)
> } {
> } EXEC SQL WHENEVER NOT FOUND GOTO NO_SUCH_ROW;
> } EXEC SQL SELECT BALANCE INTO :balance
> } WHERE ACCOUNT_ID = :acct_a
> } FOR UPDATE OF BALANCE; /* <-- sets lock */
> } if( balance <= amount) {
> } EXEC SQL ROLLBACK WORK;
> } return FAIL;
> } }
> } EXEC SQL UPDATE ACCOUNT SET BALANCE = :balance - :amount
> } WHERE ACCOUNT_ID = :acct_a AND BALANCE >= :amount;
> } EXEC SQL UPDATE ACCOUNT SET BALANCE = BALANCE + :amount
> } WHERE ACCOUNT_ID = :acct_b;
> } EXEC SQL COMMIT WORK;
> } return SUCCESS;
> } NO_SUCH_ROW:
> } EXEC SQL ROLLBACK WORK;
> } return FAIL;
>
> Personally, I prefer this version. It explicitly states what is being
> done and the casual reader understands what is happening. (I'm assuming
> that the ROLLBACK is taking care of releasing the lock?)
SQL and RDBMS requires a different approach. When translating from
German to French, say, you can not just translate each word and
forget about word order, grammer, common phraseology. No matter
how good a German speaker you are, you have to take time and effort
to learn French and perhaps one day you might be a judge of good French.
Similarly when moving from Pick to Oracle.
And to carry the French / German example one stage further: France
and Germany are each full of bigots who consider their own native
literature superior.
> --
> Jeff Janner | "Nothing is foolproof to a
> jwja...@tamu.edu | sufficiently talented fool." - Anon
--
Paul Beardsell
bur...@rainbow.rmii.com "Jackie Burhans" writes:
> Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
[many lines deleted]
> : Pick only allows you one perspective on the 4 dimensional data. To
> : obtain another perspective you must re-organise the data resulting
> : in a different key structure & the grouping of different attributes into
> : multi-values fields.
>
> Well I'm just not sure I understand the distiction you are making.
> Perhaps you could give a specific example. In terms of looking at stuff
> from different perspectives UniSQL allows you to access multiple tables
> on the fly joining by non-key attributes including multi-valued ones.
> Too darned many perspectives if you ask me.
The "NF2" model allows a four level many-to-one relationship
to be maintained in the data. key -> attribute -> value -> sub-value.
as long as the view of the data required is the top down approach
convenient to that model then, yes, I agree, Pick provides
an efficient access path to the data. But as soon as one
wants to maintain a 5 level structure then the Pick data model
does not cope anymore. And a "normalisation" process must
occur to get the data into a Pick database. Multi-dimensional
databases do not suffer this restriction. Often Pick is said
(and this is often said here in this newsgroup) to offer a real-
world-like data model. Since when is the real world a top-down
four-level hierarchy?
The point of the above argument is that Pick suffers from the
same normalisation issues as does Oracle. Pick allows a hierarchy
to be modelled and so does Oracle. Oracle allows efficient joins
(clusters) on common attributes which can be defined at will
by the DBA. Oracle does not have a rigid view of what the key is,
Oracle can define its hierarchy either bottom-up or top-down as
the spplication programmer decides and Oracle can model exactly
the same data structures as Pick by using clusters.
> : The Pick data model isn't normalised! The Relational data model is
> : normalised! What does this mean? Relational data can be viewed
> : from another perspective without re-writing the data in a different
> : format to obtain efficient queries because the data is already
> : normalised. But nevertheless a RDBMS does not have the flexibility
> : or efficiency of a Multi Dimensional Database when it comes to allowing
> : the user to dynamically select another "angle" on his/her data.
> : Oracle is not a MDDB. And neither is Pick.
> You can store data in a completely normalized form in Pick/UniData etc.
> Doesn't oracle now come with a multi-dimensional add-on component?
Is that a criticism of Oracle :-)
> : > Jackie Burhans
> : > Technical Account Manager
> : > Unidata, Inc.
--
Paul Beardsell SAM Business Systems Ltd
~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
pbear...@cix.compulink.co.uk London, N1-6BN, UK.
p...@sambusys.demon.co.uk (+44 or 0)171 608-2391
Paul Beardsell
> Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
[many lines deleted]
> : But does the Unidata SQL INSERT statement work on multi-valued data yet?
> Did it not before? I checked the manual (a rare effort for me) and Insert
> supports multi-values as does UPDATE, DELETE and SELECT and does so quite
> intelligently I am pleased to find (not that I ever doubted it but SQL is
> not my native language so I had to check.
Well, seeing that you have consulted the manual and to help explain
to me how multi-value SQL inserts work:
Key: BLOGGSF Employee code
Attr 1: 101A]202B]303C Multi-valued list of courses
Attr 2: A\A\B]A\C]C\A Grades achieved in course
Fred Bloggs now attends course 404D. Two assignments were given - he
received a B for one and a C for the other. What is the SQL to update
the table?
Obviously, ']' denotes a value mark and '\' a sub-value mark. And
it would be considered cheating to use either in the SQL, would it
not?
> : > Jackie Burhans
> : > Technical Account Manager
> : > Unidata, Inc.
--
Paul Beardsell SAM Business Systems Ltd
~~~~~~~~~~~~~~ 21 Finn House, Bevenden St,
pbear...@cix.compulink.co.uk London, N1-6BN, UK.
p...@sambusys.demon.co.uk (+44 or 0)171 608-2391
Paul Beardsell
r...@winternet.com "Rich Ahrens" writes:
> Jackie Burhans (bur...@rainbow.rmii.com) wrote:
> : Rich Ahrens (r...@winternet.com) wrote:
> : : Jackie Burhans (bur...@rainbow.rmii.com) wrote:
> : : : Unidata provides for on-line backup.
> : : Not as an available product. The last I asked, it had not even been
> : : decided what release would include it. It is definitely not available on
> : : 3.3.2, according to at least two of your VPs.
> : Not 3.3.2 we do have a site I believe implementing it on a beta basis. Again
>
> Which was my point. Your original statement didn't sound like a future
> but indicated an existing capability in the released product. And as of
> yesterday or the day before, it is not close to being released.
All of the Oracle features I have mentioned in this thread are well
established.
> : If you take my *two* statements together, I stand by this. What I was
> : trying to say is that any query will use the indexes if it can. The if
> : it can part is based on these self-optimizing algorithms. These rules are
> : documented in the manuals.
>
> Not in the ones I have. At any rate, what I'm trying to understand is
> the difference between Oracle and Unidata in this respect. Unidata is
> extremely limited in the manner in which it will use an alternate key
> index in a query. Paul has made some sweeping statements as to Oracle's
> widespread use of its indexes, and I'd like to know if it is any better
> at using them.
I'm not too familiar with Unidata. But I stand by all that I've written
re Oracle's use of its indexes.
Paul Beardsell
heg...@netcom.com "Henry Eggers" writes:
> Ian McGowan (i...@netcom.com) wrote:
> : Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
> : [much stuff, mostly unarguable, cut]
> : : * While the above application is running a customer phones in and asks
> : : for the balances of his accounts. An enquiry is run. The answer is:
> : : "In account A $1000 dollars and in account B $500." But the customer
> : : knows that he has $2000! What has gone wrong? The above application
> : : is busy transferring money from account A to account B. The application
> : : is written in Pick! If the application were written in Oracle the
> : : debit would not be visible until it had been committed ATOMICALLY with
> : : its corresponding credit. (Atomicity! Consistency!) Not even locking
> : : the records helps in Pick - a record is only locked against WRITE - you
> : : can still read the effects of a transaction before it is complete.
> : : Note that in Oracle no locking would be specified by the Programmer -
> : : the database would do it all. But the "before image" would never be
> : : locked! What does that give you? CONCURRENCY!
>
> : Uh, what if the customer withdraws money from A while this is happening?
> : Do you check twice, once at the start and then again before COMMIT'ing? Or
> : am I missing something totally obvious...
>
> You freeze the whole database during the lookup, obviously.
No you don't. Not in Oracle. That would be required in Pick. But
are you referring here to Oracle or Pick, Henry?
> ACID is
> theoretically nice, but has it's costs. The problem really arises out
> of the fundamental that Oracle and Pick are principally useful as
> shared databases. The Pick 'solution' to the cost of concurrency has
> been to be 'a bit vague' -- not unlike, I would observe, the real world.
Once again I don't know if this is tongue in cheek. Is the vagueness
of the real world really something we should implement in the control
of concurrency of a database?
> The SQL database solution 'requires' concurrency at a theological level,
I'm glad the 'requires' is in quotes. The "theological level" is at
least achievable with an RDBMS because of its foundation in
relational algebra. Although some have tried the NF2 model does
not avail itself to mathematical analysis quite as easily. And
certainly NOT how it is often implemented in Pick. But I like
"theological". The sinning priest is at least possible. But the
saintly gangster?
> although the ODBC engine allows 'degrees' of concurrency. The above problem
Which ODBC engine? There are many vendors of these.
> is made livable by means of indexing and taking copies of rows selected,
> so that the length of time the relevant parts of the database need be
> frozen is minimized. Similarly, the update side can update the new
> copies of the rows to disk, and then freeze the database while writing
> pointers to them. In this context, the strategy of having a lot of tables
> is probably useful, presuming that 'most' operations can take place against
> only one locked table, giving other processes a lot of other things
> to look in.
>
> At the opposite end, there is the Pick 'list', which assumes that the
> database will not change from the creation of the list until its final
> use. I wonder how we have all survived its use all these years?
>
> : Just for the record, has anyone reading converted from oracle|sybase|
> : informix _to_ pick or a pick-a-like? Or know of anyone who has?
>
> Sure would simplify things.
>
> Regards, hve.
Paul Beardsell
Mar...@dmatters.demon.co.uk "Martin Taylor" writes:
> In article <811338...@sambusys.demon.co.uk>
> p...@sambusys.demon.co.uk "Paul Beardsell" writes:
> [snip]
> >
> > On the other hand I have worked alongside some of the most talented
> > Pick people in the UK in Pick, Ultimate and UniVerse and each site
> > experience strange, repeatable AND random problems with the DATABASE.
> > Never mind bugs in Basic or Proc or Access etc: None of those Pick
> > environments has had a reliable DATABASE.
> >
> [snip]
>
> I have no wish to get involved in the arguments here except to say
> that *I* have never heard of this person :).
I have a letter from you written only three months ago re
ascii faxes. A follow up to email contact.
> The above paragraph, as a general statement of *problems* is a gross
> misrepresentation.
Not in any large Pick or Pick-like site where I have worked. As far
as I am aware there is no cause and effect relationship :-)
> Why Mr Beardsell contributes to cdp beats me.
It beats me too. I stopped for quite some while. But then I happened
by chance across the original posting of this thread and the its first
reply. By the way, the original poster has phoned me since to thank
me for correcting some of the misleading propaganda in that original
reply.
But thanks for the "contributes". Such a pity some other participants
in this thread seem unable to contribute.
You can ignore me if you wish. Indeed, your newsreader can
probably be taught to do so.
> --
> Martin Taylor (Author of "Pick for Users")
> Datamatters Ltd
> 13 Market Place, Heywood, Lancashire, UK
> +44 (0) 1706 625478 fax +44 (0) 1706 625740 mar...@dmatters.demon.co.uk
--
Paul Beardsell
> Perhaps your "experience" is somewhat colored by the fact that you sell
> the thing???... MY experience, and that of MANY others (judging from the
> mail I have received lately) supports Mr Janner's views on this subject
> rather that yours.
Well, I can only sell you Oracle if you buy one of our applications.
We CHOOSE to write our applications in Oracle. The other director of
SAM Business Systems and I both come from a Pick background but via
other environments and each of us has an academic interest in computing.
We KNEW there had to be something better than Pick. Of the two of
us I was the bigger Pick enthusiast and it took me a little longer
to appreciate Oracle. I would never go back now. And "back" it
would be!
But many Pickies believe they have found the Holy Grail. Pick is
almost a religion to them. One day I will have cause to say the
same thing to Oracle die-hard enthusiasts. But not yet.
I'm not claiming any great insight or priveleged position. But I'm
not a Luddite either. A consistent and realistic position for Pickies
might be:
"Pick has its faults but I like it and I'm good at it
and I earn a living from it."
But that isn't the attitude of some here. It's: "How dare
you criticise the software that I love!" :-)
[SNIP]
> [SNIP]
> >In Oracle proper concurrency is provided by the database without the
> >need for the programmer to specify locking. The default action of
> >the database is enough, mostly.
> >
> The statement above is utter bullshit... and you are being knowingly misleading
> Mr Beardsell (or you are woefully ignorant, which I doubt). If concurrency
> is to be insured at the database engine level, by means of constraints, the
> constraints must be implemented (i.e. programmed) by someone. The "default"
> action of the database engine on a table without constraints is to allow
> updates and/or inserts without regard for any logical concurrency.
Not true. I've not even mentioned Oracle's database constraints or
triggers. I'll repeat the statement again.
"In Oracle proper concurrency is provided by the database without the
need for the programmer to specify locking. The default action of
the database is enough, mostly."
In Oracle the application programmer need not explicitly lock a
record yet the database NEVER allows one transaction to trample over
another. No special action is needed when the tables are set up.
It is the implementation of ACID that allows this.
When in the mid 80's I explained to those stuck in old computing
environments about the benefits of Pick they looked at me as if
I were crazy. What? Hashed access by alphanumeric key? The editor
works on the data? Variable length fields? Sub-values? Portable
to many different machines? English-like query language?
They didn't think it was possible.
Now it's the mid 90's and things have moved on. Without you.
I am not responsible for the eclipsing of Pick by RDBMS. [But I wish I
were :-) ]
> OBTW... your little personal sniping pisses me off too... so, to put it in a
> phrase I'm sure you hear often... bugger off, you insolent twit.
I'm sorry that you are so frustrated at losing this argument. Next time
you're in England please feel free to pay me a visit. I look forward _so_
much to meeting you face to face.
> Jeff
> --
> ===============http://www.rmii.com/~jschas=============================
> Jeff Schasny : jsch...@alert.com : "They say time loves a hero,"
> Berger & Co. : jsc...@rmii.com : "but only time will tell"
> Denver, Colorado : jsc...@aol.com : - Lowell George
> ======================================================================
--
Martin Taylor
p...@sambusys.demon.co.uk "Paul Beardsell" writes:
> In article <812050...@dmatters.demon.co.uk>
> Mar...@dmatters.demon.co.uk "Martin Taylor" writes:
>
> > In article <811338...@sambusys.demon.co.uk>
> > p...@sambusys.demon.co.uk "Paul Beardsell" writes:
> > [snip]
> > >
> > > On the other hand I have worked alongside some of the most talented
> > > Pick people in the UK in Pick, Ultimate and UniVerse and each site
> > > experience strange, repeatable AND random problems with the DATABASE.
> > > Never mind bugs in Basic or Proc or Access etc: None of those Pick
> > > environments has had a reliable DATABASE.
> > >
> > [snip]
> >
> > I have no wish to get involved in the arguments here except to say
> > that *I* have never heard of this person :).
>
> I have a letter from you written only three months ago re
> ascii faxes. A follow up to email contact.
Okay, I rise to the bait.
Yes, I remember now. "heard of" would be more properly described as "know of
by technical reputation". Important to point out that the email was from you
to me and not unsolicited email from me to you. You were interested in
developments that my company had carried out re ascii fax, presumably
because this was a capability you did not have. By the way, do you have this
capability from Oracle?
>
> > The above paragraph, as a general statement of *problems* is a gross
> > misrepresentation.
>
> Not in any large Pick or Pick-like site where I have worked. As far
> as I am aware there is no cause and effect relationship :-)
>
Perhaps you haven't worked with some of the most talented people in the UK in
Pick then, which was the phrase which prompted me to reply. What *cause* and
what *effect*? There is, IMHO, a definite correlation between the success or
failure of an installation and the quality of the personnel who design and
implement it. I am not impressed by unsubstantiated generalisations. Equally
I am not impressed by your arguments for Oracle which are lacking definition
in an academic sense. This, despite the possible merit of your arguments,
substantially detracts from your case. A specific example of a banking
application which can be adequately coped with in your Oracle example whilst
it might not be in other environments, Pick or non-Pick, is only an argument
for Oracle in that specific example. It merely suggests a basis for an
appropriate choice for an appropriate example. I certainly would not suggest
that Pick is a panacea for all computer applications. For instance, if
someone suggested that Pick be used to control a nuclear power station, I
would want to emigrate, probably to Mars. Then, the same would be true if
the choice were Oracle.
Your case *may* have technical merit, but you have only weakly stated it here.
The most important point is not discussed. This is the relative
cost-effectiveness of the two systems. In a comparison of Unidata and Oracle,
Unidata wins easily. I learned a long time ago that *commercial* considerations
far outweigh any technical consideration. Most smaller organisations simply
do not have the resource to afford the 100% reliability that you allege comes
with Oracle. Maybe some larger organisations using Oracle would be a lot more
efficient if they did not. Picktype applications would not be so widely used
if they were as ineffective as you suggest.
To substantiate *my* case:
Case 1: Two large UK banks which entrust their entire telesales operations
to Pick systems.
Case 2: A multi-site textile company with about 100 Picktype systems using
them for their mainstream administrative computing. These systems range
from small 3/6 user systems to enormous Data General/Universe systems with
hundreds of users linked via kilostream.
Case 3: Ditto another one.
Case 4: A multi-site insurance agent administering ALL of their public
business on over 200 Picktype systems.
Case 5: Some of the largest car hire fleets in the UK handling their telesales
and administrative systems, one running over 100 users on a PENTIUM.
Just a selection of my customers, a humble, small systems house based in the
backwoods of Lancashire. I think that they think they have a reliable
database. I know they think that they have effective computing resources.
For all of them their Pick investments give them definite competitive
advantages.
> > Why Mr Beardsell contributes to cdp beats me.
>
> It beats me too. I stopped for quite some while. But then I happened
> by chance across the original posting of this thread and the its first
> reply. By the way, the original poster has phoned me since to thank
> me for correcting some of the misleading propaganda in that original
> reply.
>
You obviously have Pick interests which continue. What I wish is that you
were a tad more positive. The tone of your discussions almost amounts to
a crusade to persuade people to stop doing what they believe in and do
what you now believe in.
> But thanks for the "contributes". Such a pity some other participants
> in this thread seem unable to contribute.
>
> You can ignore me if you wish. Indeed, your newsreader can
> probably be taught to do so.
>
Perhaps I have too cynical and commercial view, I believe it is in my
interest to contribute positively to cdp. Perhaps egotistically I believe
that it is in readers of cdp's interests that I contribute.
I don't think it is my interest to contribute negatively. Although I am
interested in *your* contrasting experiences with Oracle and Pick.
What do you get out of it?
Paul Beardsell
p...@sambusys.demon.co.uk "Paul Beardsell" did write:
> In article <43a834$h...@natasha.rmii.com>
> bur...@rainbow.rmii.com "Jackie Burhans" writes:
>
> > Paul Beardsell (p...@sambusys.demon.co.uk) wrote:
> [many lines deleted]
> > : But does the Unidata SQL INSERT statement work on multi-valued data yet?
> > Did it not before? I checked the manual (a rare effort for me) and Insert
> > supports multi-values as does UPDATE, DELETE and SELECT and does so quite
> > intelligently I am pleased to find (not that I ever doubted it but SQL is
> > not my native language so I had to check.
>
> Well, seeing that you have consulted the manual and to help explain
> to me how multi-value SQL inserts work:
>
> Key: BLOGGSF Employee code
> Attr 1: 101A]202B]303C Multi-valued list of courses
> Attr 2: A\A\B]A\C]C\A Grades achieved in course
>
> Fred Bloggs now attends course 404D. Two assignments were given - he
> received a B for one and a C for the other. What is the SQL to update
> the table?
>
> Obviously, ']' denotes a value mark and '\' a sub-value mark. And
> it would be considered cheating to use either in the SQL, would it
> not?
>
> > : > Jackie Burhans
> > : > Technical Account Manager
> > : > Unidata, Inc.
Well, what about it, Jackie? Maybe Unidata can cope with this now.
It would sure be nice to told it can.