| Re: Bad database design can cause unnecessary coding [message #179522 is a reply to message #179517] |
Sun, 04 November 2012 10:18   |
Tony Marston
Messages: 57
Registered: November 2010
Karma:
|
Member |
|
|
"M. Strobel" wrote in message news:afl4egF9vukU1(at)mid(dot)uni-berlin(dot)de...
>
> Am 03.11.2012 10:14, schrieb Tony Marston:
>> "M. Strobel" wrote in message news:afhg10Ff1jjU1(at)mid(dot)uni-berlin(dot)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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]