Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Подписи к фото на разных языках - как хранить?
 
 автор: Zilog   (04.06.2009 в 00:17)   письмо автору
 
 

Подписи к фото на разных языках - как хранить?
Каждое фото - отдельная запись в БД (ид, путь к файлу, и т.д.)

Вижу пока два пути:
1. Завести отдельное поле TEXT, где хранить языковые записи в виде:
ru=абвгд, en=abcde, bin=010101 и т.д.
т.е. языков - куча, при выводе парсим, и выводим из примерно такого массива:
echo $langstr['en'];

Неудобство данного способа проявляется в админке: разобрали строки, вывели в поле для редактирования и.... нажали кнопку "Сохранить". Дальше - что? Мы имеем на руках одну языковую строку, которую в итоге надо добавить/заменить в уже имеющееся поле. Получаем тупой гемор.


2. Завести отдельную таблицу, где хранить переводы. Недостаток: если выводим 20 картинок, получаем 20 дополнительных запосов к БД. Многовато как то.



Что скажете, ребята? Каким путем идти?

  Ответить  
 
 автор: aexb   (04.06.2009 в 11:38)   письмо автору
 
   для: Zilog   (04.06.2009 в 00:17)
 

Попробуйте хранить все это не в базе, в а XML-файлах - таким образом вы сразу снимаете с себя вопрос по ограничению на количество параметров для одного объекта. Ну, к примеру, вот так может выглядеть XML для картиночного сервиса:
<?xml version="1.0" encoding="windows-1251"?>
<images>
  <item id="1">
    <url>http://www.mysite.ru/images/cabcba.jpg</url>
    <titles>
        <title lang="ru-ru">Красивая картинка</title>
        <title lang="en-us">Beautiful image</title>
        <title lang="de-de">Sch&#246;nes Bild</title>
    </titles>
  </item>
  <item id="2">
    <url>http://www.mysite.ru/images/pictcha.png</url>
    <titles>
        <title lang="ru-ru">Схема портала</title>
        <title lang="nl-nl">Ordningen portal</title>
    </titles>
  </item>
</images>

Естественно, что к одной картинке можно добавить кучу параметров. А разбирать XML можно с помощью XSLT на сервере. И дальше - генерить статику или динамику, дело ваше (хотя лучше статику). Плюс ко всему, XSLT хорошо себя показывает на сайтах с большой нагрузкой. Вот сюда можно сходить за примером многоязычности: http://www.artlebedev.ru/tools/technogrette/xslt/multilang/

  Ответить  
 
 автор: yuk   (04.06.2009 в 12:31)   письмо автору
 
   для: Zilog   (04.06.2009 в 00:17)
 

Еще вариант - для каждого перевода свое поле в таблице фотографий.
Например, поля title_1, title_2, title_3...
При выборе фотографий выбирать нужный title:
Допустим, на странице выбран язык 1, тогда запрос будет типа
SELECT `id`, `path`, `title_$language` AS `title` FROM ...

  Ответить  
 
 автор: Loki   (04.06.2009 в 12:32)   письмо автору
 
   для: yuk   (04.06.2009 в 12:31)
 

а при добавлении нового языка править таблицу? ну-ну...

  Ответить  
 
 автор: yuk   (04.06.2009 в 13:10)   письмо автору
 
   для: Loki   (04.06.2009 в 12:32)
 

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

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

А вобщем согласен, ваш вариант получше будет.

  Ответить  
 
 автор: Loki   (04.06.2009 в 13:36)   письмо автору
 
   для: yuk   (04.06.2009 в 13:10)
 

Для себя при оценке структуры я пользуюсь правилом: если при добавлении данных приходится править структуру, значит структура неверна.

  Ответить  
 
 автор: yuk   (04.06.2009 в 14:13)   письмо автору
 
   для: Loki   (04.06.2009 в 13:36)
 

>Для себя при оценке структуры я пользуюсь правилом: если при добавлении данных приходится править структуру, значит структура неверна.

Или постановка задачи неправильна.

  Ответить  
 
 автор: Loki   (04.06.2009 в 14:26)   письмо автору
 
   для: yuk   (04.06.2009 в 14:13)
 

Если заказчик платит деньги, то постановка задачи уже не важна:)

  Ответить  
 
 автор: Loki   (04.06.2009 в 12:31)   письмо автору
 
   для: Zilog   (04.06.2009 в 00:17)
 

Либо я не понял этот поток сознания, либо у нас слишком разные понятия о программировании.
Я бы просто создал две дополнительные таблицы
image_id, text, lang_id
и
lang_id, lang_title

А про все что Вы понаписали можете смело забыть.

  Ответить  
 
 автор: Zilog   (04.06.2009 в 14:43)   письмо автору
 
   для: Loki   (04.06.2009 в 12:31)
 

>Либо я не понял этот поток сознания, либо у нас слишком разные понятия о программировании.
>Я бы просто создал две дополнительные таблицы
>image_id, text, lang_id

>lang_id, lang_title

Это второй путь, который я предложил - правильно вас понял?
Но что делать тогда с дополнительными запросами к БД, если выодим изображения большими группами? Ведь для каждой фотки надо будет лазить в БД за текстом-переводом. а?

  Ответить  
 
 автор: Loki   (04.06.2009 в 15:22)   письмо автору
 
   для: Zilog   (04.06.2009 в 14:43)
 

>Ведь для каждой фотки надо будет лазить в БД за текстом-переводом. а?
нет. не надо.

  Ответить  
 
 автор: Valick   (05.06.2009 в 01:05)   письмо автору
 
   для: Loki   (04.06.2009 в 15:22)
 

хочу с Вами не согласиться))
В БД придётся лезть за подписью для каждой фотографии... только делать это нужно одним запросом)

  Ответить  
 
 автор: Trianon   (05.06.2009 в 08:45)   письмо автору
 
   для: Valick   (05.06.2009 в 01:05)
 

хочу с Вами не согласиться))

В БД придётся лезть один раз лишь за теми фотографиями, которые нужны, и за подписями к таким фотографиям.

  Ответить  
 
 автор: Valick   (05.06.2009 в 09:05)   письмо автору
 
   для: Trianon   (05.06.2009 в 08:45)
 

Вынужден с Вами согласиться))
Вобщем, мне кажется, нужно опредилиться какой язык будет по умолчанию.
первая таблица:
id_img | name_img
вторая таблица:
id_txt | id_img | lang | text

таким образом можно провести выборку для конкретных фотографий с самообъединением таблицы и для тех фото для которых нет подписи на нужном языке вывести подпись на языке по умолчанию

А я сейчас думаю над другой задачей. Допустим подпись к фото нужно вывести на языке оригинале (для каждого фото разные языки) и подпись перевод на каком-нибудь определённом языке.
Хм... вот и решение в столбец lang ввести язык - original. Структура таблиц та же, просто запрос будет немного другой. А для тех фото для которых не нашлось подписей с переводом на нужный язык обратиться к скрипту

  Ответить  
 
 автор: neadekvat   (07.06.2009 в 17:04)   письмо автору
 
   для: Loki   (04.06.2009 в 12:31)
 

> Либо я не понял этот поток сознания, либо у нас слишком разные понятия о программировании.
> Я бы просто создал две дополнительные таблицы
> image_id, text, lang_id
> и
> lang_id, lang_title

Получается, надо делать и третью таблицу, что-то типа

lang_name и lang_id

иначе все это будет жутко запутано и нечитабельно, имхо

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

  Ответить  
 
 автор: Valick   (07.06.2009 в 19:55)   письмо автору
 
   для: neadekvat   (07.06.2009 в 17:04)
 

зачем третья таблица? я по-моему подробно расписал как всё выглядит с двумя таблицами
сколько угодно картинок и сколько угодно подписей к ним на скольки угодно языках

  Ответить  
 
 автор: neadekvat   (07.06.2009 в 22:25)   письмо автору
 
   для: Valick   (07.06.2009 в 19:55)
 

Такое чувство, будто что-то удалили, а я не прочитал.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования