LSVА если не устроит, то как без FOREIGN KEY будем обеспечивать выполнение этого бизнес-требования? Просто напишите логику, где всегда будет шапка у строки заказа. Только и всего.
Давай на примере. Например, есть такая структура данных (T-SQL):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE TABLE Orders
(
OrderId INT IDENTITY (1, 1) NOT NULL,
....
CONSTRAINT Orders_PK PRIMARY KEY(OrderId)
)
CREATE TABLE OrderDetails
(
OrderDetailId INT IDENTITY (1, 1) NOT NULL,
OrderId INT NOT NULL,
....
CONSTRAINT OrderDetails_PK PRIMARY KEY (OrderDetailId)
)
По-моему, между этими таблицами должна быть связь внешним ключом между столбцами: Orders.OrderId -> OrderDetails.OrderId.
Но мы внешние ключи решили не использовать.
Что должно быть в слое бизнес-логики для того, чтобы запрос на вставку строки в OrderDetails не привел к нарушению ссылочной целостности?
Я правильно понимаю, что вместо этого:
1.
INSERT INTO OrderDetails (OrderId, ...) VALUES (123, ...)
надо сделать что-то вроде этого:
1.
2.
3.
4.
IF NOT EXISTS (SELECT 1 FROM Orders WHERE OrderId = 123)
RAISERROR('Нельзя нарушать ссылочную целостность', 16, 1)
ELSE
INSERT INTO OrderDetails (OrderId, ...) VALUES (123, ...)
?
Ну, само собой, это все надо выполнить с нужным уровнем изоляции и наложением блокировки на выбранную в Order строку, чтобы между SELECT-ом и INSERT-ом другой пользователь эту строку не стер.
Если я понял правильно, то ИМХО быстрее отработает с внешним ключом...
LSVА при различных ручных манипуляциях с данными часто приходится кратковременно и осознанно нарушать некую логику.
Изредка возможна ситуация, что сначала вставляются строки, а затем шапка.
А можно пример такой ситуации? Для меня это как-то диковато...
LSVИли импорт из сырого источника, где логика уже изначально нарушена.
Ну в этом случае данные, которые надо загрузить в базу, просто некорректны с точки зрения модели данных бизнес-логики.
Я таких случаях в той же базе делаю отдельные таблицы для первоначальной (черновой) загрузки таких данных (может быть, не нормализованные и, да, может быть, без внешних ключей). Этакая маленькая свалка данных в базе данных. Но потом пользователю через интерфейс программы все равно приходится наводить порядок и перегонять эти данные в основные таблицы базы, в которых уже есть внешние ключи.
Все-таки просто загрузить данные в базу - мало. Главное как их потом можно будет использовать: строить отчеты или производить расчеты. А люди, которые пишут аналитические запросы, в праве рассчитывать на то, что данные в базе корректны. И "потерянных" строк в Detail-таблицах не будет. Я не прав?
LSVНарушение логики ФК всегда можно обнаружить и правильно отреагировать (н-р заново создать шапку или удалить/переместить осиротелые строки)
Как ты создашь заново строку в таблице Orders??? Откуда ты возьмешь ее реквизиты (номер, дату, КлиентId и пр.)? Заставишь пользователя заносить с бумаги?
