Re: DB clasical structure violation

In article <5CAC48A24F99EC7B.A2D0D2DB02DCE6A9.51744061EC86DF74_at_lp.airnew s.net>, Chuck Schuelke <cesjr_at_airmail.net> writes
>I have worked with PICK from a structured point of view, the advocates
>statements are not incorrect, but if you want to move data in or out
>it is incredibly difficult. in general because of the ease of use,
>think access, changes are made, not documented, no way to trace back
>to what was origiinally envisioned. for example i have a text field
>for name, the users decide it would be better to put social security
>number in there, ok, there it is. this is real world, not
>theoretical. this discussion is highly theoretical in the sense that
>it does not address how real users use this "flexibility".
>
>This whole thread is nonsense because no responsible company would
>select pick based on todays environment. i invite anyone other than
>Anthony W. Youngman to respond to this. lets see how many supporters
>he has for this great product. PICK is a flexible mess, if you choose
>to go there good luck.

Well, I'll reply anyway :-)

And I would agree with you only too strongly about people deciding "oh we'll put the user's social security number in the name field". *BUT* how would *you* stop this in SQL? You've just declared "name" to be a text field. How do you stop the user putting any old crap in there? otoh you *can* stop users putting text into numeric fields like price, for example. Been there, done that, sworn blue murder at the silly idiot who's caused 10 times more problems than he's solved.

Oh. And as for "no responsible company would choose Pick", I gather (from sources within IBM, no less), that there are several *big* companies who would be most upset if their competitors found out they were using Pick. They reckon Pick is one of their strongest competitive advantages. Don't forget that study I've referred to in the past - comparing like-for-like companies, the companies using Pick spent about half the average on maintaining their databases.

And no responsible company would select MS Excel. But I'm sure you know of hundreds of database apps written in Excel (mostly by the accounts department :-) And no sensible programmer would choose C as a general purpose programming language... the fact is, C is a disaster in the hands of a novice, and an amazing tool in the hands of an expert. The same for Pick. Pascal makes bad programming difficult. It also makes excellent programming difficult! And SQL is just the same. The same features that make bad programming hard also interfere with good programming. What's the saying? Something about making a good servant but a bad master?

And lets refer to the thread where the OP wants to store a dictionary for password stuff. That's a *large* working dataset he's got, and Pick will just kick the living daylights out of SQL given the data/hardware combination he's got. There's just *no*way*whatsoever* that SQL stands a snowballs chance in the Sahara of coming anywhere close for performance. Not unless the poster spends loads of money to upgrade his hardware. A wonderful quote from the Pick FAQ ... "SQL optimises the easy task of finding the data you want once it's already in ram. Pick optimises the hard task of getting it from disk into ram in the first place".

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let 
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett