| Re: Bad database design can cause unnecessary coding [message #179513 is a reply to message #179510] |
Sat, 03 November 2012 14:55   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 11/3/2012 9:08 AM, Denis McMahon wrote:
> 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."
>
> 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?
>
> 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).
>
> My final word is this. Your cardinal rule, rule 1, implies that you have
> 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
>
Don't support the spammer, Denis. It's beneath you.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]