Как мне разработать базу данных ER-Diagram для этой проблемы

Question

У меня есть какой-то конкретный вопрос, но я не могу думать.

У меня есть 5-6 заявлений, которые мне нужно сохранить в моей базе данных. Эта система похожа на новостную ленту.

1. Заявление 1: A установил этот веб-сайт.
2. Оператор 2: A добавлено хранилище R в провинция X
3. Заявление 3: B проверено магазин R
4. Заявление 4: A отредактировано Хранить R
5. Заявление 5: A добавлено product P in product_category1
6. Заявление 6: B Отзыв Продукт P

Обратите внимание, что жирным шрифтом являются динамические данные, такие как A, B - это имя какого-то пресона, store R - это имя store'а, которое добавляет этот человек.

По-моему, у меня есть

• person_table (id, имя, возраст, ...)
• store_table (sid, store_name, провинция_id, ...)
• product_table (pid, product_name, ...)

а как насчет feed_table ??

Как я проектирую базу данных для хранения этих данных. и Как я запрашиваю эти данные для просмотра.

спасибо

Answer 1

Существует два подхода к решению этой проблемы:

1. Вы разрабатываете свои таблицы таким образом, что у вас нет повторения информации.По сути, интересующая вас лента может быть построена из существующих таблиц качественным способом;или

2. Вы повторяете определенные данные, чтобы упростить реализацию вашего канала.

Лично я бы, наверное, выбрал (2) и получил бы новыйтаблица:

• Фид: id, person_id, store_id, action_id, Province_id, product_category_id

, причем последние два поля являются необязательными, в зависимости от действия (просмотр, редактирование,добавить и т. д.).

Пуристы будут утверждать, что повторяющиеся данные плохие (конечно, нормальная форма стремится их вычленить), но в реальных схемах базы данных делают это все время из соображений производительности.

Подумайте об этом так: на что вы тратите большую часть своего времени в своем приложении?

1. Просмотр канала (чтение);или
2. Выполнение действий (запись).

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