Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!elroy!cit-vax!ucla-cs!sdcrdcf!trwrb!scgvaxd!ashtate!cy
From: cy@ashtate (Cy Shuster)
Newsgroups: comp.databases
Subject: Re: Database implementation/theory issues?
Message-ID: <501@ashton.UUCP>
Date: 1 Mar 88 19:28:25 GMT
References: <33671UH2@PSUVM> <232@cullsj.UUCP> <725@smidefix.liu.se>
Reply-To: cy@ashtate.UUCP (Cy Shuster)
Organization: Ashton-Tate, Glendale, CA
Lines: 16
Summary: Let's define "records"

What is the specific meaning of "records" that causes problems here? Is it
the grouping together of third-normal data (physically and logically), or
is it the problem of "record definitions" with hierarchies, such as a date
composed of month, day, year subfields? (i.e., composite domains).

To my mind, there is an undeniable benefit of data independence in the rela-
tional model (allowing the application and the database to change indepen-
dent of each other), at the cost in many cases of lessened performance, from 
the underlying engine having to support arbitrary joins. It's perhaps akin
to assembler language vs. a higher-level one: a good programmer can make
impressive performance gains in assembler, at an increased maintenance cost.
By the same token, a good programmer can take advantage of knowledge of the
physical database layout, especially in a network system, for very good
performance. But changing the network means changing all the code. You pays
your money, and you takes yer choice.

--Cy--     dBASE Mac Development    UUCP:...seismo!scgvaxd!ashtate!cy