Fair enough Warren, well stated.
As far as my lack of a response for the "50 columns per table" reply,
I wanted to speak to the database folks where I work for advice. It
took a few days to collect advice and opinions.
I was told, by them, it's not uncommon to have large tables depending
upon the type of data being dealt with. In their case the medical
industry, where they often have loads and loads of patient data to
deal with. ...but as you go through the normal forms the number of
tables usually increases and their column size should decrease.
That said, they suggested that I can break the large tables up and
chain them together, which I have done.
So thanks for the advice. There are more tables but it feels cleaner
and I don't have to change the perl script.
The people that I am assisting (not in the medical industry), for
this side project, handed me a chart of how they wanted the data to
be organized. I simply worked from that.
I should add that I am an embedded engineer. I prefer using C++ and
only use C for drivers and etc.
Lastly, I do see a practical difference between approaches and your
point is well taken. Although, I would urge you not to bite the
criticizers too much if they don't have a ready solution in hand. I
don't expect that from my customers (only the criticism from them).
P.S. You may want to re-think the "bull in a china shop" analogy. If
the design is robust it should be easy to fend off a bull. I doubt
you want to compare mysql++ to a china house. (read as friendly
On Aug 16, 2007, at 7:01 AM, Warren Young wrote:
> Graham Reitz wrote:
>> Wow man, there is no reason for this.
> I think you're misreading the tone of the message, an easy thing to
> do over a text medium. It should be read as a strong, calm
> argument. (That's "argument" as in making a reasoned point, not
> "argument" as in "being a pugnacious ass". :) )
>> You're obviously upset about something other than 'just' my comments.
> I don't know about "upset", but yes, in your newbiness, you are a
> bit of a bull in a china shop just now. Anyone who's been here a
> while could have predicted immediate rejection for some of your
> suggestions. The fact that you made them anyway demonstrates an
> insensitivity to the way things are done here, which doesn't help
> your case.
> It's common practice to lurk on a list for a while before offering
> suggestions, to avoid problems like this.
>> I hope that whatever is going on in your life improves.
> Actually, my life is fine right now, but thanks for your concern.
>> I think we would both agree that comments like, "Your library
>> sux," is completely inappropriate and definitely not constructive,
>> but that didn't happen here.
> Didn't say it did. In "X sux", X == "MYSQLPP_SSQLS_NO_STATICS" and
> suchlike, not "MySQL++".
> Study the "eyeball" thread. There are many criticisms of my code
> in it, most of which caused me no distress at all, including almost
> all of the ones I disagreed with.
> The only one that really agitated me is the guy pointing out that
> the template is not thread-safe (fine) and saying this is
> "wrong" (not fine). It is not wrong. It is simply a design
> choice. If he'd said "you could make it thread-safe by making the
> refcount inc/dec operations atomic", that would have been fine. It
> would be a logical argument, offered as a choice, with the "right"
> answer depending on context. I still would have disagreed with it,
> because I think the context where it makes sense is unrealistic,
> but I wouldn't have been upset about it.
> Condemning something as "wrong" when in fact it's a choice from a
> set of valid alternatives is an "X sux" sort of argument.
> There are no absolutes in design. That's what makes it design and
> not engineering. To properly criticize a design, you have to start
> from the premise that the current design was motivated by rational
> choices that make sense in some context, even if you can't see it.
> You can then offer an alternative which may make more sense in a
> different context. Then the designer just has to choose between
> your new alternative and the status quo, possibly with the question
> of which context is more common thrown into the mix. This avoids
> the attack on the designer's ego.
> If I didn't have an ego, it couldn't get bruised, and there would
> be no need for all this circumlocution. But if wishes were
> changes, I could have a pony, too.
> I am reminded of my response to your "50 columns" thread. I was
> implicitly criticizing your design, but in the very way I'm
> recommending here. I said I didn't understand it, and asked you to
> give me context to understand it. Even after two unanswered
> challenges, I'm still open to the possibility that you could show
> me that context and that I'd be converted in my thinking. This is
> why I didn't say "there is no valid reason to have 50 columns in a
> table". I have a strong opinion that valid reasons for such a
> design are hard to come by, but I haven't ruled out the possibility
> that you have such a reason.
> Do you see the practical difference between these approaches?
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus?