Дизайн стола для нескольких разных продуктов на одном заказе

Если бы у меня был сайт онлайн-магазинов, в котором продавались яблоки и мониторы, и они хранились в разных таблицах, потому что отличительное свойство яблок цветное, а качество мониторов - это разрешение, как бы я добавьте эти данные в таблицу счетов, сохраняя при этом ссылочную целостность и не объединяя эти таблицы?Дизайн стола для нескольких разных продуктов на одном заказе

     Invoices(InvoiceId) 
           | 
        InvoiceItems(ItemId, ProductId) 
           | 
         Products(ProductId) 
       |           | 
Apples(AppleId, ProductId, Colour) Monitors(MonitorId, ProductId, Resolution)

источник

2010-10-07 Rob

Во-первых, я бы сохранил их в одной таблице Products, а не в двух разных таблицах.

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

Предлагаю вам ознакомиться с Database Normalisation.

источник

2010-10-07 15:17:20

Если я сохранил их в одной таблице комбинированных продуктов, не означает ли это наличие нулевых столбцов разрешения и цвета, которые будут заполняться только в зависимости от того, является ли этот конкретный продукт монитором или Apple? Нормализация предполагает наличие только столбцов в таблице, если они напрямую связаны с Первичным ключом. Что касается таблицы ссылок, хорошая точка. Я слишком упростил вопрос и пропустил эту деталь. Я уточню вопрос. – Rob

Счета-фактуры (InvoiceId) | InvoiceItems (ItemId, ProductId) | Продукты (ProductId) | | Яблоки (AppleId, ProductId, Color) Мониторы (MonitorId, ProductId, Resolution) – Rob

Таблица счетов имеет идентификатор продукта FK, а ProductID может быть либо AppleID (цвет PK), либо MonitorID (разрешение ПК)?

Если это так, вы можете ввести ProductTypeID со значениями, такими как 0 = apple, 1 = monitor или isProductTypeApple boolean, если только когда-либо будет 2 типа продукта, и включите это в таблицу ProductID PK.

Вам также необходимо указать поле ProductTypeID в таблице Apple и таблице монитора PK.

источник

2010-10-07 15:18:14 Beth

Мне нравятся таблички с именами для них ... Возможно, было бы проще переделать так, что это будет «Продукт», а затем «Сведения о продукте» ... в описании продукта содержится идентификатор продукта, тип детали, а затем значение , Это позволит вам держать яблоки и мониторы в одной и той же таблице независимо от атрибута идентификации (и оставить его открытым для добавления другого продукта позже).

Символьный подход может быть использован в таблице счетов ... есть столбец «product_type», который сообщает вам, какую таблицу нужно искать (яблоко или монитор), а затем «product_id», которая ссылается на любой столбец идентификатора в яблоке/мониторный стол. Запрос на такую настройку немного сложнее и может заставить вас использовать динамический sql ... Я бы взял этот маршрут только в том случае, если у вас нет контроля над выполнением редизайна выше (и другие ответы, размещенные здесь, см.)

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

источник

2010-10-07 15:26:01 Twelfth

Не имели бы таблицы значений имен только значения String (varchar)? Что делать, если некоторые из атрибутов были числовыми или значениями даты, которые должны быть сопоставимы/безопасны по типу? Очевидно, что запросы/пользовательские интерфейсы здесь сложны, но главная трудность, с которой я сталкиваюсь, в первую очередь, является структурой БД. Я подумал, что, возможно, я мог бы сделать 4 разных таблиц значения имени, каждый из которых содержит другой тип (int, float, datetime, varchar), но это создало новую проблему, зная, как ссылаться на правильную таблицу значений имен! – Rob

Да, вы правы с этим ограничением ... varchar или nvarchar - это ваши единственные типы данных, которые могли бы обрабатывать практически любые типы данных, которые были добавлены в него. Возможно, что столбец «тип данных» будет иметь значение, хотя он заставит вас перейти на более динамический sql позже, чтобы преобразовывать их в разные типы данных. Любая причина, по которой вы не можете сохранить его как varchar и преобразовать в любой тип данных, который вам нужен, когда ссылаетесь на него в ваших запросах? – Twelfth

Вопрос для вашей модели данных. Вам нужна ссылочная схема, которую вы будете использовать для идентификации продуктов? Может быть SKU?

Затем идентифицируйте каждое яблоко как продукт, назначив SKU. Аналогично для мониторов. Затем используйте SKU в элементе счета. Что-то вроде этого:

продукт {sku} ключ {sku};

invoice_item {invoice_id, sku} key {invoice_id, sku};

apple {color, sku} ключ {color} key {sku};

монитор {размер, sku} ключ {размер} ключ {sku};

с соответствующими ограничениями ... в частности, объединение apple {sku} и монитора {sku} == product {sku}.

источник

2010-10-07 15:29:48 hash1baby

Дизайн стола для нескольких разных продуктов на одном заказе

ответ

Смежные вопросы