Каковы плюсы и минусы следующего дизайна базы данных?

Question

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

-- product
create table Product(
productID int not null identity(1,1),
name varchar(100) not null,

constraint PK_Product primary key(productID)
)

-- client
create table Client(
clientID int not null identity(1,1),
name varchar(100) not null,

constraint PK_Client primary key(clientID)
)

-- order
create table [Order](
orderID int not null identity(1,1),
clientID int not null,
orderDateTime datetime not null,
orderAmount money not null,
orderNote varchar(max) null,

constraint PK_Order primary key(orderID),
constraint FK_Order_Client foreign key(clientID) references Client(clientID)
)

exec sp_tableoption 'Order', 'large value types out of row', 0

create index IX_Order_client on [Order](clientID)

-- items
create table OrderItem(
orderItemID int not null identity(1,1),
orderID int not null,
productID int not null,
qty int not null,
amount money not null,

constraint PK_OrderItem primary key(orderItemID),
constraint FK_OrderItem_Order foreign key(orderID) references [Order](orderID),
constraint FK_OrderItem_Product foreign key(productID) references Product(productID)
)

create index IX_OrderItem on OrderItem(orderID)

Answer 1

это выглядит довольно хорошо.

Вам также может потребоваться корректирующая сумма для любых скидок или дополнений к общей стоимости заказа. Не очень понятно, как вы собираетесь обрабатывать отображаемую вами сумму заказа - обычно общая сумма заказа может быть рассчитана из суммы включенных частей.

также, если применимо, рассмотрите способ доставки для указания того, как будет доставлен заказ, и, возможно, статус, если заказ выполняется за несколько шагов.

Answer 2

1) Для таблицы OrderItem, я думаю, лучше хранить цену за единицу и добавить рассчитанное поле для суммы: Amount AS Qty*UnitPrice [PERSISTED]. Кроме того, важен тип данных для полей UnitPrice & Amount. Вы уверены, что вам нужно 4 знака после запятой? Не лучше ли использовать только 2 десятичных знака (например, NUMERIC (8,2))?

2) На данный момент, используя предложенный дизайн, можно легко «продублировать» позиции заказа (идентификатор заказа и идентификатор продукта), потому что таблица OrderItem не имеет никаких ограничений:

Order (1001, ...)
OrderItem (1,1001,10,400,800),(2,1001,11,200,1200),(3,1001,10,400,800).

Решение состоит в том, чтобы добавить уникальный индекс:

CREATE UNIQUE INDEX IUX_OrderItem_OrderID_ProductID 
ON OrderItem (OrderID, ProductID)

В некоторых случаях OrderID + ProductID может дублироваться, но UnitPrice будет другим. Если это ваш случай, то уникальный индекс будет иметь ключ с 3 полями: СОЗДАТЬ УНИКАЛЬНЫЙ ИНДЕКС IUX_OrderItem_OrderID_ProductID_UnitPrice ON OrderItem (OrderID, ProductID, UnitPrice)

3) Если версия SQL Server> = 2005, то вы можете использовать схемы для объектов базы данных.

CREATE SCHEMA Sales;
CREATE TABLE Sales.[Order] (...);
CREATE TABLE Sales.OrderItem (...);

4) Мой совет - не создавать индексы (IX_OrderItem) без причины: например, запрос или ограничение. Они должны обновляться при каждой операции DML, и им нужно место для хранения. Если вы хотите создать индексы, попробуйте создать уникальные индексы, если это возможно.

5) Я не понимаю причину использования типа данных VARCHAR (MAX) для поля orderNote из таблицы Order. VARCHAR (8000) или NVARCHAR (4000) не достаточно? Вы хотите вставить роман в это поле для каждого заказа?