Re: Designing DB in accordance with the relational model

On 12/11/2010 3:37 AM, Cimode wrote:
> On 10 nov, 10:18, Roy Hann<specia..._at_processed.almost.meat> wrote:
>> Clifford Heath wrote:
>>> [Nulls] are an
>>> efficiency feature, added to allow a reduction in the number of
>>> physical tables required, as a concession to the physical access
>>> characteristics of mechanical storage devices.
>>
>> *PLONK!* And on so many levels too.
> An *efficiency feature*. Never heard that one before. Typical mumbo
> jumbo.
>

I must say I have heard people say exactly what Clifford wrote and I seem to remember some app or other that separated most users from the dbms so that they couldn't access base tables which were 'outer joins' directly, so the application programmers never actually manipulated any nulls. I saw that as a hack that reduced the dbms to an access method but whether misguided or not, I'd say it's true enough that some people think this way, putting the performance cart before the functional cart.   Personally, if there were no dbms that could handle a performance requirement I would consider programming the app with an access method.   I think such apps are rare, perhaps found only in real-time automation systems.

Roy H snipped the first sentence in Clifford H's paragraph: "You shouldn't need NULLs in your conceptual model." I don't see any reason to plonk that, nor the rest which could have been valid sarcasm. For me the big problem with nulls is that I don't know how to express them in a predicate. (Until the late 1990's, I never thought much about predicates only because I hadn't seen much written about them. Instead, I had thought of relations as being abstractions of what I called uniform sentences. This 'thinking' was casual and a little fuzzy, not formal at all but it did at least prevent me from associating two 'very unlike' sentences with the same 'table'.) Received on Fri Nov 12 2010 - 14:48:20 CET