Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #7423 > unrolled thread

Bad database design can cause unnecessary coding

Back to article view | Back to comp.lang.php

Contents

  Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-02 07:12 +0000
    Re: Bad database design can cause unnecessary coding "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-11-02 09:53 +0100
      Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-03 09:14 +0000
        Re: Bad database design can cause unnecessary coding "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-11-03 18:01 +0100
          Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-03 15:03 -0400
          Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-04 10:11 +0000
            Re: Bad database design can cause unnecessary coding "Peter H. Coffin" <hellsop@ninehells.com> - 2012-11-04 14:37 -0600
        Re: Bad database design can cause unnecessary coding "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-11-03 19:00 +0100
          Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-04 10:18 +0000
            Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-04 07:29 -0500
    Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-02 06:48 -0400
      Re: Bad database design can cause unnecessary coding Goran <goran@nospam.com> - 2012-11-02 12:34 +0100
        Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-02 07:48 -0400
          Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-03 09:28 +0000
            Re: Bad database design can cause unnecessary coding "J.O. Aho" <user@example.net> - 2012-11-03 10:56 +0100
              Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-04 10:09 +0000
                Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-04 07:32 -0500
                Re: Bad database design can cause unnecessary coding "J.O. Aho" <user@example.net> - 2012-11-04 16:45 +0100
            Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-03 10:52 -0400
        Re: Bad database design can cause unnecessary coding The Natural Philosopher <tnp@invalid.invalid> - 2012-11-02 11:56 +0000
      Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-03 09:17 +0000
        Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-03 10:54 -0400
          Re: Bad database design can cause unnecessary coding Luuk <luuk@invalid.lan> - 2012-11-03 16:06 +0100
            Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-03 11:25 -0400
    Re: Bad database design can cause unnecessary coding Denis McMahon <denismfmcmahon@gmail.com> - 2012-11-02 11:13 +0000
      Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-03 09:31 +0000
        Re: Bad database design can cause unnecessary coding Denis McMahon <denismfmcmahon@gmail.com> - 2012-11-03 13:08 +0000
          Re: Bad database design can cause unnecessary coding Jerry Stuckle <jstucklex@attglobal.net> - 2012-11-03 10:55 -0400
          Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-04 10:04 +0000
    Re: Bad database design can cause unnecessary coding Luuk <luuk@invalid.lan> - 2012-11-03 11:04 +0100
      Re: Bad database design can cause unnecessary coding "Tony Marston" <TonyMarston@hotmail.com> - 2012-11-04 10:30 +0000
    Re: Bad database design can cause unnecessary coding Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-11-15 15:49 +0100
      Re: Bad database design can cause unnecessary coding "Peter H. Coffin" <hellsop@ninehells.com> - 2012-11-15 12:03 -0600

Page 1 of 2  [1] 2  Next page →

#7423 — Bad database design can cause unnecessary coding

When you design your database for your PHP 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 

[toc] | [next] | [standalone]

#7424

Am 02.11.2012 08:12, schrieb Tony Marston:
> When you design your database for your PHP 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? 

All your design decisions can have a detrimental or beneficial effect. The word "can"
even is too weak, since the database design is the base of your application.

I don't like the phrasing "code to access the database". What you want to access AND
use is your data.

Maybe I am nitpicking, but precision in wording shows precision in concept. That is
what programmers need.

/Str.

[toc] | [prev] | [next] | [standalone]

#7435

"M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>
>Am 02.11.2012 08:12, schrieb Tony Marston:
>> When you design your database for your PHP 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?
>
>All your design decisions can have a detrimental or beneficial effect. The 
>word "can"
>even is too weak, since the database design is the base of your 
>application.
>
>I don't like the phrasing "code to access the database". What you want to 
>access AND
>use is your data.
>
>Maybe I am nitpicking, but precision in wording shows precision in concept. 
>That is
>what programmers need.
>
>/Str.

Instead of nitpicking over the words I used why don't you try and show how 
intelligent you are by commenting on the 14 "bad" practices that I have 
identified. Do you agree with them? Do you disagree? Do you have any more to 
add? Or does your limited experience not go as far as designing the 
databases that your applications use? Or don't you write database 
applications?

-- 
Tony Marston

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

[toc] | [prev] | [next] | [standalone]

#7447

Am 03.11.2012 10:14, schrieb Tony Marston:
> "M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>>
>> Am 02.11.2012 08:12, schrieb Tony Marston:
>>> When you design your database for your PHP 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?
>>
>> All your design decisions can have a detrimental or beneficial effect. The word "can"
>> even is too weak, since the database design is the base of your application.
>>
>> I don't like the phrasing "code to access the database". What you want to access AND
>> use is your data.
>>
>> Maybe I am nitpicking, but precision in wording shows precision in concept. That is
>> what programmers need.
>>
>> /Str.
> 
> Instead of nitpicking over the words I used why don't you try and show how

Okay, leave out the nitpicking and take it as constructive proposal.

> intelligent you are by commenting on the 14 "bad" practices that I have identified.
> Do you agree with them? Do you disagree? Do you have any more to add? Or does your

Sounds like a lot of work. Advice is okay, work must be payed.

> limited experience not go as far as designing the databases that your applications
> use? Or don't you write database applications?
> 
Sorry, I forgot all since I managed DB2 in the early nineties. Forgot all from 15
years as IT trainer. Forgot more than others ever knew :-)

/Str.

[toc] | [prev] | [next] | [standalone]

#7449

On 11/3/2012 1:01 PM, M. Strobel wrote:
> Am 03.11.2012 10:14, schrieb Tony Marston:
>> "M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>>>
>>> Am 02.11.2012 08:12, schrieb Tony Marston:
>>>> When you design your database for your PHP 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?
>>>
>>> All your design decisions can have a detrimental or beneficial effect. The word "can"
>>> even is too weak, since the database design is the base of your application.
>>>
>>> I don't like the phrasing "code to access the database". What you want to access AND
>>> use is your data.
>>>
>>> Maybe I am nitpicking, but precision in wording shows precision in concept. That is
>>> what programmers need.
>>>
>>> /Str.
>>
>> Instead of nitpicking over the words I used why don't you try and show how
>
> Okay, leave out the nitpicking and take it as constructive proposal.
>
>> intelligent you are by commenting on the 14 "bad" practices that I have identified.
>> Do you agree with them? Do you disagree? Do you have any more to add? Or does your
>
> Sounds like a lot of work. Advice is okay, work must be payed.
>
>> limited experience not go as far as designing the databases that your applications
>> use? Or don't you write database applications?
>>
> Sorry, I forgot all since I managed DB2 in the early nineties. Forgot all from 15
> years as IT trainer. Forgot more than others ever knew :-)
>
> /Str.
>

Matt, you're arguing with an idiot.  He's so stoopid he doesn't even 
understand there are things he doesn't know.  He thinks he's the world 
expert, and anyone who disagrees with him (even widely recognized 
experts) are wrong.

He's just finding excuses to spam his crap site - and add more "tips" to 
prove how "knowledgeable" he is.  The only problem is, to those who are 
really knowledgeable, he looks like an ass.  And, unfortunately, there 
are people who will try his tricks and go way off on the wrong track.

He's even worse than TNP. At least TNP doesn't spam.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7452

"M. Strobel"  wrote in message news:afl0ueF96jhU1@mid.uni-berlin.de...
>
>Am 03.11.2012 10:14, schrieb Tony Marston:
>> "M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>>>
>>> Am 02.11.2012 08:12, schrieb Tony Marston:
>>>> When you design your database for your PHP 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?
>>>
>>> All your design decisions can have a detrimental or beneficial effect. 
>>> The word "can"
>>> even is too weak, since the database design is the base of your 
>>> application.
>>>
>>> I don't like the phrasing "code to access the database". What you want 
>>> to access AND
>>> use is your data.
>>>
>>> Maybe I am nitpicking, but precision in wording shows precision in 
>>> concept. That is
>>> what programmers need.
>>>
>>> /Str.
>>
>> Instead of nitpicking over the words I used why don't you try and show 
>> how
>
>Okay, leave out the nitpicking and take it as constructive proposal.
>
>> intelligent you are by commenting on the 14 "bad" practices that I have 
>> identified.
>> Do you agree with them? Do you disagree? Do you have any more to add? Or 
>> does your
>
>Sounds like a lot of work. Advice is okay, work must be payed.
>
>> limited experience not go as far as designing the databases that your 
>> applications
>> use? Or don't you write database applications?
>>
>Sorry, I forgot all since I managed DB2 in the early nineties. Forgot all 
>from 15
>years as IT trainer. Forgot more than others ever knew :-)
>
>/Str.

So even with all those years of experience you are still unable to reply 
intelligently and constructively to the 14 points I raised in my article?

-- 
Tony Marston

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

[toc] | [prev] | [next] | [standalone]

#7459

On Sun, 4 Nov 2012 10:11:42 -0000, Tony Marston wrote:

> "M. Strobel" wrote in message news:afl0ueF96jhU1@mid.uni-berlin.de...
>
>>Sorry, I forgot all since I managed DB2 in the early nineties. Forgot
>>all from 15 years as IT trainer. Forgot more than others ever knew :-)
>>
>>/Str.
>
> So even with all those years of experience you are still unable to
> reply intelligently and constructively to the 14 points I raised in my
> article?

Can, could, won't address irrelevant points in this discussion. It's
your *behavior* at issue.

-- 
The light at the end of the tunnel is not an oncoming train.

It is muzzle-flash.

[toc] | [prev] | [next] | [standalone]

#7448

Am 03.11.2012 10:14, schrieb Tony Marston:
> "M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>>
>> Am 02.11.2012 08:12, schrieb Tony Marston:
>>> When you design your database for your PHP 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?
>>
>> All your design decisions can have a detrimental or beneficial effect. The word "can"
>> even is too weak, since the database design is the base of your application.
>>
>> I don't like the phrasing "code to access the database". What you want to access AND
>> use is your data.
>>
>> Maybe I am nitpicking, but precision in wording shows precision in concept. That is
>> what programmers need.
>>
>> /Str.
> 
> Instead of nitpicking over the words I used why don't you try and show how
> intelligent you are by commenting on the 14 "bad" practices that I have identified.
> Do you agree with them? Do you disagree? Do you have any more to add? Or does your

another kind of answer:

The general problem is that you throw condensed knowledge at novices. They most often
won't be able to understand and make use of it.

Then your advice often is simply on the coding convention level, not on the design
level. Coding conventions can be different, but they must be consistent. Example
Gotcha #1: Multi-table JOINS:

First you give a complex select example with outer joins that is outright nonsense,
because the joined tables are not used. Then you advice against table aliases.

My standards: name every integer primary key column with "id". Name every foreign key
with the name of the corresponding object. Table aliases on selects must be standard,
and leave out AS because it is only noise.

Example: the product id is "id", the product id in the orders table is product_id.

This all does not answer the question which design decisions have a detrimental
effect on _coding_ .

/Str.

[toc] | [prev] | [next] | [standalone]

#7453

"M. Strobel"  wrote in message news:afl4egF9vukU1@mid.uni-berlin.de...
>
>Am 03.11.2012 10:14, schrieb Tony Marston:
>> "M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>>>
>>> Am 02.11.2012 08:12, schrieb Tony Marston:
>>>> When you design your database for your PHP 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?
>>>
>>> All your design decisions can have a detrimental or beneficial effect. 
>>> The word "can"
>>> even is too weak, since the database design is the base of your 
>>> application.
>>>
>>> I don't like the phrasing "code to access the database". What you want 
>>> to access AND
>>> use is your data.
>>>
>>> Maybe I am nitpicking, but precision in wording shows precision in 
>>> concept. That is
>>> what programmers need.
>>>
>>> /Str.
>>
>> Instead of nitpicking over the words I used why don't you try and show 
>> how
>> intelligent you are by commenting on the 14 "bad" practices that I have 
>> identified.
>> Do you agree with them? Do you disagree? Do you have any more to add? Or 
>> does your
>
>another kind of answer:
>
>The general problem is that you throw condensed knowledge at novices. They 
>most often
>won't be able to understand and make use of it.
>
>Then your advice often is simply on the coding convention level, not on the 
>design
>level. Coding conventions can be different, but they must be consistent. 
>Example
>Gotcha #1: Multi-table JOINS:
>
>First you give a complex select example with outer joins that is outright 
>nonsense,
>because the joined tables are not used. Then you advice against table 
>aliases.
>
>My standards: name every integer primary key column with "id". Name every 
>foreign key
>with the name of the corresponding object. Table aliases on selects must be 
>standard,
>and leave out AS because it is only noise.
>
>Example: the product id is "id", the product id in the orders table is 
>product_id.

Yuk! That's the complete opposite of what I preach.

>This all does not answer the question which design decisions have a 
>detrimental
>effect on _coding_ .
>
>/Str.

Design decisions in the database *DO* affect coding as some decisions 
require more coding than others with some SQL queries having to be 
individually crafted by hand. I personally prefer decisions which require 
less coding as it requires less hand crafting and can sometimes be 
automated.

-- 
Tony Marston

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

[toc] | [prev] | [next] | [standalone]

#7455

On 11/4/2012 5:18 AM, Tony Marston wrote:
> "M. Strobel"  wrote in message news:afl4egF9vukU1@mid.uni-berlin.de...
>>
>> Am 03.11.2012 10:14, schrieb Tony Marston:
>>> "M. Strobel"  wrote in message news:afhg10Ff1jjU1@mid.uni-berlin.de...
>>>>
>>>> Am 02.11.2012 08:12, schrieb Tony Marston:
>>>>> When you design your database for your PHP 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?
>>>>
>>>> All your design decisions can have a detrimental or beneficial
>>>> effect. The word "can"
>>>> even is too weak, since the database design is the base of your
>>>> application.
>>>>
>>>> I don't like the phrasing "code to access the database". What you
>>>> want to access AND
>>>> use is your data.
>>>>
>>>> Maybe I am nitpicking, but precision in wording shows precision in
>>>> concept. That is
>>>> what programmers need.
>>>>
>>>> /Str.
>>>
>>> Instead of nitpicking over the words I used why don't you try and
>>> show how
>>> intelligent you are by commenting on the 14 "bad" practices that I
>>> have identified.
>>> Do you agree with them? Do you disagree? Do you have any more to add?
>>> Or does your
>>
>> another kind of answer:
>>
>> The general problem is that you throw condensed knowledge at novices.
>> They most often
>> won't be able to understand and make use of it.
>>
>> Then your advice often is simply on the coding convention level, not
>> on the design
>> level. Coding conventions can be different, but they must be
>> consistent. Example
>> Gotcha #1: Multi-table JOINS:
>>
>> First you give a complex select example with outer joins that is
>> outright nonsense,
>> because the joined tables are not used. Then you advice against table
>> aliases.
>>
>> My standards: name every integer primary key column with "id". Name
>> every foreign key
>> with the name of the corresponding object. Table aliases on selects
>> must be standard,
>> and leave out AS because it is only noise.
>>
>> Example: the product id is "id", the product id in the orders table is
>> product_id.
>
> Yuk! That's the complete opposite of what I preach.
>
>> This all does not answer the question which design decisions have a
>> detrimental
>> effect on _coding_ .
>>
>> /Str.
>
> Design decisions in the database *DO* affect coding as some decisions
> require more coding than others with some SQL queries having to be
> individually crafted by hand. I personally prefer decisions which
> require less coding as it requires less hand crafting and can sometimes
> be automated.
>

That's because you don't know how to properly write code.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7425

On 11/2/2012 3:12 AM, Tony Marston wrote:
> When you design your database for your PHP 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.iamaspammer.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.iamaspammer.net
> http://www.iamaspammer.org

You wouldn't know a good design if it was shown to you, spammer.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7427

On 2.11.2012 11:48, Jerry Stuckle wrote:
> You wouldn't know a good design if it was shown to you, spammer.

And why is that? Why are you acting like a mad man?

[toc] | [prev] | [next] | [standalone]

#7429

On 11/2/2012 7:34 AM, Goran wrote:
> On 2.11.2012 11:48, Jerry Stuckle wrote:
>> You wouldn't know a good design if it was shown to you, spammer.
>
> And why is that? Why are you acting like a mad man?
>

If he really wanted to start a discussion, he would have started it on 
usenet, in an appropriate newsgroup (database design is NOT a PHP topic!).

His only purpose in posting here was to spam his site.  He must have run 
out of suckers who were willing to pay him (again).  Just look at his 
site and you can see how his overly-inflated ego doesn't let him realize 
how stoopid he looks to knowledgeable people - or what a piece of crap 
his "rapid development tool" really is.

But then Tony is well-known here for all of the above.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7437

"Jerry Stuckle"  wrote in message news:k70buo$2bo$1@dont-email.me...
>
>On 11/2/2012 7:34 AM, Goran wrote:
>> On 2.11.2012 11:48, Jerry Stuckle wrote:
>>> You wouldn't know a good design if it was shown to you, spammer.
>>
>> And why is that? Why are you acting like a mad man?
>>
>
>If he really wanted to start a discussion, he would have started it on 
>usenet, in an appropriate newsgroup (database design is NOT a PHP topic!).
>
>His only purpose in posting here was to spam his site.  He must have run 
>out of suckers who were willing to pay him (again).  Just look at his site 
>and you can see how his overly-inflated ego doesn't let him realize how 
>stoopid he looks to knowledgeable people - or what a piece of crap his 
>"rapid development tool" really is.
>
>But then Tony is well-known here for all of the above.
>

It *IS* a PHP topic for the simple reason that almost every PHP program 
accesses a database, and most databases are designed by the programmer 
him/herself. What I have attempted to do in my article is identify those 
design decisions which are not actually as good as the designer thinks they 
are. Bad designs cause the programmer to write extra code which should not 
be necessary. If you follow good design practices you can end up writing 
less code, or even have that code generated for you so that you don't even 
have to write it. Which do you think is the better idea - writing 
unnecessary code, or having that code generated for you?

This should be a topic of interest for all programmers in general, and PHP 
programmers in particular (after all, I have been designing and developing 
business applications using PHP for the last 10 years or so).

Instead of your usual personal attacks why don't you show the depth of your 
intelligence and experience by actually responding to the 14 points 
contained in my article? Or is that beyond your capabilities?

-- 
Tony Marston

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

[toc] | [prev] | [next] | [standalone]

#7439

On 03/11/12 10:28, Tony Marston wrote:

> It *IS* a PHP topic for the simple reason that almost every PHP program
> accesses a database, and most databases are designed by the programmer
> him/herself.

I have to agree with Jerry that it's off topic in this news group, it 
had been more on topic at alt.php.sql.

Something that people dislike here and most other usergroups is that 
promotion of your own site and most of the time it's done in a usergroup 
it's quite low quality or even requiring payment to access the low 
quality information.

A better way to do is to start a discussion and show your skills in 
there without promoting a website of self-interest.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#7451

"J.O. Aho"  wrote in message news:afk82dF3gokU1@mid.individual.net...
>
>On 03/11/12 10:28, Tony Marston wrote:
>
>> It *IS* a PHP topic for the simple reason that almost every PHP program
>> accesses a database, and most databases are designed by the programmer
>> him/herself.
>
>I have to agree with Jerry that it's off topic in this news group, it had 
>been more on topic at alt.php.sql.

Are you saying that it is forbidden to post anything related to SQL on this 
newsgroup? What about HTML? CSS? JavaScript?

>Something that people dislike here and most other usergroups is that 
>promotion of your own site and most of the time it's done in a usergroup 
>it's quite low quality or even requiring payment to access the low quality 
>information.

I pointed to a separate article for the simple reason that it was too large 
to post here. I was not saying "please visit my site which contains lots of 
stuff".

>A better way to do is to start a discussion and show your skills in there 
>without promoting a website of self-interest.

If you can't be bothered to read the article and respond intelligently to 
the points raised in it then don't respond at all.

-- 
Tony Marston

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

[toc] | [prev] | [next] | [standalone]

#7456

On 11/4/2012 5:09 AM, Tony Marston wrote:
> "J.O. Aho"  wrote in message news:afk82dF3gokU1@mid.individual.net...
>>
>> On 03/11/12 10:28, Tony Marston wrote:
>>
>>> It *IS* a PHP topic for the simple reason that almost every PHP program
>>> accesses a database, and most databases are designed by the programmer
>>> him/herself.
>>
>> I have to agree with Jerry that it's off topic in this news group, it
>> had been more on topic at alt.php.sql.
>
> Are you saying that it is forbidden to post anything related to SQL on
> this newsgroup? What about HTML? CSS? JavaScript?
>

This is not a SQL newsgroup.  Neither is it a HTML, CSS or Javascript 
newsgroup.  But you don't know the difference, so you don't understand why.

>> Something that people dislike here and most other usergroups is that
>> promotion of your own site and most of the time it's done in a
>> usergroup it's quite low quality or even requiring payment to access
>> the low quality information.
>
> I pointed to a separate article for the simple reason that it was too
> large to post here. I was not saying "please visit my site which
> contains lots of stuff".
>

You spammed your site.

>> A better way to do is to start a discussion and show your skills in
>> there without promoting a website of self-interest.
>
> If you can't be bothered to read the article and respond intelligently
> to the points raised in it then don't respond at all.
>

And if you can't be bothered to post your points in an on-topic 
newsgroup, then don't post at all.

I'm not the only one telling you it's off topic.  Why don't you figure 
it out - this is not your personal newsgroup for posting whatever YOU 
feel is on topic.  This newsgroup has a charter, and that charter 
defines what is on topic or not.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7457

On 04/11/12 11:09, Tony Marston wrote:
> "J.O. Aho"  wrote in message news:afk82dF3gokU1@mid.individual.net...
>>
>> On 03/11/12 10:28, Tony Marston wrote:
>>
>>> It *IS* a PHP topic for the simple reason that almost every PHP program
>>> accesses a database, and most databases are designed by the programmer
>>> him/herself.
>>
>> I have to agree with Jerry that it's off topic in this news group, it
>> had been more on topic at alt.php.sql.
>
> Are you saying that it is forbidden to post anything related to SQL on
> this newsgroup? What about HTML? CSS? JavaScript?

Yes, HTML, CSS and JavaScript are also off topic here, as they don't 
have anything to do with the PHP. Try to see the different usergroups as 
sorting mail, you don't mix your business mail with your private, as it 
makes it easier to find the right mail when you are looking for a mail 
from a friend with his vacation photos.

For this reason a post in comp.lang.php may be on-topic, while it's 
off-topic in alt.php.sql (and the other way too) and there are times 
when a post can be on-topic on both or none. It's up to the poster to 
keep it on-topic and promoting a site is in general off-topic on most 
usergroups.


>> Something that people dislike here and most other usergroups is that
>> promotion of your own site and most of the time it's done in a
>> usergroup it's quite low quality or even requiring payment to access
>> the low quality information.
>
> I pointed to a separate article for the simple reason that it was too
> large to post here. I was not saying "please visit my site which
> contains lots of stuff".

You kind of did that, as you started a new thread and promoted your site 
(article), it had been a lot different if there had been someone asking 
how to make a good database design on a database related usergroup, then 
you could have posted your link and said here you can read some stuff I 
have discovered.


>> A better way to do is to start a discussion and show your skills in
>> there without promoting a website of self-interest.
>
> If you can't be bothered to read the article and respond intelligently
> to the points raised in it then don't respond at all.

You didn't post to increase the number of visitors to IBMs "Approach's 
database design and how to use a relational database", but to your own 
site and in the completely wrong usergroup.

I'm not replying to your articles content, but trying to explain why 
people dislike what you did.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#7442

On 11/3/2012 5:28 AM, Tony Marston wrote:
> "Jerry Stuckle"  wrote in message news:k70buo$2bo$1@dont-email.me...
>>
>> On 11/2/2012 7:34 AM, Goran wrote:
>>> On 2.11.2012 11:48, Jerry Stuckle wrote:
>>>> You wouldn't know a good design if it was shown to you, spammer.
>>>
>>> And why is that? Why are you acting like a mad man?
>>>
>>
>> If he really wanted to start a discussion, he would have started it on
>> usenet, in an appropriate newsgroup (database design is NOT a PHP
>> topic!).
>>
>> His only purpose in posting here was to spam his site.  He must have
>> run out of suckers who were willing to pay him (again).  Just look at
>> his site and you can see how his overly-inflated ego doesn't let him
>> realize how stoopid he looks to knowledgeable people - or what a piece
>> of crap his "rapid development tool" really is.
>>
>> But then Tony is well-known here for all of the above.
>>
>
> It *IS* a PHP topic for the simple reason that almost every PHP program
> accesses a database, and most databases are designed by the programmer
> him/herself. What I have attempted to do in my article is identify those
> design decisions which are not actually as good as the designer thinks
> they are. Bad designs cause the programmer to write extra code which
> should not be necessary. If you follow good design practices you can end
> up writing less code, or even have that code generated for you so that
> you don't even have to write it. Which do you think is the better idea -
> writing unnecessary code, or having that code generated for you?
>
> This should be a topic of interest for all programmers in general, and
> PHP programmers in particular (after all, I have been designing and
> developing business applications using PHP for the last 10 years or so).
>
> Instead of your usual personal attacks why don't you show the depth of
> your intelligence and experience by actually responding to the 14 points
> contained in my article? Or is that beyond your capabilities?
>

You are so stoopid you don't even know the difference between a database 
and a programming language.  But then spammers aren't very smart, and 
you're even more stoopid than most spammers.  Even your rants on your 
own site show that - they have provided a group of us with good laughs.

If it's on topic here, show us where the PHP manual discusses "database 
design".

But you can't, because it isn't there.  So take your bullshit somewhere 
else.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7430

On 02/11/12 11:34, Goran wrote:
> On 2.11.2012 11:48, Jerry Stuckle wrote:
>> You wouldn't know a good design if it was shown to you, spammer.
>
> And why is that? Why are you acting like a mad man?
>
Its not an act....

-- 
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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web