Проблемы при разработке базы данных для управления всеми видами продуктов, таких как Amazon - PullRequest
0 голосов
/ 28 ноября 2010

Прежде всего, извините за мой плохой английский хехехе. Мне нужна помощь, я хочу создать базу данных для веб-сайта, например, мини-Amazon.Эта база данных будет управлять всеми видами продуктов (телевизоры, автомобили, компьютеры, книги, видеоигры, карандаши, столы, штаны ...), но также каждый продукт должен иметь некоторые свойства (которые будут проиндексированы), например, если продукткнига, свойства будут что-то вроде жанра, года, автора.Если продукт - телевизор, свойства будут примерно такими же, как размер, цвет, а также год.А если продукт - автомобиль, то его свойства будут, например, год, цвет, модель.Итак, это моя идея:

  1. Одна таблица для управления отделами (например, электроника, книги ...)
  2. Одна таблица для управления категориями отделов, эта таблица будетдитя предыдущего.Если в отделе электроники, то здесь будут аудио, ТВ и видео, игры ... (каждая категория принадлежит одному отделу, отношения - это один отдел ко многим категориям)
  3. Одна таблица для управления продуктами (каждаятовар относится к одной категории, отношение - одна категория ко многим товарам)
  4. Одна таблица для управления свойствами (например, год, цвет, жанр, модель ...)
  5. Одна таблица для привлечения товаровсо свойствами эта таблица будет называться ProductProperties

Я не уверен, что это лучший способ, база данных будет огромной, я разработаю базу данных на MySQL.Но я думаю, что это не лучший способ, в этой статье говорится о «Абстракции базы данных: агрегация и обобщение»другими словами, общие объекты (я думаю), но этот способ устарел (70-е годы).В этой статье http://www.simple -talk.com / sql / database-Administration / ten-common-database-design-errors / в разделе «Одна таблица для хранения всех значений домена» говорится, что этоНеправильный путь ... Я говорю все это из-за таблицы ProductProperties, я не знаю, делаю ли я эту таблицу или я делаю специальные таблицы для каждого вида продуктов.

Есть ли у вас какие-либо предложения?Или у вас есть идея получше?

Заранее спасибо, позаботьтесь !!!

Ответы [ 3 ]

2 голосов
/ 28 ноября 2010

1. Один стол для управления отделами (например, электроника, книги ...) 2. Одна таблица для управления категориями отделов, эта таблица будет дитя предыдущего. Если отдел электроники, здесь будет быть аудио, ТВ и видео, игры ... (каждый категория принадлежит одному отделу, отношения являются одним отделом много категорий)

Почему? Одна таблица, категории, образующие иерархию. Более гибкий.

3. Одна таблица для управления продуктами (каждый продукт относится к одной категории, отношения это одна категория много продуктов)

Почему? Разрешите m: n здесь. Продукт во многих категориях.

Я не уверен, что это лучший способ, база данных будет огромной

Ах - нет. Сожалею. Нетривиально, да. Хью? Нет. Просто чтобы дать вам представление о Хью - у меня есть база данных, я добавляю 1,2 миллиарда строк в день к конкретной таблице. В среднем. Это большое. Вы в конечном итоге с чем - 100.000 предметов? даже не стоит упоминать.

1 голос
/ 28 ноября 2010

Pablo89, описание того, что вы хотите, очень близко к тому, что делает база данных AdventureWorks для SQL Server. Существует множество примеров использования AdventureWorks в Интернете, от веб-приложений до отчетов в BI.

Загрузите и установите SQL Server Express 2008 R2. Загрузите и установите образец базы данных для вышеуказанного продукта. Проверьте дизайн базы данных для AdventureWorks.

Используйте AdventureWorks в качестве примеров вопросов, которые вы можете опубликовать.

Я использую AdventureWorks, потому что я использую SQL Server. Я не говорю, что это лучше, чем другие продукты баз данных, я говорю это потому, что знаю AdventureWorks.

0 голосов
/ 31 марта 2017

Я не думаю, что какая-то база данных может работать быстро с 500 000 000 элементов.Полное дерево категорий товаров для amazon.com содержит 51 000 узлов ( amazoncategories.info ).Также данные обновляются ежечасно, поэтому сохраненная информация о продукте может быть неверной.Я думаю, что оптимальный способ - хранить в дереве категорий только данные о продукте во время выполнения с помощью API Amazon.

...