Bad database design can cause problems for developers

[Tony Marston]

When you design your database for your application are you aware that
some of your design decisions can have a detrimental effect when it comes to
writing the code to access that database? I have been designing databases,
and building the applications which use them, for several decades, and I
have learned over the years that there are some design decisions which help
the developer while others do nothing more than hinder. I have produced a
document which lists 14 of these “hindrances” which can be read at
http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-nincompoop.html

Do you agree with my opinions? Can you think of any more questionable design
decisions which can be added to this list?

Tony Marston

http://www.tonymarston.net
http://www.radicore.org

[Brian Cryer]

"Tony Marston" <TonyM...@hotmail.com> wrote in message
news:rCJls.200250$Ak.1...@fx24.am4...

Good read.

On your point about "unnecessary technical keys", I've encountered a novice
mistake which I don't think you've got covered (although my apologies if you
have, as you've got a lot there). I once worked with someone who insisted on
adding an index for every field that was used as part of a query. So
something like:

CREATE Table Arrivals (
ArrivalID int AUTO_INCREMENT,
CountryID int,
SiteID int,
StationID int,
PRIMARY KEY (ArrivalID),
Index I1 (CountryID),
Index I2 (SiteID),
Index I3 (StationID));

most of the queries against this table were of the form:
Select * from Arrivals where CountryID=X and SiteID=Y;

What he didn't appreciate is that the database will only use one index (per
table), so defining multiple indexes like this - especially ones which would
never actually be used - is wasteful.

What he should have done was to define a compound index:
Index I1(CountryID,SiteID);

Once I'd educated him about compound indexes the next mistake he tended to
make was to have this in addition to his others, so:
Index I1 (CountryID),
Index I2 (CountryID, SiteID)

The first of these is unnecessary.

Once I took over database design, and rationalised what indexes where in use
the database was noticably faster and smaller.

One point I would quibble with - is "[Common mistakes by nincompoops:]
Numeric fields which cannot contain negatives are not marked as unsigned."
In general I'd agree with you, but as with most good advice there are
exceptions. I remember using an unsigned int - this was for a range of
values that would never exceed even a signed int, the problem was that the
ODBC.NET driver insisted (correctly I suppose) that this couldn't be mapped
to an int in code but to an Int64 - so 64 bit integer rather than a 32 bit
integer. Given that I was working on a 32 bit operating system I wanted to
stick with a 32 bit integer, so it was easier to change the database to a
signed int. I suppose the message is that unless it compromises your
database, then be prepared to make allowances when choose an appropriate
field type given how it will be represented in code that will run against
that database.

Hope this is useful.
--
Brian Cryer
http://www.cryer.co.uk/brian

[Erick T. Barkhuis]

Tony Marston:

>[...] I have learned over the years that there are

>some design decisions which help the developer while others do
>nothing more than hinder. I have produced a document which lists 14
>of these “hindrances” which can be read at
>http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-nincompoop.html
>
>Do you agree with my opinions?

Thanks for this, Tony.
I just read your document, and found it interesting. Good stuff for
novice developers, and plenty of items to at least give (another)
consideration for experienced developers.

You won't really benefit from a "Yes, I agree" after each paragraph
that I like, and therefore I just mention a couple of your opinions
that I have a slightly different take on. Please, see them as
discussion openers, only...not as some harsh critique.


1. "All tables should be named in the singular, not the plural."
-----------------------------------------------------------------
Since I have started using plural for table names, I have never
regretted that decision. "SELECT ... FROM customers" sounds so much
more logical than "SELECT ... FROM customer". It even makes discussing
tables and queries with clients during workshops more natural.
However, I use singular as long as we're working with E/R-models, only.
In data modeling workshops, where database tables aren't on-topic yet,
I'd have a "Customer" entity, an "Article" entity, etc.



2. [Passing context to child programs]
"This context can be passed as a simple string in the format
<pkey_name>='<customer_id>' such as customer_id='12345'. Provided that
the column name(s) in the primary key are *exactly* the same as the
column name(s) in the foreign key then the receiving program can use
the passed context without the need for any additional processing."
------------------------------------------------------------------
In a web environment, where query string contents are open to all, I
generally don't like to mention database, table or field names. Passing
a value for customer_id='12345' would, in my applications, look
something like http://mydomain.invalid/?cu=12345 or similar. Color me
phobic.



3. [Normalization]
"Having proper table names and column names is one thing, but that is
not the end of the story. To make the insertion and subsequent
retrieval of data as efficient and effective as possible it is also
necessary for the database designer to go through a process called
'data normalisation'."
-------------------------------------------------------------------
This point sounds as if it was added later, almost like "Oh yeah,
before I forget, let's just mention normalization, too."
In the context of your document, I would either leave it out, or make a
major point of it. Thinking of it, I would leave it out. The order of
magnitude of the topic of normalization is much different from your
other (valid) points. In fact, I'd rather see a well-normalized
database that violates half of your advice topics than a non-normalized
bunch of tables with proper naming conventions and key definitions.


4. [Tone]
Examples: "Trying to mix the two methods is a sure sign of a very
confused mind."
"...such arrogant nincompoops should be forced to ..."
-------------------------------------------------------------------
Please, allow me to add, that I have hesitated to reply after reading
your document. By using phrases like the above, you don't really
encourage your readers to get down to work immediately and implement
your advice. It's not the advice that they won't like, but the tone of
parts of the document, that may make them click it off the screen and
never return.
May I suggest that you try and write your document for your friends,
for your friends only, and consider all readers your best friends, who
don't deserve any name calling or top-down rebuking?



--
Erick

[Brian Cryer]

"Erick T. Barkhuis" <erick....@ardane.c.o.m> wrote in message
news:afpmi6...@mid.individual.net...

> Tony Marston:
>
>>[...] I have learned over the years that there are
>>some design decisions which help the developer while others do
>>nothing more than hinder. I have produced a document which lists 14
>>of these “hindrances” which can be read at
>>http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-nincompoop.html
>>
>>Do you agree with my opinions?
>
> Thanks for this, Tony.
> I just read your document, and found it interesting. Good stuff for
> novice developers, and plenty of items to at least give (another)
> consideration for experienced developers.
>
> You won't really benefit from a "Yes, I agree" after each paragraph
> that I like, and therefore I just mention a couple of your opinions
> that I have a slightly different take on. Please, see them as
> discussion openers, only...not as some harsh critique.
>
>
> 1. "All tables should be named in the singular, not the plural."
> -----------------------------------------------------------------
> Since I have started using plural for table names, I have never
> regretted that decision. "SELECT ... FROM customers" sounds so much
> more logical than "SELECT ... FROM customer". It even makes discussing
> tables and queries with clients during workshops more natural.
> However, I use singular as long as we're working with E/R-models, only.
> In data modeling workshops, where database tables aren't on-topic yet,
> I'd have a "Customer" entity, an "Article" entity, etc.

Good point. I think this is a good example of where a simple rule doesn't
work. Looking through the database I'm currently working on there are a
mixture of plural and single named tables - most are plural and all seem
appropriate.

So, like you I have "select ... from Accounts" - where it reads so much
better because the table is named in the plural. That said, I do acknowledge
Tony's point that (quote): "When writing SQL queries it is more logical to
write 'product.cost' than 'products.cost'". Which just shows that you can't
please everyone all of the time.

I also have "select ... from AuditTrail" and "select ... from UploadQueue"
where having then named in the singular is more appropriate.

What it really comes down to is to name tables appropriatly. In any event,
its an interesting and good point to think about before naming a table.

[Erick T. Barkhuis]

Brian Cryer:

>"Erick T. Barkhuis" <erick....@ardane.c.o.m> wrote in message
>news:afpmi6...@mid.individual.net...

>>1. "All tables should be named in the singular, not the plural."
>>-----------------------------------------------------------------
>>Since I have started using plural for table names, I have never
>>regretted that decision.

>So, like you I have "select ... from Accounts" - where it reads so

>much better because the table is named in the plural.[...]

>I also have "select ... from AuditTrail" and "select ... from
>UploadQueue" where having then named in the singular is more
>appropriate.
>
>What it really comes down to is to name tables appropriatly. In any
>event, its an interesting and good point to think about before naming
>a table.

I agree, Brian.
Like you, I also have several tables named in singular, because that
seems the proper use of language. And I often find forms of verbs
appropriate for certain n:m-relationship-tables, like "hands_over_to"
or "makes_available_at", which come to mind.



--
Erick

"With only 365 days a year, there's a natural limit to our spare time"

[herman...@invalid.be.invalid]

Good reading, just two minor remarks:
Giving an example is a tricky affair. In your first secondary convention you
give the example of the ISO country code as a not changing data item. I seem
to remember that there are discussions of changing all country codes to
three characters, no idea when that would happen. But if it does, and you
would have used the country code as primary/foreign key, then the change
might cause a problem.

I miss a recommendation that states something like "A primary key should be
a meaningless number (or string)".
I've seen more than once problems with that, like electrical components
having a "number" where part(s) of the string had a meaning like physical
value, technology indicators.... They run out of possible codes because one
or the other substring is too short after some time to accomodate all values
the users want or have to use.
But thay is a recommandation, not a strict rule!

Herman Viaene

>
> Tony Marston
>
> http://www.tonymarston.net
> http://www.radicore.org

--
Veel mensen danken hun goed geweten aan hun slecht geheugen. (G. Bomans)

Lots of people owe their good conscience to their bad memory (G. Bomans)

[Tony Marston]

"Brian Cryer" wrote in message news:k786kc$58m$1...@dont-email.me...

Thanks for that. I'll consider adding that to my article (with credits, of
course).

>One point I would quibble with - is "[Common mistakes by nincompoops:]
>Numeric fields which cannot contain negatives are not marked as unsigned."
>In general I'd agree with you, but as with most good advice there are
>exceptions. I remember using an unsigned int - this was for a range of
>values that would never exceed even a signed int, the problem was that the
>ODBC.NET driver insisted (correctly I suppose) that this couldn't be mapped
>to an int in code but to an Int64 - so 64 bit integer rather than a 32 bit
>integer. Given that I was working on a 32 bit operating system I wanted to
>stick with a 32 bit integer, so it was easier to change the database to a
>signed int. I suppose the message is that unless it compromises your
>database, then be prepared to make allowances when choose an appropriate
>field type given how it will be represented in code that will run against
>that database.
>
>Hope this is useful.

The point about unsigned integers is that where the business logic expects a
positive number the sudden appearance of a negative value could cause
confusion. In the case of MySQL an unsigned integer can hold double the
number of values, which is useful when using AUTO_INCREMENT primary keys.
But, as you point out, if you are interfacing with software which can't
handle unsigned integers properly then that is something that you have to
live with.

--

[Tony Marston]

"Erick T. Barkhuis" wrote in message
news:afpmi6...@mid.individual.net...
>

>Tony Marston:
>
>>[...] I have learned over the years that there are
>>some design decisions which help the developer while others do
>>nothing more than hinder. I have produced a document which lists 14
>>of these “hindrances” which can be read at
>>http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-nincompoop.html
>>
>>Do you agree with my opinions?
>
>Thanks for this, Tony.
>I just read your document, and found it interesting. Good stuff for
>novice developers, and plenty of items to at least give (another)
>consideration for experienced developers.
>
>You won't really benefit from a "Yes, I agree" after each paragraph
>that I like, and therefore I just mention a couple of your opinions
>that I have a slightly different take on. Please, see them as
>discussion openers, only...not as some harsh critique.
>
>
>1. "All tables should be named in the singular, not the plural."
>-----------------------------------------------------------------
>Since I have started using plural for table names, I have never
>regretted that decision. "SELECT ... FROM customers" sounds so much
>more logical than "SELECT ... FROM customer". It even makes discussing
>tables and queries with clients during workshops more natural.
>However, I use singular as long as we're working with E/R-models, only.
>In data modeling workshops, where database tables aren't on-topic yet,
>I'd have a "Customer" entity, an "Article" entity, etc.

This is a case of six of one and half a dozen of another. While "SELECT *
FROM customers" may seem sensible what about when referring to column names
in your query, such as "customers.customer_id, customers.customer_name". In
one context using plurals seem right, but in another it does not.

>2. [Passing context to child programs]
>"This context can be passed as a simple string in the format
><pkey_name>='<customer_id>' such as customer_id='12345'. Provided that
>the column name(s) in the primary key are *exactly* the same as the
>column name(s) in the foreign key then the receiving program can use
>the passed context without the need for any additional processing."
>------------------------------------------------------------------
>In a web environment, where query string contents are open to all, I
>generally don't like to mention database, table or field names. Passing
>a value for customer_id='12345' would, in my applications, look
>something like http://mydomain.invalid/?cu=12345 or similar. Color me
>phobic.

In my framework I *NEVER* pass such information in URLS. I put the WHERE
string into a session variable, so it stays on the server and is never
exposed to the client.

>3. [Normalization]
>"Having proper table names and column names is one thing, but that is
>not the end of the story. To make the insertion and subsequent
>retrieval of data as efficient and effective as possible it is also
>necessary for the database designer to go through a process called
>'data normalisation'."
>-------------------------------------------------------------------
>This point sounds as if it was added later, almost like "Oh yeah,
>before I forget, let's just mention normalization, too."
>In the context of your document, I would either leave it out, or make a
>major point of it. Thinking of it, I would leave it out. The order of
>magnitude of the topic of normalization is much different from your
>other (valid) points. In fact, I'd rather see a well-normalized
>database that violates half of your advice topics than a non-normalized
>bunch of tables with proper naming conventions and key definitions.

I put it at the end simply because you have to build your database first
before you can normalise it, so using proper naming conventions and data
types is done before, not after.

The only thing which is done after is looking for primary keys to see if a
natural keys exists or a surrogate has to be created, and what indexes need
to be created.

>4. [Tone]
>Examples: "Trying to mix the two methods is a sure sign of a very
>confused mind."
>"...such arrogant nincompoops should be forced to ..."
>-------------------------------------------------------------------
>Please, allow me to add, that I have hesitated to reply after reading
>your document. By using phrases like the above, you don't really
>encourage your readers to get down to work immediately and implement
>your advice. It's not the advice that they won't like, but the tone of
>parts of the document, that may make them click it off the screen and
>never return.
>
>May I suggest that you try and write your document for your friends,
>for your friends only, and consider all readers your best friends, who
>don't deserve any name calling or top-down rebuking?

Perhaps you are right, but that is a reaction to all the abuse I get from my
critics.

--

[Erick T. Barkhuis]

Tony Marston:

>"Erick T. Barkhuis" wrote in message
>news:afpmi6...@mid.individual.net...

Hi Tony,
thanks for taking the time to post a reply to each suggestion.

>>3. [Normalization]
[...] Thinking of it, I would leave it out.[...]

>
>I put it at the end simply because you have to build your database
>first before you can normalise it,

Eh?
Do you really build a non-normalized database first, and then go
through the process of normalization?
Isn't normalization rather one step in the process of database design,
well before any tables are actually created?

>>4. [Tone]
>>Examples: "Trying to mix the two methods is a sure sign of a very
>>confused mind."
>>"...such arrogant nincompoops should be forced to ..."
>>-------------------------------------------------------------------
>>Please, allow me to add, that I have hesitated to reply after
>>reading your document. By using phrases like the above, you don't
>>really encourage your readers to get down to work immediately and

>>implement your advice.[...]

>Perhaps you are right, but that is a reaction to all the abuse I get
>from my critics.

Allow me to think out loud:
if you don't like the abuse, why would your readers like to be abused?

With your article, you want to change the World a bit, giving
information and sharing your experiences. You want your readers to
appreciate your effort and they want to benefit from that (otherwise,
they would not read the lengthy article). That's great!
Those who really sit down and read your article are NOT the ones who
abuse or critizise you...they are the ones who like to get informed
opinions. By suggesting that they might be nincompoops, you are asking
to be critized and kindly inviting them to abuse you.

That's why I suggest you get rid of the part where you mention the
difference between ninjas, newbies and nincompoops. For the purpose of
sharing information and experience, this differentation is a non-issue.

Another suggestion: please go and read a couple of articles from "A
List Apart". Feel and experience the tone in which those are written.
All of them. Every one of them is a pleasant read....just because the
author, every author, writes in a pleasant, friendly tone. The reader
feels at ease and 'leveled' with the author. I consider these articles
excellent contributions and great examples of how to communicate when
sharing information from experts and enthousiasts. Even though I don't
always agree with the contents.




--
Erick

[herman...@invalid.be.invalid]

One other thing in your secondary convention 3:
In an environment where the data analysis starts with ERD analysis (entity-
relationship-diagram) there is sometimes the convention that the entities
are named in singular, while the tables derived from these in the actual
design are named in plural.

Herman Viaene

>
> Tony Marston
>
> http://www.tonymarston.net
> http://www.radicore.org

[Denis McMahon]

On Tue, 06 Nov 2012 07:25:46 +0000, Tony Marston wrote:

>> [normalisation]

> I put it at the end simply because you have to build your database first
> before you can normalise it, so using proper naming conventions and data
> types is done before, not after.

What a load of crap.

Normalization should be part of the design process before you start
defining tables, not something that you tack on afterwards.

Rgds

Denis McMahon

[Tony Marston]

wrote in message news:7vmdnR2sedV3VQrN...@edpnet.net...

>
>Tony Marston wrote:
>
>> When you design your database for your application are you aware that
>> some of your design decisions can have a detrimental effect when it comes
>> to writing the code to access that database? I have been designing
>> databases, and building the applications which use them, for several
>> decades, and I have learned over the years that there are some design
>> decisions which help the developer while others do nothing more than
>> hinder. I have produced a document which lists 14 of these “hindrances”
>> which can be read at
>> http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-
>nincompoop.html
>>
>> Do you agree with my opinions? Can you think of any more questionable
>> design decisions which can be added to this list?
>
>Good reading, just two minor remarks:
>Giving an example is a tricky affair. In your first secondary convention
>you
>give the example of the ISO country code as a not changing data item. I
>seem
>to remember that there are discussions of changing all country codes to
>three characters, no idea when that would happen. But if it does, and you
>would have used the country code as primary/foreign key, then the change
>might cause a problem.

Generally speaking standard codes such as ISO country codes should never
change, but there may be circumstances, such as too many countries and too
few letters in the alphabet, where a change is inevitable rather than an
idle whim of some faceless bureaucrat. Perhaps they would leave the existing
codes alone and simply add another character for new ones.

>I miss a recommendation that states something like "A primary key should be
>a meaningless number (or string)".
>I've seen more than once problems with that, like electrical components
>having a "number" where part(s) of the string had a meaning like physical
>value, technology indicators.... They run out of possible codes because one

>or the other substring is too short after some time to accommodate all

>values
>the users want or have to use.

>But that is a recommendation, not a strict rule!
>
>Herman Viaene

I think it would be wrong to say that a primary key should *always* contain
a meaningless number/string as there are some natural keys (such as country
codes) which can safely be used instead of a random number. I have worked on
quite a few data entry systems where the user preferred to input a
well-known or memorable code instead of being forced to to a lookup to
obtain an arbitrary number.

As usual this is one of those cases where you have to think about it and
weigh up the pros and cons.

It is only those who are incapable of thinking who require rules for
everything.

[Tony Marston]

"Erick T. Barkhuis" wrote in message

news:afrurj...@mid.individual.net...

>
>Tony Marston:
>
>>"Erick T. Barkhuis" wrote in message
>>news:afpmi6...@mid.individual.net...
>
>
>Hi Tony,
>thanks for taking the time to post a reply to each suggestion.
>
>>>3. [Normalization]
>[...] Thinking of it, I would leave it out.[...]
>>
>>I put it at the end simply because you have to build your database
>>first before you can normalise it,
>
>Eh?
>Do you really build a non-normalized database first, and then go
>through the process of normalization?
>Isn't normalization rather one step in the process of database design,
>well before any tables are actually created?

I used to design my databases on pieces of paper first, in the old days, and
then create the database schema, but nowadays with modern tools it seems
just as fast to put your thoughts directly into the schema and play with it
there. Which ever way you do it, you have to start with a bunch of sample
tables and columns before you can normalise them. There is no rule which
says that you must complete te normalisation process before you create the
physical database schema.

>>>4. [Tone]
>>>Examples: "Trying to mix the two methods is a sure sign of a very
>>>confused mind."
>>>"...such arrogant nincompoops should be forced to ..."
>>>-------------------------------------------------------------------
>>>Please, allow me to add, that I have hesitated to reply after
>>>reading your document. By using phrases like the above, you don't
>>>really encourage your readers to get down to work immediately and
>>>implement your advice.[...]
>
>
>>Perhaps you are right, but that is a reaction to all the abuse I get
>>from my critics.
>
>Allow me to think out loud:
>if you don't like the abuse, why would your readers like to be abused?

Unfortunately it is a fact of life that if you tone down your observations
and make them too polite then some people will fail to realise the
seriousness of what you are saying. If I were to say that by copying those
14 points your database design would be "less than optimum" it would not
have the same effect as "only fools do it this way".

>With your article, you want to change the World a bit, giving
>information and sharing your experiences. You want your readers to
>appreciate your effort and they want to benefit from that (otherwise,
>they would not read the lengthy article). That's great!
>Those who really sit down and read your article are NOT the ones who
>abuse or critizise you...they are the ones who like to get informed
>opinions. By suggesting that they might be nincompoops, you are asking
>to be critized and kindly inviting them to abuse you.

I am not suggesting that everyone who reads this article is a nincompoop,
but you may know someone who is.

>That's why I suggest you get rid of the part where you mention the
>difference between ninjas, newbies and nincompoops. For the purpose of
>sharing information and experience, this differentation is a non-issue.
>
>Another suggestion: please go and read a couple of articles from "A
>List Apart". Feel and experience the tone in which those are written.
>All of them. Every one of them is a pleasant read....just because the
>author, every author, writes in a pleasant, friendly tone. The reader
>feels at ease and 'leveled' with the author. I consider these articles
>excellent contributions and great examples of how to communicate when
>sharing information from experts and enthousiasts. Even though I don't
>always agree with the contents.


--

[Tony Marston]

"Denis McMahon" wrote in message news:k7an44$usg$1...@dont-email.me...

I disagree. You have to have a collection of tables and columns before you
can normalise them. You may have them written down on pieces of paper, or
inside a database modelling tool, or you may put everything into your
database schema and play with it there. This is no rule that you cannot
create your physical database schema until after you have complete the
process of normalisation.

[Tony Marston]

wrote in message news:6rWdnfSh4NmuQgXN...@edpnet.net...

>
>Tony Marston wrote:
>
>> When you design your database for your application are you aware that
>> some of your design decisions can have a detrimental effect when it comes
>> to writing the code to access that database? I have been designing
>> databases, and building the applications which use them, for several
>> decades, and I have learned over the years that there are some design
>> decisions which help the developer while others do nothing more than
>> hinder. I have produced a document which lists 14 of these “hindrances”
>> which can be read at
>> http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-
>nincompoop.html
>>
>> Do you agree with my opinions? Can you think of any more questionable
>> design decisions which can be added to this list?
>
>One other thing in your secondary convention 3:
>In an environment where the data analysis starts with ERD analysis (entity-
>relationship-diagram) there is sometimes the convention that the entities
>are named in singular, while the tables derived from these in the actual
>design are named in plural.
>
>Herman Viaene

This is another area where different people have different conventions. Some
"conventions" are forced upon you simply because of the modelling tool that
you use. I remember years ago having arguments with people about connecting
the boxes or ER diagrams to show the existence of a parent-child
relationship - some liked arrows while other liked crows feet. You can't
have a single set of rules which can please everybody, but whichever rules
you follow you should always understand the reasoning behind those rules and
not follow them blindly and without question.

--

[Erick T. Barkhuis]

Tony Marston:

>"Erick T. Barkhuis" wrote in message

>news:afrurj...@mid.individual.net...
>>
>>Tony Marston:

>>>Perhaps you are right, but that is a reaction to all the abuse I
>>>get from my critics.
>>
>>Allow me to think out loud:
>>if you don't like the abuse, why would your readers like to be
>>abused?
>
>Unfortunately it is a fact of life that if you tone down your
>observations and make them too polite then some people will fail to
>realise the seriousness of what you are saying. If I were to say that
>by copying those 14 points your database design would be "less than
>optimum" it would not have the same effect as "only fools do it this
>way".

So, the louder and more abusive you yell, the more you are right? Hmm..
Have you ever given thought about the possibility that your critics may
occasionally be right?

>I am not suggesting that everyone who reads this article is a
>nincompoop, but you may know someone who is.

Tony, english is not my native language, so I may be misunderstanding
this remark of yours.
Are you perhaps implying what I think you are?


--
Erick

[Tony Marston]

"Erick T. Barkhuis" wrote in message

news:afufp9...@mid.individual.net...

>
>Tony Marston:
>
>>"Erick T. Barkhuis" wrote in message
>>news:afrurj...@mid.individual.net...
>>>
>>>Tony Marston:
>
>>>>Perhaps you are right, but that is a reaction to all the abuse I
>>>>get from my critics.
>>>
>>>Allow me to think out loud:
>>>if you don't like the abuse, why would your readers like to be
>>>abused?
>>
>>Unfortunately it is a fact of life that if you tone down your
>>observations and make them too polite then some people will fail to
>>realise the seriousness of what you are saying. If I were to say that
>>by copying those 14 points your database design would be "less than
>>optimum" it would not have the same effect as "only fools do it this
>>way".
>
>So, the louder and more abusive you yell, the more you are right? Hmm..
>Have you ever given thought about the possibility that your critics may
>occasionally be right?

The word "nincompoop" is not as abusive as you think it is. It is certainly
not as bad as "fucking idiot".

Why don't you stop fixating on the word "nincompoop" and respond
constructively to the bad practices which I have identified in that article.
Do you agree or disagree that they are bad? Why? Do you have any others
which you can add from your vast experience of writing code to access
somebody else's database?

>>I am not suggesting that everyone who reads this article is a
>>nincompoop, but you may know someone who is.
>
>Tony, english is not my native language, so I may be misunderstanding
>this remark of yours.
>Are you perhaps implying what I think you are?

I don't know what you are thinking. I am suggesting that while you
personally may be able to see the logic and common sense in the numerous
points which are raised in my article, you may actually know of others who
keep making the same mistakes over and over again and fail to respond to
common sense and logic.

[Denis McMahon]

On Thu, 08 Nov 2012 06:53:54 +0000, Tony Marston wrote:

> Why don't you stop fixating on the word "nincompoop" and respond
> constructively to the bad practices which I have identified in that
> article.

If you want to show people your way of enlightenment, calling them
nincompoops / idiots / stupid / dense / dunces etc. is not the way to
engage with them.

Rgds

Denis McMahon

[The Natural Philosopher]

Furthermore its hard to see who its aimed at anyway..
Anyone learning to program a database app will have learnt formally, or
found out through experience, or have been forced to use through
corporate policy, all this stuff, anyway.

There must be dozens of books out there under 'software engineering'
already.


If someone exists who is both doing database programming and yet doesn't
know all this and hasn't read the book either, they aren't going to
listen to some nut on Usenet.


Why re-invent the wheel?




--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[Tony Marston]

"The Natural Philosopher" wrote in message
news:k7ga52$8db$1...@news.albasani.net...

>
>On 08/11/12 12:24, Denis McMahon wrote:
>> On Thu, 08 Nov 2012 06:53:54 +0000, Tony Marston wrote:
>>
>>> Why don't you stop fixating on the word "nincompoop" and respond
>>> constructively to the bad practices which I have identified in that
>>> article.
>>
>> If you want to show people your way of enlightenment, calling them
>> nincompoops / idiots / stupid / dense / dunces etc. is not the way to
>> engage with them.
>>
>> Rgds
>>
>> Denis McMahon
>>
>Furthermore its hard to see who its aimed at anyway..
>Anyone learning to program a database app will have learnt formally, or
>found out through experience, or have been forced to use through corporate
>policy, all this stuff, anyway.
>
>There must be dozens of books out there under 'software engineering'
>already.
>
>
>If someone exists who is both doing database programming and yet doesn't
>know all this and hasn't read the book either, they aren't going to listen
>to some nut on Usenet.
>
>
>Why re-invent the wheel?

You can't accuse me of reinventing the wheel when the wheel does not exist.
Can you point me to any resource on the internet which contains a list of
bad database design practices? Is these are not listed somewhere then how is
a poor newbie to know what is good and what is bad? You may think that what
I have written is common knowledge, but if it is then why are there still
people out there getting it wrong?

[Tony Marston]

"Denis McMahon" wrote in message news:k7g8a6$vq7$2...@dont-email.me...

The only people likely to be offended are those who recognise themselves to
be guilty of the bad practices which I have identified, and as I don't place
any value on the opinions of such people I don't care if they are offended
or not.

[The Natural Philosopher]

On 09/11/12 13:22, Tony Marston wrote:

> The only people likely to be offended are those who recognise themselves
> to be guilty of the bad practices which I have identified, and as I
> don't place any value on the opinions of such people I don't care if
> they are offended or not.
>

Thanks for the best 'coffee moment' of the day.

Golly, you are a self-opinionated little prick, aren't you?

[The Natural Philosopher]

Why biotyer? people want to now GOOD practice, not bad practice.

Is these are not listed somewhere
> then how is a poor newbie to know what is good and what is bad? You may
> think that what I have written is common knowledge, but if it is then
> why are there still people out there getting it wrong?
>

Maybe there is someone dumber than you?

[Tony Marston]

"The Natural Philosopher" wrote in message

news:k7j2tl$jsc$1...@news.albasani.net...

>
>On 09/11/12 13:22, Tony Marston wrote:
>
>> The only people likely to be offended are those who recognise themselves
>> to be guilty of the bad practices which I have identified, and as I
>> don't place any value on the opinions of such people I don't care if
>> they are offended or not.
>>
>Thanks for the best 'coffee moment' of the day.
>
>Golly, you are a self-opinionated little prick, aren't you?

At least I have opinions. The fact that you don't like them doesn't concern
me in the least.

[Tony Marston]

"The Natural Philosopher" wrote in message

news:k7j2vm$jsc$2...@news.albasani.net...

Your spelling is atrocious! Go and stand in the naughty corner!

If you disagree with the points I raised then what is your justification?

>Is these are not listed somewhere
>> then how is a poor newbie to know what is good and what is bad? You may
>> think that what I have written is common knowledge, but if it is then
>> why are there still people out there getting it wrong?
>>
>
>Maybe there is someone dumber than you?

Have you looked in the mirror lately?

[The Natural Philosopher]

On 09/11/12 16:25, Tony Marston wrote:
> "The Natural Philosopher" wrote in message
> news:k7j2tl$jsc$1...@news.albasani.net...
>>
>> On 09/11/12 13:22, Tony Marston wrote:
>>
>>> The only people likely to be offended are those who recognise themselves
>>> to be guilty of the bad practices which I have identified, and as I
>>> don't place any value on the opinions of such people I don't care if
>>> they are offended or not.
>>>
>> Thanks for the best 'coffee moment' of the day.
>>
>> Golly, you are a self-opinionated little prick, aren't you?
>
> At least I have opinions.

That the whole problem. That's all they are.

Opinions.

And you seem PROUD of that?

>The fact that you don't like them doesn't
> concern me in the least.
>

Its not the opinions I don't like....they are not worth liking or
disliking..

[Gordon]

On 2012-11-05, Tony Marston <TonyM...@hotmail.com> wrote:
> When you design your database for your application are you aware that
> some of your design decisions can have a detrimental effect when it comes to
> writing the code to access that database? I have been designing databases,
> and building the applications which use them, for several decades, and I
> have learned over the years that there are some design decisions which help
> the developer while others do nothing more than hinder. I have produced a
> document which lists 14 of these “hindrances” which can be read at
> http://www.tonymarston.net/php-mysql/database-design-ru-novice-ninja-or-nincompoop.html
>

I know that database design is *very* important. One needs to think longer
and harder about its structure than almost all people think. For it is
important.

[Tony Marston]

"Gordon" wrote in message news:ag64m1...@mid.individual.net...

Yes, it *IS* important. Very, very important. It is also important that it
is designed correctly otherwise it could have a detrimental effect on the
software which is supposed to access it. It is wrong to say that *any*
design is acceptable because after many years of being exposed to different
design ideas I can say that some ideas are definitely better than others.
The purpose of my article was to say "you may think that these database
design ideas are good, but they are not as good as you think, and here are
the reasons why".

[Tony Marston]

"The Natural Philosopher" wrote in message

news:k7jh7v$k8e$3...@news.albasani.net...

>
>On 09/11/12 16:25, Tony Marston wrote:
>> "The Natural Philosopher" wrote in message
>> news:k7j2tl$jsc$1...@news.albasani.net...
>>>
>>> On 09/11/12 13:22, Tony Marston wrote:
>>>
>>>> The only people likely to be offended are those who recognise
>>>> themselves
>>>> to be guilty of the bad practices which I have identified, and as I
>>>> don't place any value on the opinions of such people I don't care if
>>>> they are offended or not.
>>>>
>>> Thanks for the best 'coffee moment' of the day.
>>>
>>> Golly, you are a self-opinionated little prick, aren't you?
>>
>> At least I have opinions.
>
>That the whole problem. That's all they are.
>
>Opinions.
>
>And you seem PROUD of that?
>
>
>>The fact that you don't like them doesn't
>> concern me in the least.
>>
>
>Its not the opinions I don't like....they are not worth liking or
>disliking..

Why don't you grow up and criticise the message instead of the messenger. I
don't care whether you like me or not, or the way that I say things. It is
*WHAT* I say which is important.

By saying that you disagree with my message you are announcing to the world
that you regularly employ all those bad practices in your database designs,
which means that your database designs are not as good as you think they
are. If you disagree with the numerous points which I identified in my
article can you do the grownup thing and provide contra-arguments? Or are
you incapable of anything except personal abuse?

[Tony Marston]

I have now updated my article to include 4 extra items, so my list of
"un-cool" practices goes up from 14 to 18.

"Tony Marston" wrote in message news:tYons.258891$Tf3....@fx12.am4...

[The Natural Philosopher]

Except they are not new and not important.

> By saying that you disagree with my message you are announcing to the
> world that you regularly employ all those bad practices in your database
> designs, which means that your database designs are not as good as you
> think they are.

No, I am not announcing anything of the sort, and its yours blinded
egotiss that makes you say that.

> If you disagree with the numerous points which I
> identified in my article can you do the grownup thing and provide
> contra-arguments? Or are you incapable of anything except personal abuse?
>

Oh *I* am capable of much more ..its you that is resorting to personal
abuse.

"Let me tell you a secret I learnt from a witch: Water is Wet!".

Its only the crass ignorance you must have laboured under to regard
anything you have said as more than the most basic elementary knowledge
that anyone who approaches database design must know already.

The astonishing thing is not that you have arrived at it, but that you
appear to think that no one else has - the reality is its second nature
to the point where its not worth remarking upon.

[The Natural Philosopher]

Breathing is very important too, to the point where if you stop, its a
permanent bug.

[Tony Marston]

"The Natural Philosopher" wrote in message

news:k7o1da$sk$1...@news.albasani.net...

>
>On 10/11/12 09:22, Tony Marston wrote:
>> "The Natural Philosopher" wrote in message
>> news:k7jh7v$k8e$3...@news.albasani.net...
>>>

>>>>> On 09/11/12 13:22, Tony Marston wrote:
>>>>>
>>>>>> The only people likely to be offended are those who recognise
>>>>>> themselves
>>>>>> to be guilty of the bad practices which I have identified, and as I
>>>>>> don't place any value on the opinions of such people I don't care if
>>>>>> they are offended or not.
>>>>>>
>>>>> Thanks for the best 'coffee moment' of the day.
>>>>>
>>>>> Golly, you are a self-opinionated little prick, aren't you?
>>>>
>>>> At least I have opinions.
>>>
>>> That the whole problem. That's all they are. Opinions.
>>>
>>> And you seem PROUD of that?
>>>
>>>
>>>> The fact that you don't like them doesn't
>>>> concern me in the least.
>>>>
>>>
>>> Its not the opinions I don't like....they are not worth liking or
>>> disliking..
>>
>> Why don't you grow up and criticise the message instead of the
>> messenger. I don't care whether you like me or not, or the way that I
>> say things. It is *WHAT* I say which is important.
>>
>
>Except they are not new and not important.

Then show me any resource on the internet which identifies these same
points.

>> By saying that you disagree with my message you are announcing to the
>> world that you regularly employ all those bad practices in your database
>> designs, which means that your database designs are not as good as you
>> think they are.
>
>No, I am not announcing anything of the sort, and its yours blinded egotiss
>that makes you say that.
>
>> If you disagree with the numerous points which I
>> identified in my article can you do the grownup thing and provide
>> contra-arguments? Or are you incapable of anything except personal abuse?
>>
>
>Oh *I* am capable of much more ..its you that is resorting to personal
>abuse.

Show me where in any of my posts where I have used personal abuse? *YOU* are
the one who keeps calling me a self-opinionated prick, not the other way
around.

Tony Marston