|
|
Posted by Jeff North on 06/30/05 03:00
On Wed, 29 Jun 2005 17:36:21 -0500, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net> wrote:
>| madsgormlarsen@gmail.com wrote:
>| > Is what you are suggesting something along these lines?
>| >
>| > or do you agree with Jeff?
>| >
>| > CREATE TABLE `usr_languages` (
>| > `pageName` varchar(25) default '',
>| > `id` int(11) default '0',
>| > `language` char(2),
>| > `Actual_info` text,
>| > )
>| >
>|
>| No, I do not agree with Jeff. His design, while it works, makes the code very
>| difficult to modify should he ever want to add a new language. To do so would
>| require changing the database - and an examination of all the code which
>| accesses the database. No, all the code would not HAVE to be modified - but all
>| would have to be inspected.
Each method has it's pros and cons. Neither is better than the other.
>| Normalizing the database helps with these effects. You don't need to change
>| column names in your queries, for instance. It means if you have a bad language
>| value (i.e. no sw(ahili) column), you get no data back instead of a MySQL query
>| error.
>|
>| The method you quoted is much clearer - except you really don't need an "id"
>| column. Rather, the primary key should be "pageName, language".
If you have 20 fields on a webpage, how would you work out what text
goes where?
NB: where I use this is on forms where there are lots of prompts,
tooltips and other textual information.
>| I don't have any tutorials in mind - but if you do a google search on "database
>| normalization" you should find several.
---------------------------------------------------------------
jnorthau@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Navigation:
[Reply to this message]
|