Написать триггер для учета количества книг

@kurtx · Регистрация: 14.07.2015

Студворк — интернет-сервис помощи студентам

Здравствуйте, прошу помощи с задачкой
Есть таблица с базой книг, с полями: Название и количество на складе,
и есть вторая таблица Продаж, задача состоит в том, что когда мы заполняем таблицу продаж, вводим ID книги, то с первой таблицы(склад) в поле - кол-во должно вычесть единицу, .т.е на складе было 3 книги Анна Каренина, мы одну купили, стало 2...и если на складе нету подходящей книги, то данные в таблицу Sale не заносятся

T-SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
create table Books(
ID int IDENTITY(0,1) PRIMARY KEY,
Name nvarchar(100) NOT NULL,
nCount int NOT NULL,
 
CONSTRAINT check_nCount CHECK (nCount >= 0))
 
 
INSERT into Books(Name, nCount) values
('Отцы и дети', 3),
('Война и мир', 2),
('Анна Каренина', 4)
 
create table Sale(
ID int IDENTITY(0,1) PRIMARY KEY,
idBook int NOT NULL,
 
CONSTRAINT FK_idBook FOREIGN KEY (idBook) REFERENCES Books (ID))

@Hikari · 19.02.2016, 14:26

Сообщение от kurtx

в поле - кол-во должно вычесть единицу

Я не рекомендую тебе вести живые остатки в базе.
Остатки - это вычисляемая величина по периодам и списку приходно расходных ордеров. Их не рекомендуется хранить в базе. Рекомендуется запросом подбивать агрегатными функциями остаток товара проходя по списку накладных.

@kurtx · 19.02.2016, 14:29 **[ТС]**

Hikari, я только начинаю изучать t-sql, нужно выполнить описанную выше задачку, если есть другой способ это сделать, покажите пожалуйста наглядно
за совет спасибо

@Hikari · 19.02.2016, 16:12

Если это ради изучения, то не очень удачный пример... Я не подскажу тебе как бы делала это триггерами, я скажу как бы делала хитрая блондиночка:

SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE PROCEDURE Купить
@Книга NCHAR(100),
 
AS
 
BEGIN
DECLARE  @КолвоКниг INT 
DECLARE  @IDКнига INT 
@IDКнига =(SELECT ID FROM Books WHERE Name=@Книга)
IF NOT @IDКнига IS NULL BEGIN
 @КолвоКниг=(SELECT nCount FROM Books WHERE id=@IDКнига )
 IF @КолвоКниг>1 BEGIN
  UPDATE Books SET nCount=nCount-1 WHERE id=@IDКнига
  INSERT INTO Sale (@IDКнига)
 END
END
 
END
GO

И применение:

SQL
1
EXECUTE [Купить]("Охота за Красным Октябрем");

Смысл: Все проверки упаковать в процедуру. Добавить по вкусу обработку исключений и ошибок.
Забыть про триггеры.

@pincet · 19.02.2016, 16:56

ужос

никому больше не показывайте такие подходы и к оперативному учету, и написанию на SQL

@RCF · 22.02.2016, 21:37

Сообщение от Hikari

Я не рекомендую тебе вести живые остатки в базе.
Остатки - это вычисляемая величина по периодам и списку приходно расходных ордеров. Их не рекомендуется хранить в базе

Не совсем понял, что имеете ввиду?

То есть запасы не должны храниться в таблицах и определение остатка на складе должно выполняться методом подсчета?

@Hikari · 22.02.2016, 22:07

Сообщение от RCF

То есть запасы не должны храниться в таблицах и определение остатка на складе должно выполняться методом подсчета?

Совершенно верно. Иначе однажды ты не сведешь баланс, если хранимые остатки у тебя будут расходиться с набором ордеров. Если это курсовая - еще ладно, но если реальная программа, то, думаю тебе не стоит будить спящего налогового инспектора.

@invm · 22.02.2016, 22:42

Hikari, набросайте схематично - как при вашем подходе контролировать целостность данных, т.е. чтобы расход не превышал приход.

@RCF · 23.02.2016, 01:06

Сообщение от Hikari

Совершенно верно

Вы глубоко заблуждаетесь по тому поводу, чтобы остатки не должны храниться на складе ))

И причем тут не сведешь ? И причем тут набор ордеров и факт хранения (в таблицах) запаса на складе?

@Hikari · 23.02.2016, 09:18

Сообщение от invm

как при вашем подходе контролировать целостность данных, т.е. чтобы расход не превышал приход.

Что значит "как"?
Как получить список приходных ордеров по коду ордера?
Как вообще кладовщики работают в бумажных каталогах товара, знаешь? Как они подбивают свои остатки?

Сообщение от RCF

Вы глубоко заблуждаетесь по тому поводу, чтобы остатки не должны храниться на складе ))

Ну тогда я умолкаю.

Сообщение от RCF

И причем тут не сведешь ?

У тебя допустим произойдет ситуация, когда остаток не запишется в поле таблички, но движение товара зафиксируется в виде накладной. Ты потом какой циферке доверять будешь? Той, которая будет в виде остатка, или той, которая пройдет по учету инвентаризации?

Ладно, я уже поняла. Мне в этой теме не рады, более мешать не буду. Делайте как умеете - я свое мнение из личного опыта работы со складом выразила.

@pincet · 23.02.2016, 09:29

Сообщение от RCF

Вы глубоко заблуждаетесь по тому поводу, чтобы остатки не должны храниться на складе ))

хранить остатки без движений - бред.Покурите оперативный учет

@invm · 23.02.2016, 11:30

Сообщение от Hikari

Что значит "как"?
Как получить список приходных ордеров по коду ордера?
Как вообще кладовщики работают в бумажных каталогах товара, знаешь? Как они подбивают свои остатки?

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

Сообщение от Hikari

У тебя допустим произойдет ситуация, когда остаток не запишется в поле таблички, но движение товара зафиксируется в виде накладной.

ACID? Транзакции? Не, не слышала.

Сообщение от Hikari

Ну тогда я умолкаю.

Правильно. Не стоит позориться и лезть с советами в область, в которой не разбираетесь.

@Hikari · 23.02.2016, 12:46

Сообщение от invm

Перед каждым списанием "подбиваем остатки".

Зачем? Причем тут списание? Движение товаров формируется на основе ордеров за период. Если за определенный период был по накладным отгружен товар, то самым простейшим запросом с агрегатными функциями легко получим остатки. Причем тут списание?

Сообщение от invm

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

А чего тут думать? Я уже так 5 лет работаю, и от пользователей только спасибо слышу.
Зато около 6 лет мучаюсь с программой, которая остатки хранит в таблице. Вечно получается так, что между периодами происходит недостача, ибо кто-то вручную остатки корректирует, и они потом с движением не коррелируются. В результате бухгалтерия пъет корвалолчик и хватается за сердечко.
А потом я сижу и полнедели эти остатки правлю. Бр-р-р...

Сообщение от invm

ACID? Транзакции? Не, не слышала.

А причем тут транзакции? У тебя данные дублируются. Транзакции тут не помошники.

@invm · 23.02.2016, 13:42

Сообщение от Hikari

Зачем? Причем тут списание?

Что, действительно не понимаете?
Допустим, вы наагрегировали по движениям остаток некоего артикула в 10 единиц. Теперь проводят расходную накладную с этим же артикулом на 11 единиц. Контролировать такую ситуацию не нужно?

Сообщение от Hikari

Зато около 6 лет мучаюсь с программой, которая остатки хранит в таблице. Вечно получается так, что между периодами происходит недостача, ибо кто-то вручную остатки корректирует, и они потом с движением не коррелируются.

Это всего лишь говорит о том, что у вас бардак с учетом. Потому что при нормальной работе никто остатки вручную не корректирует.

Сообщение от Hikari

А причем тут транзакции?

Что, опять не понимаете?
Транзакции нужны, что бы не получить "остаток не запишется в поле таблички, но движение товара зафиксируется в виде накладной".

@Hikari · 23.02.2016, 14:10

Сообщение от invm

Теперь проводят расходную накладную с этим же артикулом на 11 единиц.

И? Программа должна получить остаток на складе по списку проведенных накладных и вынести вердикт о том, есть ли товар или уже весь ушел в движение.

Сообщение от invm

Потому что при нормальной работе никто остатки вручную не корректирует.

А я разве говорю что у меня все хорошо? Именно из-за хранения остатков из-за непродуманной структуры хранилища остатки и приходится корректировать. Программист, который мне такую ПО поставил не учитывал вообще ничего, в результате часть накладных (особенно при фиксировании боя и возврата) просто не фиксирует ордера. Да и со списание беда. А товароведам все равно. Им главное свести баланс, а для этого нужно в конце периода остатки согласовать с бухгалтерией, вот и лезут ручками прямо в таблицу.

Сообщение от invm

Транзакции нужны, что бы не получить "остаток не запишется в поле таблички, но движение товара зафиксируется в виде накладной".

А причем тут это? Если у тебя никогда не было ситуаций, когда ПО, коим ты пользуешься, работает на ура, то это не значит что у всех остальных все так же. Просто признайся - ты не сталкивался с ситуациями, когда и срочно, и точно и немедля, иначе накажут

И как можно надеяться на транзакцию, если она изначально оказывается несогласованной с другими движениями данных?

@pincet · 23.02.2016, 16:00

Сообщение от Hikari

И как можно надеяться на транзакцию, если она изначально оказывается несогласованной с другими движениями данных?

Это в анналы. Зачем вообще нужны транзакции?

Добавлено через 2 минуты

Сообщение от pincet

Зачем тогда вообще нужны транзакции?

И зачем конечному пользователю знать про "Что? Что у вас? - У нас транзакция. - @я, мне .... что это. Прямо здесь и прямо сейчас!"

@iap · 23.02.2016, 16:09

Мне кажется, для данной задачи стоит рассмотреть реализацию в виде индексированного представления.

@Hikari · 23.02.2016, 16:14

Сообщение от pincet

И зачем конечному пользователю знать

Во-первых не нужно так бурно проявляться. Ты все таки не Свема.
Во-вторых пользователю особенно кладовщику это не интересно. Кладовщику бы баланс свести. Да так, чтоб сошлось с бухгалтерией до копеечки. Его не интересуют ни транзакции ни то, как хранятся остатки, ни то, какой методикой они высчитываются. Если у кого-то схема с хранением остатков отдельной цифирью независимо от списка ордеров работает на ура - я очень рада.
На сим откланиваюсь, свое мнение я выразила. Принимать его или плеваться от избытка самомнения - это уже меня не интересует.

@pincet · 23.02.2016, 16:24

Сообщение от Hikari

Если у кого-то схема с хранением остатков отдельной цифирью независимо от списка ордеров работает на ура - я очень рада.

а это что?
UPDATE Books SET nCount=nCount-1 WHERE id=@IDКнига
INSERT INTO Sale (@IDКнига)

@invm · 23.02.2016, 16:27

Сообщение от Hikari

И? Программа должна получить остаток на складе по списку проведенных накладных и вынести вердикт о том, есть ли товар или уже весь ушел в движение.

Ага, ожидаемый ответ. С учетом работы БД в многопользовательском окружении:
1. Как вы обеспечите достоверность полученных значений?
2. Как предотвратить получение одного и того же значения остатка параллельными сеансами, с последующей некорректной проверкой допустимости списаний?

Сообщение от Hikari

А я разве говорю что у меня все хорошо? Именно из-за хранения остатков из-за непродуманной структуры хранилища остатки и приходится корректировать. Программист, который мне такую ПО поставил не учитывал вообще ничего, в результате часть накладных (особенно при фиксировании боя и возврата) просто не фиксирует ордера. Да и со списание беда. А товароведам все равно. Им главное свести баланс, а для этого нужно в конце периода остатки согласовать с бухгалтерией, вот и лезут ручками прямо в таблицу.

И что? Как это влияет на безапеляционность вашего предложения не хранить остатки?

Сообщение от Hikari

А причем тут это? Если у тебя никогда не было ситуаций, когда ПО, коим ты пользуешься, работает на ура, то это не значит что у всех остальных все так же. Просто признайся - ты не сталкивался с ситуациями, когда и срочно, и точно и немедля, иначе накажут

Ну да, сначала сделаем кривой дизайн БД, да еще и разрешим всем подряд лазить в таблицы руками и править что угодно и как угодно. А потом будем героически бороться с последствиями, внедряя не менее кривые костыли и выдавая это за собственные достижения, которыми можно гордиться и рекомендовать как единственно правильный способ решения задачи.
И если вы привыкли так работать, это не означает, что все остальные должны работать аналогично.

Сообщение от Hikari

И как можно надеяться на транзакцию, если она изначально оказывается несогласованной с другими движениями данных?

Транзакции не бывают согласованными с данными.
Если ваша БД открыта для прямых модификаций без всякого контроля, - не помогут ни транзакции, ни что-либо еще.

Новые блоги и статьи Все статьи Все блоги /
My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .
Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача №1: при указании работ (справочник РаботыПоРемонтуСпецтехники),. . .

@kurtx 0 / 0 / 0 Регистрация: 14.07.2015 Сообщений: 19
	19.02.2016, 14:29 [ТС]
	Hikari, я только начинаю изучать t-sql, нужно выполнить описанную выше задачку, если есть другой способ это сделать, покажите пожалуйста наглядно за совет спасибо 0

@pincet 1655 / 1154 / 173 Регистрация: 23.07.2010 Сообщений: 6,910
	19.02.2016, 16:56
	ужос никому больше не показывайте такие подходы и к оперативному учету, и написанию на SQL 0

@invm 3614 / 2135 / 756 Регистрация: 02.06.2013 Сообщений: 5,169
	22.02.2016, 22:42
	Hikari, набросайте схематично - как при вашем подходе контролировать целостность данных, т.е. чтобы расход не превышал приход. 0

@iap 1116 / 761 / 183 Регистрация: 27.11.2009 Сообщений: 2,272
	23.02.2016, 16:09
	Мне кажется, для данной задачи стоит рассмотреть реализацию в виде индексированного представления. 0