From: gus@progress.COM (Gus Bjorklund)
Subject: Re: Date's 12 Rules for DISTRIBUTED databases
Keywords: distributed database
Organization: Progress Software Corp.
Date: Wed, 30 Sep 1992 12:51:33 GMT

tcox@netcom.com (Thomas Cox) writes:

>Here is a re-posting of Date's 12 Rules, and my own evaluations as to
>how Ingres and Oracle stack up.  

Since Progress was not included, here are my observations (note that
I work at Progress Software, so my comments are self-serving):

>The quick score:  	Oracle 6, 6.0 rules (8 if you're generous)
>			Ingres,   6.5 rules (7 if you're generous)
>			Oracle7, 10.0 rules (10.5 if you're generous)

                        Progress 10.0 rules

>		DATE's 12 Rules for Distributed Databases


>Rule 0: A distributed database should look no different than a database
>that is not distributed.

>	v6 PARTIAL ('yes', but read-only)
>	v7 YES
>	Ingres YES
	Progress YES

>The implication here is that the *users* of the database, either people or
>applications, should be shielded from the fact of the database being
>distributed.  (Those databases that must hard-code data locations into
>triggers, i.e. Sybase, cannot truly be said to comply with this rule.  Note
>that Oracle v7 triggers avoid this error.)


>Rule 1: Local Autonomy; Local data is owned and managed locally
>with local accountability and security.  Local operations remain local and no
>site should depend on another for successful functioning.

>	v6 YES
>	v7 YES
>	Ingres NO
	Progress YES


>Rule 2: No Reliance on a Central Site; All sites must be treated as
>equals, with no reliance on a master site.

>	v6 YES
>	v7 YES	
>	Ingres NO
	Progress YES

>Note that this Rule is not a reference to a two-phase commit coordinator, but
>rather to the idea of a SINGLE central "daddy" machine.  Ingres*Star, for
>example, requires that one site be the "daddy" site that maintains a master
>list of all database objects and resources.  Thus, Ingres' latest product fails
>Rule 2; ORACLE versions 5, 6, and 7 all pass Rule 2.


>Rule 3: Continuous Operation; There should never be any need for a
>planned shutdown, so that installations at one site should not affect
>operations at another.  New installations should not affect existing
>programs, nor should removing a node from service cause interruptions in
>service.  Portions of databases should be able to be created and
>destroyed without stopping any component.

>	v6 YES
>	v7 YES	
>	Ingres PROBABLY YES
	Progress YES

>This is a reference to several features, such as site autonomy and the ability
>to activate or de-activate a node without having to take some central "daddy"
>database offline to be modified.  Any node can create or modify its own
>resources and need neither (A) register this with any central authority such as
>a central data dictionary, nor (B) shut down other nodes.


>Rule 4: Location Independence; Users should not have to know where data
>is physically stored and should be able to act as if all data were
>stored locally.

>	v6 PARTIAL (i.e. only if the read-only limitation is acceptable)
>	v7 YES
>	Ingres Yes in theory; NO in practice
	Progress YES

>Most commercial Ingres sites seem to have hard coded data locations into
>their applications, to avoid the network delays that Ingres' Master-
>Slave architecture forces.


>Rule 5: Fragmentation Independence; Relations between data elements
>should be able to be fragmented for physical storage.  Nonetheless,
>users should be able to act as if data were not fragmented.

>	v6 NO
>	v7 NO
>	Ingres PROBABLY NO
	Progress NO


>Rule 6: Replication Independence; Relations and fragments should be able
>to be represented at the physical level by multiple, distinct, stored
>copies or replicas at distinct sites, transparent to the user.

>	v6 NO
>	v7 PARTIAL
>	Ingres NO
	Progress NO

>(The V7 snapshot facility provides a partial solotion.  It allows for
>multiple read-only copies of a master table which are updated at a user defined
>interval.  Also V7 triggers and 2PC provide a partial synchronous replication
>facility.  The problem here is that you have to code your own in
>triggers, which is less elegant.)


>Rule 7: Local processing and input/output activity needs to take place
>at multiple sites, with some amount of data communications between them.
>Both local and global optimization of query processing should occur.

>	v6 PARTIAL
>	v7 PARTIAL (better)
>	Ingres PROBABLY YES
	Progress PARTIAL

>V6 does some query optimization.  V7's optimizer does a better job optimizing
>distributed queries.


>Rule 8: Distributed Transaction Management; Single transactions
>execute code at multiple sites, causing updates at multiple sites.

>	v6 NO
>	v7 YES	
>	Ingres YES
	Progress YES

>This covers the Transparent Two Phase Commit, the RPCs that are protected by
>2PC, Triggers and Stored Procedures that can have effects across sites.


>Rule 9: Hardware Independence; Distributed databases should be able to
>run on different kinds of hardware, with all machines participating as
>equal partners where appropriate.

>	v6 YES
>	v7 YES	
>	Ingres NO
	Progress YES

>Ingres does not allow equal partnership.  


>Rule 10: Operating System Independence; Distributed databases should be
>able to run under different kinds of operating systems.

>	v6 YES
>	v7 YES	
>	Ingres SOMEWHAT
	Progress YES

>Ingres Star was confined to VMS; it may have made it to some Unix
>platforms by now.


>Rule 11: Network Independence; Distributed databases should be able to
>work with different kinds of communications networks.

>	v6 YES
>	v7 YES	
>	Ingres PROBABLY YES
	Progress YES


>Rule 12: Database Independence; Distributed databases should be able to
>work with different kinds of databases, providing they have the same
>interfaces.

>	v6 PARTIAL read-only and using SQL*Connect
>	v7 YES	Foreign databases can be included in 2PC.
>	Ingres AT LEAST SOMEWHAT
	Progress YES - 2PC can include one foreign database

>Specifically, a 2PC coordinated by an ORACLE database can include one foreign
>database.  A 2PC coordinated by a Transaction Processing Monitor (TP Monitor)
>can include any number of foreign databases.

--
Gus Bjorklund              uucp:     ...mit-eddie!progress!gus
Progress Software Corp.    internet: gus@progress.com
14 Oak Park                phone:    6172804361
Bedford, MA  01730         fax:      6172804095
Newsgroups: comp.databases