Re: Best way to design table to store attributes?

On Jan 25, 3:57 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> paul c wrote:
> > patrick..._at_yahoo.com wrote:
>
> >> While the DATA in these tables could have a zillion states, thats like
> >> saying that an ssn field has 10^9 states because it has nine
> >> characters that can range from zero to nine.
>
> Yes, exactly like that. One of my high school french teachers would have
> reponded to that with "You have a fine grasp of the obvious." Except
> elsewhere Patrick utterly fails to demonstrate any such grasp.
>
> I suggest one stop to ponder that a billion seems like a large number
> but it is infinitesimally small compared to 10^45, which is itself
> infinitesimally small comparet to 10^90.
>
> >> Yes, there may be many
> >> many possible values, but simple payroll programs for example are not
> >> burdened with a zillion states as either entire ranges of values are
> >> handled identically, or the unneeded values are simply never entered
> >> into storage.
>
> That depends on the payroll program. ADP regularly handles on the order
> of 10^7 social security numbers, and the IRS handles on the order of
> 10^8 or 10^9 of them--when one stops and considers that even
> non-resident aliens like myself sometimes have one.
>
> Nevertheless, 10^45 states is a vast number of states. It is on the
> order of the mass of the sun in picograms. However, Carl's explanation
> suggests the first thing anyone will do with that data is dimension
> reduction.

Bob's 10^45 states argument appeared in his first response to Carl's original post and in that post I can't see any suggestion that "the first thing anyone will do is data reduction". Nevertheless, I don't have a problem with Bob asking the question of whether it really makes sense to record so many independent boolean attributes.

Bob needs to refine his apparent claim that an excessive number of possible states suggest poor design. For example, a 1 mega-pixel 24 bpp image has about 10^(7 million) possible states. Received on Mon Jan 26 2009 - 02:22:34 CET