Re: Database in Redhat Linux
From: "Anthony W. Youngman" <wol@thewolery.demon.co.uk> > >Network, hierarchical, post-relational, object, ... Mmm...I fall over them, wherever I go. >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? >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. >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. >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...? > >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? >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. 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. >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? >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) >I would say that any database programmer should understand set theory >and the principles of SQL - it makes them a much better programmer - but >don't forget that the guy who invented SQL disowned it as crap within >two years! Unfortunately, it took off, in preference to its younger >sibling. Ubiquity # quality. I certainly don't believe that SQL is a panacea, but it *is* a standard (of sorts). Who among us believes that the original IBM PC was better than the Apple II or the Acorn BBC or the Amiga (or whatever floated your boat at the time)? Who doesn't remember that Beta was technically way ahead of VHS? Etc. And if we're saying ubiquity # quality, then that must make M$ really crap! :-) _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com