Previous messages sum up the consensus on the article pretty well: just not up to TechRepublic's standards. In addition to the comments already posted, the writer has also confused the means of accessing records with the logical/physical structure of the database itself. No mention was made of the b-tree based index structure common to the current crop of DBMS's.
Database 101
" ..a database system is basically a computerized record- keeping system....(and which)consists of some collection of persistent data that is used by the application systems of some given enterprise". "The database management system is the software that handles all access to the database."
The above quotes are from CJ Date's "An Introduction to Database Systems" of 1995. The author was a db specialist at the IBM Santa Teresa lab in San Jose and was a prime mover in IBM's SQL and DB2 projects. It would be safe to assume that he knew what he was talking about.
Regarding types of structures there are Inverted List (Computer Associates by way of Applied Data Research. ), Hierarchic ( IBM's IMS is a still living and breathing example), Network (Cullinet's IDMS) or - roll of drums and hushed tones, Relational - to be used only if your database and DBMS conform more or less to Dr. E.F. Codd's rules.
A relational database could just as easily have an ISAM access method to get at indexes instead of the b-tree type of index structure that is in use today. And, as with any other type of database, if there is no index on the field you need to select on, you have no choice but to plough through your entire set of records containing that field before you can get anywhere.
It is a continual source of wonder to me when otherwise knowledgeable folks refer disparagingly to flat files. Like it or not, all the actual physical files are flat files: records variable or fixed in length are written one after the other on disk unless a hashed access mechanism is used. Sure, the records may be written as a series of pages on disk but this doesn't change the bottom line: to get at any record you need to know its starting offset position in the file or a page of that file. How you get to that vital piece of information - ultimately dependently on the indexing system itsef, is what really makes or breaks the whole system.
Once upon a time, the programmer could actually physically control the way disk space was allocated to a file to reduce access time. This now, if done at all, is a function of the underlying DBMS - assuming it can bypass the OS. I think now that all the DBMS itself can do is to preallocate space on disk to avoid fragmentation and the penalty this exacts on throughput.
This whole issue of what the OS allows the DBMS to do is becoming to me at least and probably IBM, Oracle, Sybase et al, an increasing concern when it comes to Microsoft's OS's. The anti-trust case settlement forced Microsoft to disclose a large number of undocumented API's that if known and used would positively impact the performance and capabilities of an application system.
I hope I'm wrong but nothing much was said about disclosure in future versions or after a certain period of time.
To put this in context, at present the physical disk and its controller itself simply just doesn't know from relational, hierarchical or whatever. At least, not until some otherwise sane disk manufacturer decides to put a DBMS into the firmware of the disk drive's controller. I don't know if I heard it right, but there was a rumor that Microsoft was a bidder for the hard drive business that IBM recently sold.
Can you imagine it: I'm sorry sir but you can't get a system with Longhorn aka WinLeapYear and SQL Server Version x unless you also get a Bighorn fixed disk from you know who. Any other disk, well, it just won't work. Be aware Microsoft, that if this idea lights your bulb I shall insist upon royalties.
Given this possibility and Microsoft's very visible thrust into the application business - CRM and the acquisition of Great Plains accounting stuff to name but two, its little wonder that IBM, Oracle and others are going flat out for Linux.
Just in case.
Who after all wants to develop software for a platform when you suspect that the maker of the platform may have put a governor on the top speed of the model you buy or not disclosed some other useful features, that will allow him to make his version substantially better than yours and which of course will only appear when you have established the market.
Perhaps that is Microsoft's real concern about the recent leak of its Windows source code. That someone will actually sift through it and discover references to undocumented API's.
It cannot possibly be can it because they think the Linux community will find something worth emulating. Maybe the leak was deliberate and had a darker purpose; taking a leaf out of SCO's book so that they can claim copywright infringement by Linux at some later date which they couldn't do if the source code had not been "published" in the first place.
Strange how events turn out. If Lou Gerstner, then CEO of IBM hadn't shot IBM and everyone else in the foot by killing OS/2 and publicly surrendering the desktop to Microsoft, the world today would be OS/2 and Micro who? But then again even though a vastly better OS than Windows ever was/will be, would Linux stiil have emerged but with a Goliath to face called IBM OS/2 instead of Microsoft Windows.
Makes you wonder.
