I like Rick's point about metaphors here. Regardless how expressive a model may be, the set of tools provided by a DBMS does tend to influence the way we model. The basic data type in LISP (List Processing) is the list, and it is no great surtprise that a LISP programmer will be more likely to think about a problem in terms of (nested) lists than a C programmer. Similarly, MUMPS arrays are different from C arrays or Perl hashes, and the basic abstraction supported by the language DOES influence they way MUMPS programmers "see the world". But whether, the basic tools you have available are lists, array, decorated trees (globals) or relations, you are able to express and work with structures much more complex than those directly supported by the language.
There is reason why there are so many programming languages out there, even if they are computationally equivalent, and that is some make tasks of a certain type easier. Similarly, there is no "right" database model. The relational model has been tremendously successful, and is in some ways the database analog of Algol-like programming languages (Algol/68, Pascal, Ada, C, ...) which have been similarly successful and influential in the theory of programming languages. But the relational model no more renders other models (such as the Fileman model) irrelevant or useless, than Pascal renders Scheme or Haskell irrelevant. --- Greg Woodhouse <[EMAIL PROTECTED]> wrote: > > > --- "Frederick D. S. Marshall" <[EMAIL PROTECTED]> wrote: > > > Dear Matthew, > > [...] > > > > All databases exist to record an abstract model of pieces of the > > world. > > Databases are usually structured as files (or tables or classes), > > each > > of which lists entities of a similar kind, such as patients, or > > drugs, > > or visits. Just as the file represents a category of entities, so > > each > > record (or entry or row or object or instance) in that file > > represents a > > specific entity, such as a specific patient, a specific drug, or a > > specific visit. Databases, files, and records are not the real > > things > > they represent, only abstract representations of them. An entry in > > the > > patient file is not a real patient, but an abstraction of a > patient, > > a > > metaphor for that patient. Very much as with poetry, the more > > closely > > that metaphor matches the important parts of the real thing it > > represents, the more powerful the metaphor, the more meaningful, > and > > from the perspective of medical informatics, the more likely it is > to > > > > assist in improving patient health. Whether you have the right > > information and whether you have organized it into the right > metaphor > > is > > largely dictated by how that information will be used--that tells > you > > > > which operations can be inefficient and which need to be efficient, > > > which tells you how to balance the tradeoffs that are always > > involved. > > > > A good database designer chooses apt metaphors that match well the > > kinds > > of information the clients need to record. The strategic part of > > that > > choice involves selecting the right database paradigm; the tactical > > part > > is using that paradigm effectively. WHICH data a file records is > up > > to > > the file designer, but HOW that data is stored is up to the > database > > paradigm you choose (relational, hierarchical, network, > polymorphic, > > object-oriented, etc.). As with successful adaptation in nature, > the > > > > secret to success lies not with rigid orthodoxy but with responsive > > > flexibility, varying your approach to let each problem dictate its > > own > > best solution. > > > > I find it useful to think in terms of data types. I believe that what > you are saying here is that it is important to abstract away from the > primitives used to implement other types. Just as pointers are the > basic primitive used in a language like Pascal to implement abstract > data types, tuples and relations are the basic primitives used in the > relational world to model other structures. I believe it is > unnecessarily narrow (and in fact, a caricature of the relational > model) to think of the table as the basic *abstraction* of this > model. > That would be like saying pointers and subfiles are the basic > abstractions with which one works in Fileman. That's just not true. > They are *primitives* used to model abstractions that can be quite > complex. > > Think about this way: Bricks and mortar may be used to construct > buildings (well, maybe not out here in earthquaqke country), but when > an architect looks at a building, (s)he does not see (just) brick and > mortar. There is much more that can be said about buildings than > simply > that they are built out of certain fundamental components. > > > [...] > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Without the requirement of mathematical aesthetics a great many > discoveries would not have been made." > > -- Albert Einstein > > > > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Without the requirement of mathematical aesthetics a great many discoveries would not have been made." -- Albert Einstein ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
