Что правильнее и быстрее: дублировать одинаковые столбцы в нескольких родственных таблицах или использовать JOINы?

Question

[Максим Ходырев]

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

Что правильнее и быстрее в таком случае?

1. Создать таблицу-родитель(c общими полями) и связать с ней таблицы параметров каждой конкретной услуги
2. Запихать все в одну таблицу и использовать VIEW для каждого конкретного типа услуг
3. Создать разные таблицы для всех типов услуг и дублировать общие поля

Answer 1

[Павел Соловьёв]

1 вариант

Comments

[Максим Ходырев]

Спасибо за ответ, можете аргументировать его подробнее?

[Илья Лесных]

@maximkou нормализация БД - вот аргументация.

[Павел Соловьёв]

3 вариант, нарушает правила нормализации, 2 слишком запутанный, 1 вариант самый оптимальный не сильно нарушает нормализацию БД, и прост в реализации + достаточно легко будет искать данные.

[Максим Ходырев]

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

[Павел Соловьёв]

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

[Максим Ходырев]

@pavel_salauyou, Данные сейчас кешируются в memcached, нереляционную базу не хочется использовать, т.к. нужны полноценные транзакции. Буду экспериментировать. Еще раз спасибо за отклик.

Answer 2

[Виталий Желтяков]

Правильнее - 1 вариант, быстрее - 2.

Comments

[Максим Ходырев]

С правильностью соглашусь, с быстротой 2 варианта не уверен. Что бы выбрали для себя вы из этих 2 вариантов?

[Виталий Желтяков]

@maximkou 2 вариант будет быстрее, т.к. все действия с услугами будут сводиться к одному простому запросу без Join-ов.
Какой вариант - зависит от контекста. Если специфических опций не много, то 2-ой. Если опций предполагается много, то 1-ый.

[Максим Ходырев]

Неясно, сколько будет этих самых опций. Решил все же остановиться на 1 варианте. Спасибо за пояснение.

Answer 3

[tovogukA]

С JOIN - формально правильнее для любой RDBMS. Производительности, как правило, хватает.
Но в некоторых РЕДКИХ случаях может вызвать проблемы производительности.

Вариант с одной таблицей (с дублями) - в таких РЕДКИХ случаях помогает решить проблему с производительностью. Но возможны косяки - из-за несинхронизирования дублирующей информации.

Но, как правило, проблема с производительностью лежит в другой плоскости.

Дублировать, на практике, приходится по другой причине, - ВОВСЕ не из-за производительности.

Например, интернет магазин:

Цены - могут поменяться.
Но в таблицу с заказанными уже товарами должно уехать (дублироваться) все по старому, то есть так цена, что была в момент оформления заказа покупателем. А вовсе не ссылка на таблицу с текущими ценами.