tf
Расскажу, отчего не рассказать.
DruidM
Структура БД - это не то чем программа не должна оперировать, программа должна оперировать ДАННЫМИ а не менять их СТРУКТУРУ - т.е. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ.
Область же не меняется - почему вы тогда хотите менять модель?
Многоязычность на сайте реализовать несложно. Сперва нужно определить, что же такое "язык".
Для этого служит справочник lang
В нем есть атрибуты
LANG_ID - идентификатор языка - суррогатный ключ
NAME - название языка (English, Russian ....)
ISO_CODE - ISO код языка
LOCALE - PHP локаль для данного языка (чтобы работали стандартные строковые ф-ции)
CHARSET - кодовая таблица языка
Ну и плюс несколько вспомогательных полей (флаг "язык сайта по умолчанию", номер языка в списке, список доменов для определения языка по домену)
Далее каждый тип объектов в базе храниться в 2-х таблицах - языко-независимые и языко-зависимые атрибуты.
Например объект типа "Новость".
Языко-независимые атрибуты
NEWS_ID - идентификатор, суррогатный ключ
DT - дата-время новости
USER_ID - идентификатор "владельца" для записи
Языко-зависимые атрибуты
NEWS_ID + LANG_ID - первичный ключ
TITLE - заголовок
CONTENT - содержание
STATUS - статус новости
Очевидно что для вывода одной новости на одном языке нужно все-навсего сделать простой JOIN.
Очевидно так-же что для добавления нового языка - достаточно добавить одну запись в таблицу lang - ну и соотв. тексты на нужном языке.
Ответ вроде: "потому что это противоречит четвертой нормальной форме" считается отмазкой, так как на практике часто жертвуют правильностью в обмен на скорость.
Можешь считать как угодно - я уже написал - больше дураков, меньше конкуренция. "Скорость" бывает разная. Скорость выполнения запросов у данных методов - неразличима. И в том и в другом можно по дурацки все сделать, если руки растут не оттуда. А вот "скорость" отыскания потом багов и решения новых поставленных задач в моем методе на порядки выше просто потому что данные изначально нормализованы. Представь себе сайт с десятком языков - и сразу будет понятно.
Предлагаю подумать над простой вещью - например статусами новостей в моем примере.
В моей системе каждая "новость" проходит редакционный цикл - "создание, редактирование, опубликование".
Как можно видеть - статус находиться в языко-зависимом блоке, а это значит что каждая языковая версия может жить своей жизнью, например новость на русском опубликовали вчера, а на английский переведут только на след. день - когда переводчик придет на работу.
Теперь представляем себе что у нас 10 языков и 10 переводчиков - в варианте vadim потребуется ввести 2x10 новых полей в таблицы (а это кстати только замедлит выборку, т.к. длина одной строки резко возрастет).
С разнообразными "надписями" я поступаю аналогично - выношу их в базу в отдельные 2 таблицы. GetText использовать не слишком удобно, т.к. владелец сайта нанимает переводчика, не я.
А переводчик тупо переводит все языковые пары. Для вывода используется smarty и простой ресурс-плугин, так что надписи могут содержать подстановки вида "There are {$rows} rows in table".
Как видите использование кодировок осталось за кадром - потому что к собственно многоязычности они отношения не имеют.
UTF-8 удобен безусловно, но в первую очередь тем, что позволяет забыть о "кодировке" как таковой и унифицировать строковые операции независимо от языка.
Тем не менее разделять тексты по языковому признаку придется в любом случае.
Больше объяснять почему нормализация данных это хорошо - не буду. Не видел ни одного примера где бы это реально что-то ускорило, наоборот - только создает проблемы и мешает делать нормальные запросы.
SQL создавался для сложных запросов, не надо работать с SQL-базой как с кучей файлов-таблиц (выбрал из одной, выбрал из другой) - не бойтесь сделать много джойнов, при правильной организации данных все будет просто и быстро.
