Re: Database in Redhat Linux

In message <F898yfogkJXrRjbDt3H00006895@hotmail.com>, Obnoxio The Clown <obnoxio@hotmail.com> writes >From: "Anthony W. Youngman" <thewolery@thewolery.demon.co.uk> >> >>In article <8vmgld$om4$1@wagner.wagner.home>, Victor Wagner >><vitus@wagner.rinet.ru> writes >> >In comp.os.linux.misc Freelancer <someone@somewhere.world> wrote: >> >: I need decide which database going to run for Redhat Linux. >> >: I know MySQL is the most popular one in Linux world. I need >> >: you help me to fill out the blank and hole (?) in table below. >> > >> >Its a pity for Linux World, that most hype is done by people who don't >> >know what real database is. So they promote mySQL which is no more than >> >fast flat-file search engine with SQL-like syntax. >> >>And it's a real pity that there are so many people who think that the >>only valid type of database is a SQL database. > >Errrr....OK, so what is a valid alternative? Network, hierarchical, post-relational, object, ... > >>And to me, a database is a complete environment, aka AS/400, Pick, etc. >>A SQL back-end is to databases what the rear legs are to pantomime >>donkey - it can stand on its own but is useless without the other half. > >AS/400 uses DB/400, which is a relational database, isn't it? Or do you mean >the tin itself? So are we to infer then that an HP N-class is a complete >database environment? As I understood the AS/400, it came as a complete system, including database and tools. I don't know what comes with an N-class, but my company uses SQL-server, and I've tried to understand MySQL. Neither seem usable without a whole host of add-on extras - such as VB for SQL- Server, and similarly with MySQL > >> >So, only free database is PostgreSQL. But PostgreSQL start to >> >resemble real database only since 7.0 version, becouse before there was >> >no foreign keys. I would consider that it IS a database, not RESEMBLES >> >one only when it begin to support outer joins and binary large objects. >> >Both are scheduled for 7.1. >> > >>I think you mean the only free *relational* database - which is not the >>same thing at all. There are much better databases out there. While I >>would strongly suggest that all database programmers should know >>relational theory (it helps design immensely), there are a load of far >>better databases out there. SQL and relational databases put theoretical >>purity above practicality and functionality, which is why Oracle is such >>a beast - I could probably write programs that run faster, do more, and >>handle larger datasets, and all on a system half the size! just because >>I don't believe "relational is best". > >Well, off you go then. You're right, of course, until you deliver the system >and the customer says "wouldn't it be nice if...". You'll be cutting code >and restructuring everything manually long after I've said ALTER TABLE... You mean your systems have extra-sensory perception and the data entry fields will appear immediately you've finished your ALTER TABLE? Oh, and 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 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 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... > >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 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." And what database am I talking about? Actually, it's one owned by Informix, namely Pick (of which they own the U2 variant(s)). 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. 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...). And I know I've rather slagged off SQL above with things I don't understand, but those complaints are unfair about SQL because a lot of effort has been spent at optimising them away. They haven't been optimised in Pick because you can't optimise away a problem you don't have :-) I think you've been slagging off things you don't understand, too... Don't forget that Oracle, Informix, Microsoft et al are all busily trying to copy what we in the Pick community have had since the 60s! 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. Cheers, Wol. -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People.@@