Re: Best way to design table to store attributes?
Date: Sat, 24 Jan 2009 04:26:10 GMT
Message-ID: <CLwel.7320$Db2.6466_at_edtnps83>
patrick61z_at_yahoo.com wrote:
> 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.i
Programming 101 has nothing to do with it. I doubt there is much 'genuine' interest because the record here shows precious few are interested enough to explore fundamentals and what you posted isn't 'academic' (as you say) at all, closer to the obfuscation that's so popular in db circles these days. From what I've seen, B. Badour, when he chooses to comment on incomplete questions, nearly always offers an indirection or two and at least one abstraction, which I find more valuable than direct instruction, being as indirections, for example, invite comparisons between equally valid design alternatives. In return for that advantage, one must apply much more thought and imagination than the frequently simplistic dictums and sloppy language so common here suggest (such as so-called 'relational methodology', there is no such thing, witness the big guns elsewhere who don't agree even about oft-supposed-solid theory like normalization). I'd say the point of the 'state machine' comp arison was likely to illustrate that the original post completely lacked 'actionable' requirements, ie., the 'requirement', as stated, was silly (no offence intended to the OP who qualified his questions). I've seen people try to pass off such as real requirements more times than I want to remember. Note that the original poster hadn't clarified his requirement until later. A later message showed that he's trying to deal with a survey result. But since a marketing operation seems involved, there are further applications, eg., 'who bought a trip and might become a repeat customer?'.
(I think the 'dictums' are more or less okay when it comes to a specific products but c.d.t. is not about products.)
Besides, if 1.2 million respondents, times 150 questions, is considered a big db, I have to laugh. Only big to a mickey-mouse operation, I'd say. Those numbers might have been a prooblem with the hardware of thirty years ago, but not now, at least if the organization involved is serious about using a computer. Personally, if that's thought to be too big for accessible commercial hardware, I'd say it's likely that this is not an important problem. Given the cost of postage these days, any outfit that mails only half of the 150 possible offers to respondents without further analysis will soon be hamstrung with bigger problems, eg., bankruptcy. That company deserves to go broke for crappy analysis in the first place.
Note to newbies (even though most of you are semi-literate), don't take everything you see posted on c.d.t. at face value. Eg., don't assume that just because somebody uses a phrase like 'original design' that any real design exercise ever happened. Another free tip I have for you is at that in c.d.t. there is a never-ending supply of obfuscators who have no notion of the basics. Most posts here are from people who are familiar only with apps they've had something to do with, and are not really serious about theory. Try a little grade-school arithmetic to help compare posts you see here. Ask which sums look practical and which phrases seem nebulous, ie., impractical. Obviously when mail offers are involved, some business decision will be involved beyond any answers a db can provide. Obviously the computer could help identify the bell-curve, but you'd have to do a lot of googling to find a correlation between bell-curves and the relational model (or models plural if you l ike, no doubt enough googling might suggest a weak-minded correlation, but that's another 'modern' problem). If you can't handle simple business arithmetic, you're probably wasting time here. Let alone mathematical philosophy, aka logic, which most of db theory revolves around. Received on Sat Jan 24 2009 - 05:26:10 CET