| Re: Bad database design can cause unnecessary coding [message #179510 is a reply to message #179507] |
Sat, 03 November 2012 13:08   |
Denis McMahon
Messages: 634
Registered: September 2010
Karma:
|
Senior Member |
|
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]