Многоязычный социальный веб-сайт - базой данных?

Question

Для хранения многоязычного контента существует много контента, должен ли он храниться в базе данных или файле?И каков основной подход к этому: у нас есть содержимое страницы, справочные таблицы, строки заголовка страницы, метаданные и т. Д. Итак, будут ли в каждой таблице дополнительные столбцы для каждого языка?Так что, если будет 50 языков (число будет расти, поскольку это общедоступный социальный сайт, поэтому конечная цель состоит в том, чтобы иметь как можно больше языков), тогда 50 дополнительных столбцов на таблицу?Или есть лучший способ?

Существует смесь динамического системного и пользовательского контента + статического контента.

Важны масштабируемость и производительность.Разрабатывается на PHP и MySQL.

Пользователь сможет менять язык на любой странице из нижнего колонтитула.Язык может быть основан на сеансе или предпочтениях.Не знаете, какой маршрут лучше?

Answer 1

Если у вас есть переменная, по сути неизвестное сегодня число языков, то это определенно НЕ должно быть несколькими столбцами в записи.По сути, ключ поиска в этой таблице должен быть чем-то вроде идентификатора сообщения плюс идентификатор языка или, возможно, идентификатора экрана плюс идентификатор сообщения плюс идентификатор языка.Тогда у вас есть отдельная запись для каждого языка для каждого сообщения.

Если вы попытаетесь объединить все языки в одну запись, ваше обслуживание станет кошмаром.Каждый раз, когда вы добавляете другой язык в приложение, вам придется проходить через каждую программу, чтобы добавить «else if language == 'Tagalog' затем text = column62" или что-то еще.Сделайте его частью ключа поиска, и тогда вы просто читаете «где messageId =« Foobar »и language = current_language», и вы передаете текущий язык.Если у вас новый язык, ничего менять не нужно, кроме добавления нового языка в список допустимых языковых кодов.

Answer 2

Так что на самом деле вопрос:

бла-бла-бла. Должен ли я хранить свои данные в виде простых файлов или базы данных?

Короткий ответ в зависимости от того, с кем вам легче работать. В зависимости от того, как вы его структурируете, подход на основе файлов может быть быстрее, чем подход на основе базы данных. OTOH, поймите неправильно и влияние на производительность будет огромным. Подход с использованием базы данных обеспечивает более согласованную структуру с самого начала. Так что, если вы сделаете это по ходу дела, то подход к базе данных, вероятно, окупится в долгосрочной перспективе.

конечная цель состоит в том, чтобы иметь как можно больше языков) затем 50 дополнительных столбцов на таблицу?

Нет.

Если вам нужно менять схему базы данных (или структуру файла) каждый раз, когда вы добавляете новый язык (или новый контент), тогда ваша схема неверна. Если вы не понимаете, как правильно моделировать данные, я настоятельно рекомендую использовать подход к базе данных по указанным причинам.

Вы также должны научиться нормализовать свои данные - даже если в конечном итоге вы решите использовать нереляционную базу данных для хранения данных.

Answer 3

Нет причин, по которым вам нужно придерживаться одного источника данных для всего «контента». Существует динамический контент, который будет регулярно добавляться или обновляться, а затем есть относительно статический контент, который редко изменяется. Кроме того, существует периферийный контент, такой как системные сообщения и текст меню, и основной контент - то, что пользователи на самом деле здесь, чтобы увидеть. Вам редко придется искать или индексировать периферийное содержимое, в то время как вы, вероятно, хотите иметь возможность выполнять запросы к основному содержимому.

В большинстве случаев динамический контент и первичный контент должны помещаться в базу данных. Статический периферийный контент может быть размещен в базе данных или нет. Нет смысла помещать его в базу данных, если сайт обслуживается профессиональным веб-разработчиком, который, вероятно, сочтет более удобным просто редактировать файл .pot или .po непосредственно с помощью инструментов командной строки.

Поиск SO по тегам i18n и l10n для получения дополнительной информации о реализации интернационализации / локализации. Что касается разработки схемы базы данных, то этот вопрос заслуживает отдельного вопроса. Я хотел бы найти вопросы по нормализации, как это предложено symcbean, а также поискать учебники по проектированию баз данных.

Answer 4

Определенно начните с четко определенной модели, чтобы вашему дизайну было все равно, поступают ли данные из файла, базы данных или даже из memCache или чего-то в этом роде.Вероятно, лучше всего сделать один вызов на страницу, чтобы получить объект, который содержит все поля для этой одной страницы, а не несколько вызовов.Вы можете просто ссылаться на этот единственный возвращаемый объект, чтобы получить каждое локализованное поле.За кулисами вы могли бы затем кодировать доступ к хранилищу и тестировать.Лично я бы, вероятно, применил подход БД к файлу - вам не нужно беспокоиться о параллельном доступе к файлу, и, вероятно, легче внедрить изменения - опять же, вам не нужно беспокоиться о файлах, заблокированных чтением, когда выразвертывание новых файлов - просто обновление базы данных.

См. эту ссылку о php ioc , которая может вам помочь, поскольку это позволит вам абстрагироваться от кода, какой тип хранилища используется для храненияданные.Таким образом, если вы выберете один подход, а потом захотите изменить его - вам не нужно будет так много переделывать.

Answer 5

Вы можете найти это полезным:

• PHP UTF-8 шпаргалка

В статье описывается, как спроектировать базу данных для многоязычного веб-сайта и использовать функции php.