Интересно, будет ли это выполнимо? Вставка массива в одно поле в базе данных.
Например, у меня есть заголовок, я хочу иметь этот заголовок только с одним идентификатором, но он будет использоваться на веб-сайте.
Чувствовать себя немного ненужным, чтобы еще одна таблица имела свои глобальные идентификаторы, а затем другую таблицу с фактическими заголовками, связанными с таблицей с глобальным идентификатором.
Я просто хочу иметь что-то вроде этого
ID TITLE 1 Array("english title", "nederlandse titel"); Я использую PHP / MSYQL, поэтому, если бы это было выполнимо, можете ли вы объяснить это на этих языках.
О да, я подумал, что могу отформатировать фанки и использовать функцию split, чтобы снова включить ее в массив. Но я задаюсь вопросом, могу ли я просто сохранить его как массив сразу, в случае, если пользователь может ввести что-то с тем же форматированием (один из миллиона)
это выполнимо:
$title = serialize($array);
а затем для декодирования:
$title = unserialize($mysql_data);
но, как уже упоминалось, это действительно снижает преимущества базы данных в первую очередь. я определенно предложил бы рассмотреть вариант с несколькими столами или несколькими столбцами, в зависимости от количества языков, которые вы хотите поддержать, и если это число изменится в будущем.
edit: хороший момент, упомянутый dcousineau (см. комментарии)
Иногда сериализованный вывод, даже после экранирования, бросает символы в запрос, который закручивает вещи вверх. Возможно, вы захотите обернуть свои вызовы serialize () в base64_encode (), а затем использовать base64_decode (), прежде чем вы несериализуете.
скорректированный код для таких ситуаций:
$title = base64_encode(serialize($array) ); $title = unserialize(base64_decode($mysql_data) );
Здесь есть только два разумных варианта:
Присоединиться к другой таблице
профи: неограниченные названия на неограниченных языках
минус: накладные расходы на подключение являются более дорогостоящими вычислительными, SQL немного сложнее для обновления / вставки и т. д.
Несколько столбцов
например: TITLE_EN, TITLE_NL, TITLE_DE
профи: быстрый ввод, выбор и т. д.
минусы: ограниченное количество языков, добавление больше – ALTER TABLE
Учитывая наши два выбора, вы обычно должны выбрать первый. Если вы не имеете дело с просто неприличным количеством транзакций, которые нельзя распараллелить, или вы, абсома, можете гарантировать, что вы никогда не добавите языки, дополнительная гибкость в компоновке схемы сэкономит вам головные боли в долгосрочной перспективе.
Массивы нарушают нормализацию; в моем опыте с базами данных интернационализации я обнаружил, что нормализация фраз – лучший дизайн,
Я позволяю вам легко создавать оптовые копии строк – например, «es» – «es-mx» или «en» – «en-US», «en-GB» и мой любимый: «xx-piglatin». В схеме массива вам придется либо перезаписать каждую запись, либо добавить сложный парсинг, либо использовать нечто более сложное, чем массивы, например XML.
Сравнительно просто использовать LEFT JOIN s для поиска нетранслируемых фраз для работы, а также использовать COALESCE для возврата по умолчанию, чтобы программа оставалась пригодной для использования, даже если фраза не переводится.
Используйте таблицу с тремя столбцами!
ID, TITLE_EN, TITLE_NL
Нет никакой веской причины сериализовать это, ДЕЙСТВИТЕЛЬНО!