Какую архитектуру базы лучше использовать в данном случае?

Question

[Nokse]

Краткое описание:
Есть 1000 товаров. Есть 500 магазинов. Каждый из товаров может продаваться в каждом из магазинов и иметь там цену, а может и не продаваться. Как лучше организовать хранение данных про цены на товары во всех магазинах, чтобы максимально быстро и эффективно можно было построить список для сравнения цен во всех магазинах на все товары в виде таблички
|---------| shop 1 | shop 2 | shop 3 | ... | shop N |
| item 1 | price 1 | price 2 | price 3 | ... | price N |
| item 2 | price 1 | price 2 | price 3 | ... | price N |
| item 3 | price 1 | price 2 | price 3 | ... | price N |
...
| item N | price 1 | price 2 | price 3 | ... | price N |

Я реализовал хранение всех данных в одной таблице в виде (айди товара, айди магазина, цена) с уникальным индексом по паре столбцов (айди товара, айди магазина), но теперь понимаю, что, чтобы построить сводную таблицу для всех товаров по всем магазинам - надо выполнить к базе количество запросов равное количеству товаров, а это совсем не правильно (как мне кажется). Распылять данные на кучу таблиц (по одной таблице на магазин) и потом это все склеивать джойнами - тоже неправильно, как мне кажется.

Посему и возник вопрос - как правильно такое делать?

Заранее спасибо за ответы.

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

Answer 1

[Roman K]

Ты сделал всё правильно, это самая нормальная форма. Не надо бояться JOIN'ов. БД созданы для того, чтобы таблицы джойнили.

Возможно, стоит добавить дату цены. Чтобы всегда была история цен, а не последняя. Но это уже другой вопрос.

Answer 2

[Alex]

3 таблицы
Товары
Магазины
Таблица связи с ценой

для сводной таблицы в MS SQL например есть оператор PIVOT

Comments

[Nokse]

Спасибо, благодаря Вам открыл для себя pivot tables )

Answer 3

[Максим Y]

У вас сейчас подходящая структура для хранения. Если стоит задача находить магазин с минимальной ценой по товару, то ваша структура будет прекрасно справляться.
Но "быстро и эффективно можно было построить список для сравнения цен" - это не то же самое, что городить таблицу на 500 столбцов, которой невозможно пользоваться на практике. Результат для просмотра человеком, как правило, должен быть более агрегирован.

Comments

[Nokse]

Спасибо за ответ. Я тоже уже пришел к выводу, что таблица на 500 столбцов, даже с прокруткой - неудобно, и что надо делать либо разбивку на страницы, либо фильтр для выбора небольшого количества (до 10) магазинов для сравнения. Да и построение сводной таблицы на 10 магазинов и на 500 - разница в скорости и нагрузка на сервер колоссальна.

Answer 4

[Nokse]

Благодаря ответу Alex и гуглению нашел весьма интересную штуку (для Postgres): colpivot
Эта функция вполне решила мою задачу.