Re: Best way to design table to store attributes?

On Jan 22, 3:53 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> At a more basic level, though, are you sure you have correctly modelled
> your problem? 150 independent booleans creates a state machine with
> somewhere around 10^45 states. That's a big state machine. Without any
> sort of transition constraints, that creates a fully connected state
> machine with 10^45 states and somewhere around 10^90 allowable transitions.
>
> Those are big numbers, and it seems unlikely you really need such an
> unwieldy state machine for each row of your table.

I've often wondered about this line of thinking, that if your system isn't implemented in a purely relational methodology, you have no choice but to implement it as a state machine. However, I think that I'm settling on the idea that its more the malfunction of the relational advocate that they aren't able to handle situations outside of their admittedly good relational foundations.

Just because the original design used what appears to be a perfectly decent instance of repeating groups does not mean the designer is then condemned to the complexity of Mr. Badour's imaginary zillion states.

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, 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.

C'mon people, programming 101 here.

Does anybody have knowledge of the origin of this silly "state machine" argument? I'm really curious why it carries any weight in these sort of discussions but I also imagine that it originally was a valid point offered by someone a bit more academically inclined than Mr. Badour, and I'm genuinely interested in reading about it. Received on Fri Jan 23 2009 - 21:27:59 CET