Проектирование базы данных для редактируемой таблицы

#sql #database-design

#sql #database-design

Вопрос:

Мне нужно разработать приложение, которое будет хранить продукты со значениями по умолчанию в таблице с именем default_products .
Это приложение будет использоваться клиентами (или пользователями), которые должны иметь возможность использовать продукты из default_products таблицы со значением по умолчанию, но они также должны иметь возможность :

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

Одним из решений, которое я мог себе представить, было бы:

  • одна default_products таблица, содержащая все продукты по умолчанию со значениями по умолчанию
  • одна custom_products таблица со всеми продуктами, созданными пользователями, а также копия продукта по умолчанию, который пользователь настроил бы, и логическое поле, is_update которое указывает, является ли это обновлением из записи default_product
  • Функция, которая сначала ищет обновленные записи продукта из custom_product таблицы, затем запрашивает default_products таблицу и возвращает записи из default_product таблицы только обновленные и пользовательские продукты для этого пользователя из custom_product таблицы.

Пример:

 default_product
 - id
 - name
 - price

custom_product
 - default_product.ID
 - custom_price
 

Я хочу, чтобы запрос возвращал: default_product.ID, default_product.name, custom_product.price только если в custom_product есть запись, соответствующая продукту в default_prduct, в противном случае return: default_product.ID, default_product.name, default_product.price .

Есть идеи, если это хорошо? Или у кого-нибудь есть более простой способ сделать?

Комментарии:

1. IMO, user таблица и product таблица с user_id ref user и product_name or product_id , и сохранять значение по умолчанию product всякий раз, когда появляется новая user запись, и обновлять всякий раз, когда пользователь обновляет свой список продуктов.

2. Я не думаю, что есть необходимость разделять default и custom на две таблицы, а также логическое значение для указания статуса обновления.

3. @Thomas Ballandras вы можете использовать JOIN запрос по WHEN CASE мере необходимости

4. Лучше спросить у дочернего сайта, администратора базы данных. StackExchange.com

5. Допустим, цена продукта по умолчанию составляет 19,95. Пользователь выбирает этот продукт и не настраивает цену. Позже цена по умолчанию изменяется на 29,95. Какова цена пользовательского продукта? 19,95 или 29,95? Другими словами, получают ли они копию или псевдоним?

Ответ №1:

То, как вы подходите к этому, зависит от того, есть ли у пользователя копия значения по умолчанию или псевдоним значения по умолчанию. То есть, как только пользователь выбрал продукт, видят ли они обновления названия и цены по умолчанию?


Если это псевдоним, у вас может быть таблица products для хранения продуктов и таблица user_products для хранения выбранных пользователем продуктов и любых настроек.

 products:
  id
  name not null
  price not null

user_products:
  id
  user_id not null
  product_id
  name
  price
 

user_products.name и user_products.price могут иметь значение null. Если null, они будут использовать значение из products . Вы делаете это с помощью coalesce which будет выбрано первое ненулевое значение.

Если пользователь хочет добавить свой собственный продукт, user_products.product_id имеет значение null. Выполните a left join , чтобы обеспечить результат.

 select
  coalesce(up.name, p.name) as name,
  coalesce(up.price, p.price) as price
from user_products up
left join products p on p.id = up.product_id
where user_id = ?
 

Недостатком является то, что две таблицы должны поддерживаться синхронно, и для объединения каждого поля должны быть написаны запросы. Это может быть примером использования наследования таблиц, если ваша база данных поддерживает его.


Если это копия, создайте единственную таблицу со столбцом user_id, который может быть нулевым.

 products:
  id
  user_id
  name not null
  price not null
 

Когда products.user_id значение равно null, это значения по умолчанию, доступные любому.

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

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

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