Re: What's does oracle have that others don't?

Your Name <Yourname_at_somwhere.COM> writes:  

>having your corporate data rely on a PC, or you don't need a REAL database
>engine to keep up with your data. Can FoxPro or DBASExx have x,000's of
>users concurrently how about hundreds? I don't think so!! A PC can not
>have concurrent access of the SAME data, has no clue as to locking etc.
>Can DbaseIV or FOXPRO have hundreds of GB or even TeraByte databases? Try
>and manage that!
 

Generally, for corporate data, what you say is all true.  

However, some refinements need to be mentioned for "Personal Computer" databases:  

  Locking: Ever since MS-DOS 3.1, which became fully aware of remote

            networked disks, there has been the concept of "byte range locking"
            originally implemented using SHARE.EXE, or by the remote
            NETBIOS server.
 
            For "table per file" databases like DBase (a.k.a. XBase) and
            Paradox, this byte-range locking is used to lock individual
            records, and sometimes entire tables (files).
 
            For Microsoft Access (a single file database), "extended byte
            range locking" is used to lock various kinds of items,
            usually database pages.  "Extended byte range locking" means
            using "bogus" byte ranges beyond the end of the actual
            shared file (the .LDB file for Access) for locking purposes.
            Access calculates lock addresses as
            (LockTypeOffset + (PageNumber * MaxUsers) + UserNumber)
            where MaxUsers is currently fixed at 255.
 

  Multiple
  Users: As just mentioned, Microsoft Access has a fixed limit of 255

            users per database.  Due to file contention, the practical
            limit may be much lower, especially if many users are doing
            updates.
 

The key tradeoff to me between "legitimate" server database systems, like Oracle or SQL Server, and "file server" database systems, like Paradox and Access, is Robustness vs. Convenience:  

  Robustness:

            The "legitimate" database systems allow for "after-image journal"
            data to be written to a separate disk drive from the database data
            disks.  Combined with database backups to tape (or other disks),
            this protects COMPLETELY against any SINGLE point of failure
            in terms of disk crashes.
 
            The only way to provide similar protection for "file server"
            databases is to use a RAID disk system on the file server.
 
            In the future, ongoing continuous replication may replace
            the need for database backups.  Thus, this distinction may
            actually go away.
 
  Convenience:
            The "file server" databases can be stored on a salesman's
            laptop computer, and operated in stand-alone mode.
            At certain points in time, the salesman hooks up to the network
            and uses replication tools to resynchronize the laptop's
            database with a centrally shared database.
 
            The "legitimate" database systems are starting to offer
            "personal" versions, but these require more resources on the
            laptop computer than the "file server" databases.  Also,
            database administration is more complex for the "legitimate"
            databases.
 

Another issue is network traffic:  

  The "legitimate" databases use a higher level of request/response message:   entire SQL queries or even higher stored-procedure calls. The amount   of network traffic between client and server can be minimized by   thoughtful applications programming.  

  The "file server" databases generate much more network traffic per user,   since each request/response message happens at the level of each disk   page in the shared file. The program traverses indexes, for example,   by reading file pages over the network to the desktop computer,   then deciding which pages to read next, etc.   (The "legitimate" databases do all this on the server, and only return   resulting data rows over the network.)  

Summary:  

  For truly "corporate" or "enterprise" data stores, the "legitimate"   database systems win.  

  For distributed pockets of "departmental" or "workgroup" data,   the conveniences of the "file server" database have increasing appeal.   As RAID hardware technology and replication software technology improve,   and as network bandwidth increases, expect to see more situations where   the "file server" databases can be justified for localized data storage.  

  In fact, expect to see architectures that use both types of database   technology in various complementary combinations.    

• Rick --

(Rick Rutt is a system architect living and working in Midland, Michigan.) Received on Mon Jan 08 1996 - 00:00:00 CET