@gamer25
Студент 3 курса ЯрГУ факультета ИВТ

Как правильно организовать структуру БД для прайс-листов?

Здравствуйте! Дали задание в университете по базам данных.
fb82292d69254d2fb56af50236d14bb7.jpg9d3c38d7f99941118bf5f1d0b7848767.jpg
Интересует именно организация структуры БД.
Пока предполагаю 2 варианта:
Делаем отдельные таблицы для комплектующих ПК и там храним только характеристики.
  1. Делаем одну таблицу прайс-листа с полями: id магазина, id комплетующего ПК, цена (но возникает проблема, что поле id комплектующего не сделать foreign key, ведь выбор сторонней таблицы зависит от типа комплектующего (видеокарта/цп и т.д.))
  2. Делаем на каждую таблицы комплектующих свою таблицу прайс-листа (т.е. отдельный прайс-лист видеокарт, цп и т.д.) с полями: id магазина, id комплетующего ПК, цена. (Здесь уже не будет проблемы с foreign key, но получится много таблиц)
Вопрос: как правильно сделать? Может быть вообще не перечисленными способами. Спасибо.

8d57bd351d4b4c59b57318145688cb08.png
----
Прикрепляю фото задания и текущую диаграмму БД.
  • Вопрос задан
  • 794 просмотра
Пригласить эксперта
Ответы на вопрос 2
sim3x
@sim3x
Привыкай что в ИРЛ нет правильного - есть такие, что решают задачу, и те что плодят костыли

Твой ближе ко второму

Фирма:
- название

Товар:
- название
- тип (сдром, цпу, рам, ...) можно сделать статическим списком, можно сделать ФК на отдельную таблицу
- .... другие общие для всех характеристики

ТоварЦена:
- фирма = ФК(Фирма)
- цена

Характеристики индивидуальные для каждого товара делаем по https://en.wikipedia.org/wiki/Entity%E2%80%93attri...
Ответ написан
Комментировать
@vjjvr
Самая большая проблема - сопоставление товара.
В разных фирмах используются разные названия.

Сопоставить может только человек.

Как будут забиваться данные?

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

Если будут забиваться вручную, то все проще - сразу можно забить однообразно.

Для таких вещей я бы не стал использовать таблицы - "видеокарты", "память" и т.д.
Будет сложно расширять.

Я бы в schemaless СУБД сделал бы. Например, в MongoDB.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы