Re: Constraints and Functional Dependencies
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 28 Feb 2007 18:57:31 GMT
Message-ID: <vgkFh.1172106$5R2.322326_at_pd7urf3no>
>>Marshall wrote:
>>
>>
>>>For myself, I completely fail to see the point of possreps.
>>
>>Data independence.
>>
>>Consider a Complex number type. It has two possible representations:
>>cartesian and polar.
>>
>>Consider the following chart of performance characteristics for
>>combinations of operations and representations:
>>
>> | Cart | Polr |
>>-----------------
>>+ | Fast | Slow |
>>-----------------
>>* | Slow | Fast |
>>-----------------
>>
>>Consider three similar relations that have a Complex attribute. The
>>first application mostly uses the attribute for addition. The second
>>application mostly uses the attribute for multiplication. The third uses
>>the attribute for a balanced mix of operations.
>>
>>The first application will perform better if the dbms physically stores
>>the attribute in cartesian coordinates. The second application will
>>perform better if the dbms physically stores the attribute in polar
>>coordinates. The third application performs better if it avoids
>>unecessary conversions.
>>
>>Now, suppose it is the same relvar in all three cases and a dba has to
>>achieve specific performance goals. How does the dba do that without
>>disrupting any of the applications.
>>Finally, consider a Video data type where each conversion results in a
>>loss of picture quality. What is the best way to support multiple
>>players and formats?
Date: Wed, 28 Feb 2007 18:57:31 GMT
Message-ID: <vgkFh.1172106$5R2.322326_at_pd7urf3no>
Marshall wrote:
> On Feb 28, 9:20 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >
>>Marshall wrote:
>>
>>
>>>For myself, I completely fail to see the point of possreps.
>>
>>Data independence.
>>
>>Consider a Complex number type. It has two possible representations:
>>cartesian and polar.
>>
>>Consider the following chart of performance characteristics for
>>combinations of operations and representations:
>>
>> | Cart | Polr |
>>-----------------
>>+ | Fast | Slow |
>>-----------------
>>* | Slow | Fast |
>>-----------------
>>
>>Consider three similar relations that have a Complex attribute. The
>>first application mostly uses the attribute for addition. The second
>>application mostly uses the attribute for multiplication. The third uses
>>the attribute for a balanced mix of operations.
>>
>>The first application will perform better if the dbms physically stores
>>the attribute in cartesian coordinates. The second application will
>>perform better if the dbms physically stores the attribute in polar
>>coordinates. The third application performs better if it avoids
>>unecessary conversions.
>>
>>Now, suppose it is the same relvar in all three cases and a dba has to
>>achieve specific performance goals. How does the dba do that without
>>disrupting any of the applications.
> > > My problem with this examples has always been the limitations > of floating point numbers. Consider (1,1). It is exactly representable > in cartesian form, but not in polar form; the radius is sqrt(2), an > irrational. > > However, I had not considered: "How does the dba do that without > disrupting any of the applications" previously; I'll have to think > about that some more. > > >
>>Finally, consider a Video data type where each conversion results in a
>>loss of picture quality. What is the best way to support multiple
>>players and formats?
> > > In the case of lossy compression, I feel strongly that it is a logical > matter, and cannot be abstracted away. The choice of compression > ratios and algorithms needs to be under user/application control, > not dba control.
Surely a video application would not try to map sqrt(2) to an individual pixel without a notion of rounding or somesuch. Without somesuch, I presume a polar possrep would either disallow that polar value or equate it a cartesian coordinate that exists. Don't ask me how to implement it, though. I still don't understand how the RM all by itself can decide equality/identity.
p Received on Wed Feb 28 2007 - 19:57:31 CET