| Re: Bad database design can cause unnecessary coding [message #179519 is a reply to message #179510] |
Sun, 04 November 2012 10:04   |
Tony Marston
Messages: 57
Registered: November 2010
Karma:
|
Member |
|
|
"Denis McMahon" wrote in message news:k734vv$so2$1(at)dont-email(dot)me...
>
> On Sat, 03 Nov 2012 09:31:15 +0000, Tony Marston wrote:
>
>> "Denis McMahon" wrote in message news:k709tb$h2i$1(at)dont-email(dot)me...
>>>
>>> On Fri, 02 Nov 2012 07:12:05 +0000, Tony Marston wrote:
>>>
>>>> Do you agree with my opinions? Can you think of any more questionable
>>>> design decisions which can be added to this list?
>>>
>>> I think that, not only are you a spammer, but you're a crap one. My
>>> first reaction on actually reading the url you posted was "wtf, this
>>> jerk can't even write english!"
>>>
>>> The first design paradigm I have for you as a website designer is "Don't
>>> try and write websites in languages you aren't fluent in!"
>
>> What is wrong with my english? Why do you think I am not fluent in PHP?
>> Or are you another one of these trolls who is incapable of responding
>> properly to a serious article?
>
> I find it hard to take an article seriously when it contains so many
> errors. In addition, you appear to be spamming. My grandmother used to
> say "if it waddles like a duck and it quacks like a duck, it's a duck."
>
> However, I'll give you the benefit of the doubt, here's one example:
>
> "There are some people out there who are design but never build."
So you found a single little mistake which both I and my spellchecker
missed, and that cause you to disregard the whole article. How petty you
are!
> Now, turning to the technical content of your page, your first rule is:
>
> 'Every table requires a primary key. Some databases allow a table to be
> created without a primary key, but there is no good reason to use this
> "feature".'
>
> Pray tell me, in a database table that maps attendees to events in a many
> to many relationship, which column, attendee_id or event_id, would be the
> primary key?
If you bothered to read the article you would have come across this:
http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-nin compoop.html#many-to-many
> Or should I add a third, unused, autoincrement column called mapping_id
> just so that I can have a primary key, even though that value is never
> going to be used.
>
> In addition, you state that 'Wherever possible fields with the same
> content should have the same name.'
>
> I have, in my 20+ years of working with sql, found that it is much more
> beneficial to name columns for their purpose within the table, rather
> than their purpose within some other table.
>
> e.g. person_id in the person table may map to manager_id or managee_id in
> the manager table (which maps managers to their staff), attendee_id in
> the mapping of events to attendees, and trainee_id in the mapping of
> people to courses they have attended (and all three of those tables break
> your first rule, because they are all many to many mappings).
While that may be OK sometimes, the point I was trying to make was that you
should avoid have different names such as ACCOUNT_NO, ACCNO and ACC_NUM
which mean the same thing. You should also avoid using a name which has
different meanings on different tables.
> My final word is this. Your cardinal rule, rule 1, implies that you have
So you disagree with the cardinal rule which says that every table should
have a primary key? That says a lot about your capabilities. I would hate to
work on a database that *YOU* designed.
> no understanding of the use, purpose or benefit of mapping many to many
> relationships. If that is the case, then your claimed years of experience
> are worth squat, zero, zilch, sweet fuck all. If that is not the case,
> then your ability to develop worthwhile, meaningful database design
> paradigms based on your claimed years of experience is worth squat, zero,
> zilch, sweet fuck all.
>
> gds
>
> Denis McMahon
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]