Walt wrote:
> "DBMS_Plumber" <paul_geoffrey_brown_at_yahoo.com> wrote in message
> news:1172776674.096197.42640_at_k78g2000cwa.googlegroups.com...
>
>>On Feb 28, 10:37 am, Sampo Syreeni <d..._at_iki.fi> wrote:
>>
>>>[snip] Hence, the RM places little to no constraints on optimization.
>
> [snip]
>
>>I agree with Sampo's onservations, with one practical caveat.
>>
>>One principle objective of relational DBMS systems is to separate data
>>management from application code, allowing several applications to
>>share one database. This leads to situations where the DBMS is
>>implemented as one set of (operating system) processes, and the
>>application(s) in another(others).
>>
>>Most hierarchical systems--IMS, Pick etc -- share with many embedded
>>data managers -- Berkeley DB, etc -- the property that the data
>>management is co-resident with the application code in a single
>>process. By avoiding the cost of moving data between processes,
>>hierarchical data managers adopting this architecture gain
>>considerable response time and throughput advantages.
>>
>>That said, it doesn't amount to a hill of beans in practice. Business
>>flexibility trumps computer performance every time (so long as
>>performance meets some minimal, usually pretty low-bar, level).
>
> Hear, hear!
>
> I've never seen the above quite so well put, especially the part concening
> the minimal performance bar.
If we had true physical independence, even the process context switches
could mostly go away.
Received on Fri Mar 02 2007 - 17:30:40 CST
