Re: Database in Redhat Linux
From: "Anthony W. Youngman" <wol@thewolery.demon.co.uk> > >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 :-) I thought you used SQL Server? >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... :-) Thanks for sharing. >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... Does INFORM or ENGLISH have a GUI? My users can't be arsed to actually do much more than click a "yes" button. > >> >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... Jeez, well, I think you're generalising an awful lot from one little site. >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 :-( Oh? I also think you're overglamourisng AS/400, I know plenty of sites with pain. And I've been on Pick sites with pain, too, for that matter. > >>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 :-(, [SNIP] > >>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 If they're that business savvy, how come they're paid less than market rates? :-) >(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 :-( And this is SQL's fault? > >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... And http://www.williamhill.co.uk, apparently. >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 Oracle, no, Informix absolutely. I've even run that many users on a 386. >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 the entities in the same table? Given a known key of one > >>entity, which has ten related entities in the other table, how many disk > >>reads do you need to get all the information? So I beat you on > >>simplicity - KISS - I have two tables to your three. I beat you on speed > >>- I need only eleven reads (maybe less, twelve if I'm unlucky) - you > >>need to either scan three tables in their entirety or scan two indexes > >>(I don't need any indexes so I don't have them - less to go wrong...). > > > >You don't have indexes? How do you enforce integrity? Or don't you care? > >(Not being stroppy, I don't really know) > >Notice I said I don't *need* indexes - _to find the record on disk_. To I don't _need_ the indexes for that either. But sometimes it makes things a little quicker. :-) _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com