|
|
Posted by Jeff North on 06/30/05 20:38
On Thu, 30 Jun 2005 10:12:49 -0500, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net> wrote:
>| Jeff North wrote:
>| > On Wed, 29 Jun 2005 17:36:21 -0500, in comp.lang.php Jerry Stuckle
>| > <jstucklex@attglobal.net> wrote:
[snip]
>| >>| 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.
>|
>| Then why is normalization so important? A properly normalized database is
>| almost without exception better than an unnormalized one.
Normalisation is good.
But there are databases that are more efficient when not normalised.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ssceqpop.mspx
and scroll to "Consider Database De-normalization".
IOW there are times when you should normalise and there are times when
you shouldn't normalise.
Now lets throw the cat amongst the pidgeons :-)
Here is a simplified example of my data:
en fr it sp
---------------------------------------------------
Hello bonjour ciao hola
Goodbye au revoir arrivederci adiós
password mot de passe parola d'accesso contraseña
Now, is there *really* any repeating data?
Yeah, I know, it can be argued either way.
>| >>| 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.
>|
>| How do you do it with your page?
The id field or looking for a particular phrase in the field.
>| In his case, he just wants to store the entire page in a table. This works fine
>| for it.
True. But (there's always a but isn't there :-) ) what if there are
multiple areas on the page? What if the page is a form with multiple
fields?
A (slightly) different table structure will need to be used.
I've shown one method, you've shown another.
Which is better - depends upon your requirements.
Lets consider another common layout.
You have a page with 3 columns.
Column 1 is the menu.
Column 2 is the content.
Column 3 is adverts specific to that country.
In the above case neither of our table designs would be suitable.
>| If you have several fields, normalization is even more important. You could add
>| a third column to pagename and language - that being "field". Each row would be
>| identified by a pagename, a language and a field. It now becomes quite easy to
>| add or delete languages, fields and rows.
I think you are making the assumption that I'm returning all fields
from the table, I'm not.
(JScript example as I'm not proficent in php)
Entire page contents:
sql ="SELECT pageName,id," + Session("UserLanguage") + " FROM
usr_language WHERE PageName=" + currentPage + " ORDER BY id";
Single item:
sql = "SELECT " + Session("UserLanguage") + " FROM usr_language WHERE
en like '" + phrase + "%'";
As I've said previously "Each method has it's pros and cons. Neither
is better than the other."
---------------------------------------------------------------
jnorthau@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Navigation:
[Reply to this message]
|