Re: Database question ?
Date: Sat, 14 Aug 2004 09:45:14 +0200
>>>Q: How is data actually stored?
> A: The relational model model does not say.
> Am I missing something? <<
> You got it!! I can think of 4-5 SQL engines whose internal file
> designs are absolutely nothing in common.
> Teradata uses hashing and parallelism; An entire Nucleus database is
> one compressed bit vector space; SQL Server is still based on
> contigous physical storage; Sybase SQL Anywhere uses pointer chains
> from a PK to all the FK that reference it; Ingres has over a dozen
> different index types; Want to look at concurrency control in
> The beauty of an abstract language spec is that you can do it anyway
> you want and the same SQL can run on all of them. This assumes that
> the vendor does not give you an incomplete product or proprietary
> carp, of course.
Not knowing, not *having* to be exposed to how the content really is stored, having a simpler abstraction of that gives the developer of the databased system more time to actually contemplate the meaning and intrinsic structure of the data at hand, and less complicating factors - that is the idea. It is a manifestation of a classic principle of modular design called 'information hiding' in order to minimize interaction problems between modules ('coupling and binding' if one wants to search).
Modularisation comes at a price, though.
Black-box thinking blocks taking advantage
of any hidden specifics. In this case not being allowed to
know how the data gets stored blocks taking advantage
of any specific storage strategy.
If it's all a designer can work with, the given abstractions better be good.
The question: "what gets encapsulated in which module?" has a pre-cooked answer for one part (the storage strategy will be somehow taken care of by/within the DBMS) when working with a relational model. To me it is not clear that that is allways the right answer. Received on Sat Aug 14 2004 - 09:45:14 CEST