FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Bad database design can cause unnecessary coding
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Bad database design can cause unnecessary coding [message #179517 is a reply to message #179504] Sat, 03 November 2012 18:00 Go to previous messageGo to previous message
M. Strobel is currently offline  M. Strobel
Messages: 386
Registered: December 2011
Karma:
Senior Member
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.

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

/Str.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: php daemon
Next Topic: keeping the page content stay in their positions and not merging
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Nov 22 08:16:33 GMT 2024

Total time taken to generate the page: 0.05479 seconds