| Re: Bad database design can cause unnecessary coding [message #179524 is a reply to message #179522] |
Sun, 04 November 2012 12:29   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 11/4/2012 5:18 AM, Tony Marston wrote:
> "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.
>
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(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]