- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Есть база продуктов со следующими таблицами:
[ATTACH]138892[/ATTACH]
Название продуктов нужно дополнить локализацией, а базу вообщем нужно расширять, но при этом, не терять возможности обновлять из отдельных источников, таких, как USDA.
В связи со вторым требованием, я решил хранить в рабочей базе все предоставляемые колонки, в том числе, PRIMARY_KEY, который является уникальным для базы источника USDA.
В связи с нуждой в расширении базы, уникальный для USDA PRIMARY KEY не может быть PRIMARY KEY в рабочей базе, поэтому, каждому продукту из другого источника (либо каждому продукту вообще) должен быть присвоен внутренний ID.
Учитывая требования, как вы посоветуете хранить локализацию и расширения к USDA? Просто дополнять существующие таблицы колонками или отдельная таблица для локализации FK `name_local`_`name` и отдельная таблица для продуктов из других источников, которые могут иметь немного другую разметку?
Есть еще вариант: хранить универсальные данные с внутренним PRIMARY KEY + в отдельных таблиц хранить специфические для конкретного источника колонки с FK на универсальную таблицу?
По локализации. Я бы все поля, для которых необходима локализация вынес в отдельную таблицу: ID_Товара (уникальный, вне зависимости от источника), ID_языка, Поле1, Поле2, Поле3 и т.д.
С локализацией просто такое дело, что может понадобится, например, при отсутствии русского перевода выдавать английский. Дергать таблицы с кучей лишних данных (которые еще и без надобности дублироваться будут) в таком случае будет накладно по производительности.
Про то чтобы локализировать дополнительными полями в таблице вообще речи не должно идти - хреново масштабируется. Завтра понадобится новый язык и надо лезть колупать бекэнд (возможно, в 10 разных местах) для поддержки нового поля. Лучше уж один раз человеческую поддержку сделать и потом просто в админке добавлять новые языки.
По специфическим данным для разных источников. Тут надо знать насколько много источников и как сильно они отличаются + необходимость делать выборки по ним. Если там до десятка INT/DOUBLE полей - можно и в одну таблицу свалить, а если куча TEXT/BLOB - надо их разносить по разным таблицам обязательно.
Опять же советую смотреть на универсальность, чтобы меньше гемороя было при возможном добавлении нового источника. Например, если разница между ними гарантировано будет в нескольких мелких полях, и по этим полям не надо делать выборки (только выводить), то можно их даже в JSON запихнуть.
Добавлю о более-менее универсальном хранении дополнительных атрибутов. В таком случае их придется вынимать отдельным запросом, но гибкость хорошая + можно сверху накрутить разбитие по группам.
Нужно минимум две дополнительные таблицы:
1. attributes: attribute_id, language_id, name
2. product_attributes: product_id, attribute_id, language_id (если надо переводить значения атрибутов), value