Re: Database in Redhat Linux

In message <F125wMfgZUr3CrJRxKZ00006f1c@hotmail.com>, Obnoxio The Clown <obnoxio@hotmail.com> writes >From: "Anthony W. Youngman" <wol@thewolery.demon.co.uk> >> >>Network, hierarchical, post-relational, object, ... > >Mmm...I fall over them, wherever I go. Relational is ubiquitous :-( > >>You mean your systems have extra-sensory perception and the data entry >>fields will appear immediately you've finished your ALTER TABLE? Oh, and > >Is that in System Builder? Or is Pick BASIC prescient? I got the impression that your systems were prescient. Why not Pick BASIC too :-) > >>by the way, in the time you've typed your ALTER TABLE, I've done an ED >>DICT and updated my metadata. While you're waiting for your ALTER TABLE >>to return from rebuilding the table and making space for your new >>fields... WHAT - you need to rebuild the table? What an absolute waste >>of time!!! I just alter the metadata and table access takes the new > >Actually, I don't. It's called in-place alter. The table gets altered as and >when each row gets touched or evaluated, so ALTER TABLE can take no time at >all. Well, I did say I was being rude about SQL on things that have now been optimised out... and I gather they use the same trick to do that as Pick has used for years... Playing catch-up with us as usual :-) > >>information into account. And when you discover that your system analyst >>got the spec wrong so you've fed 3 months worth of CHAR,20 data into a >>CHAR,10 field - hang on! You still have such archaic features as field >>length! And while you're desperately trying to recover all that lost > >Archaic? I'm a big fan of strong typing, myself, but being a BASIC >programmer, you clearly wouldn't be. Untyped variables are a double-edged sword. It's damn useful being able to multiply an integer by 10, just by concatenating a nought on the end, until you find some twit put a real in the field :-) I'd love the *ability* to type variables, I just don't want to be forced into it. Something I learnt very early as a FORTRAN programmer - the FORCE_DECLARE_ALL_VARIABLES parameter is damn useful... :-) > >>data, you get users asking you to run off special reports... Hang on >>again! Any half-intelligent user can run off their own reports on our >>system - it's not that difficult and you don't need a Masters in set >>theory to work out what data is in which table and how they relate >>together... > >You mean like Business Objects or Brio or Cognos or...? What do you mean? We just use INFORM, or ENGLISH, or whatever Informix/U2 calls the standard command-line query language. It's dead simple. Try getting an end user of a relational database to run an ad- hoc query over three or four entities, with a many-many thrown in for good measure... > >> >Performance is not everything. >> > >>It is when your web site is under load and customers leave because the >>system isn't responding. It is when your customer support staff are > >And this website would be? Well, our website (okay it's SQL-Server - rubbish I know) slows to a crawl with 200% CPU as soon as it gets more than 2 or 3 people on it... I don't happen to know of many sites run on Pick, but that seems to be the same problem the AS/400 has. It's just there, works flawlessly and never gets noticed. Things like doze, SQL, even nix, force themselves upon you because they never work quite right, so they get all the attention :-( > >>tearing their hair out because all their queries take 5 mins with the >>customer on the phone. And I agree, performance isn't everything - our >>system typically doesn't need DBAs, only needs half the programmers for >>a given size of database (and they usually earn half as much :-(, and >>the typical company typically spends half the percentage of revenue on >>its DP department than does a SQL-based company (the average co spends >>4% of revenue on IT - our average co spends 2%). So it impacts the >>bottom line pretty heavily. Even more so, the typical programmer is far >>more business-analyst oriented. The biggest problem users have running >>requests past me is not getting me to approve the programming. It's >>getting me to approve the business model - the number of requests I >>throw out as "You don't want to do that. The results will be meaningless >>at best, and downright damagingly misleading at worst." > >Well, I'm pleased you think that SQL programmers aren't capable of making >the same comments. I must be something special then. I'm not saying you aren't. It's just that Pick programmers have a reputation for being business savvy - which SQL programmers don't have (that's not to say many aren't). As we found when we moved our CRM database from Pick to SQL - we're STILL debugging all the design flaws and this is three or four years down the road. Many of the problems were pointed out at design time, and just didn't make it into the spec :-( The guy who spec'd it was a PhD in maths and a brilliant programmer - he just didn't have the business ability. Most Pickies, if they've got qualifications, are business qualified - that's why so many Pick systems are genuinely bloody awful - the guys who wrote them were business men not programmers. Mind you, that's why they're also relatively easy to maintain - they may be spaghetti but it's business spaghetti not coder spaghetti. If that sort of person programmed in SQL the program would be binned within the year - most such Pick systems soldier on for years accumulating more and more cruft along the way. That pretty much describes our setup :-( > >Somehow your presentation of yourself as more of business analyst doesn't >quite gel with your stated problem above of the system analyst getting the >data structures wrong -- surely you'd have picked that up yourself? I'm >pretty sure I would have. I've never had to bother my head with the problem - field size to me is a meaningless concept. Output format, yes I do have to worry about that. But again, it's just a quick edit to the metadata. > >>Relational design is not a magic bullet. I've seen some bloody awful >>relational databases. And our Pick ones are pretty awful, too :-(. But >>build a Pick database app using relational theory and it will be easy to >>build, easy to understand, easy to maintain, and on hardware with any >>sort of resource constraint, it will blast the arse off of any >>competitor for its speed and response. > >Mmmm...scalability? What's your biggest site? Dunno. But Pick runs on some pretty big hardware - RS6000s and stuff like that. My site's only a 64-user licence, but Hill House Hammond (a reasonably large UK insurer) are a Pick site. O'Reilly run their accounts on Pick. There was a large music store roll out a while back on Pick... Would you run - would you EVER have run - a 30-user Oracle installation on a 486? Okay, that hardware is now way out of date, but that was a pretty typical installation in those days... We ran ours on a 33MHz processor, 16Mb RAM and 32 users (+ 32 remote users) at that time... > >>Breaking relational constraints just that little bit - you have two >>tables with a many-to-many relationship. Can you store the foreign keys >>together with t