Igor Korolyov

PaulWist
Э-э-э, брат, объясни мне, как ты заполняешь документ, когда часть данных на момент заполнения ещё неизвестна? ставишь наобум обязательные атрибуты, а потом по ним можно сделать отчет? как ты узнаешь что в этом доке всё правильно заполнено, а другом нет?

Начнём с простого. Я не заполняю "непойми что" - вот Владимир Максимов - да. Он, вероятно как и ты, сохраняет абсолютно произвольный мусор в таблицах шапка-детали-поддетали, и только при установлении статуса "готово" проверяет этот мусор "по полной программе". Т.е. у него нет никаких констрейнов not null, никаких check-ов, возможно нет и foreign key констрейнов (т.к. в этом случае реальный "мусор" будет мешать и работе со справочником, и работе с таблицами ссылающимися на эти полу-мусорки, а сделать декларативный FK работающий лишь с "хорошими" записями но пропускающий "плохие" невозможно в известных мне СУБД).

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

Совсем уж "мусор", разумеется, не вводят. Есть некоторые обязательные для заполнения данные, есть некоторые предварительные проверки. Но есть и некие "завершающие" проверки, которые выполняются только когда пользователь дает "отмашку" о готовности документа. Сам дает. Явно нажав на соответствующую кнопку.

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

В такой постановке задачи триггер бесполезен. На момент ввода/изменения значения любой записи документа (не важно, шапки или строки) выполнять сравнение суммы в шапке и суммы по строкам не просто бессмысленно, но откровенно вредно. Как пользователь в этом случае сами суммы будет менять? Он вообще не сможет ничего ввести. Триггер будет постоянно ругаться и отменять любые изменения

Но, в то же время, и не сохранять записи тоже нельзя. Ну, возьмем крайний случай с документом на 100500 строк. Пользователь весь день вбивал все эти строки, осталось ввести парочку, но сохранить ты ему не даешь, поскольку сумма не совпадает. Ему что, завтра с утра по новой это все набивать? Нет, конечно!

Вот в такой ситуации различные статусы и этапы обработки как раз и уместны. Завершил ввод данных, дал "отмашку", выполняем проверку.

Владимир Максимов
Не надо в крайности впадать.

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

Владимир Максимов
Совсем уж "мусор", разумеется, не вводят. Есть некоторые обязательные для заполнения данные, есть некоторые предварительные проверки. Но есть и некие "завершающие" проверки, которые выполняются только когда пользователь дает "отмашку" о готовности документа. Сам дает. Явно нажав на соответствующую кнопку.

Ну потому что у тебя компромиссное решение - хотя по сути эти предварительные проверки не играют большой роли. Всё равно пока не будет "нажата кнопка" с точки зрения логики в БД будет "мусор" - то что нельзя использовать, нельзя учитывать - единственное что с этим мусором можно сделать - загрузить обратно в форму ввода для продолжения вбивания данных.
Я просто с трудом представляю себе "документы" которые вбивались бы на протяжении недели. Это, скорее, отсутствие декомпозиции сложной сущности на более простые и управляемые части. И уж поверь, с большими документами мы тут имеем дело - и проекты выполнения работ (по 30-40 "разделов"), и наряды и сметы... Просто можно поделить их на логически завершённые части, а "соответствие между частями" оформлять не железобетонной логикой БД (которая должна исполняться всегда - в любой момент времени и для ВСЕХ записей), а как раз таки отдельно живущими проверками и статусами "между сметой и нарядом расхождений нет". Что вполне себе позволяет во время "работы над документом" иметь кучу "противоречий в данных" - но лишь МЕЖДУ его логическими частями, а не в рамках одной небольшой части.
Естественно и сами проверки и установку статусов выполняет весьма сложная бизнес-логика (она может быть и в виде ХП, и в виде прикладного кода - это совершенно непринципиально - конечно же она НЕ может быть в виде триггера - не "технически" а идеологически).

Владимир Максимов
Ну, например, первое, что пришло в голову. В шапке документа указываем некую сумму. Сумма по строкам должна совпасть с суммой в шапке.

И сразу же "тупой вопрос". Назачем "вводить" эту сумму? Если она в любой момент времени тупо считается исходя из введенных "строк"?
Это такая же "странная" идея как, к примеру, вводить для строк отдельно цену, количество, сумму, процент НДС, цену с НДС и сумму с НДС.
И потом бодро рапортовать несчастному юзеру о несоответствии между какими-то из полей. Спрашивается назачем так делать?

Владимир Максимов
Вот в такой ситуации различные статусы и этапы обработки как раз и уместны. Завершил ввод данных, дал "отмашку", выполняем проверку.

Статусы нужны совсем не для этого... Те которые бизнес-статусы. Вот статус "проверено главбухом/аудитором" или "подписано директором" - это понятно.
А "признак г*на в данных" - это не бизнес-статус - это технологический костыль.
Кстати, "проект договора" это таки бизнес-сущность. Только она отличается от "реально договора" вовсе не тем что "сумма по строкам" не бьётся с "суммой по документу", или что в строках вместо названий товаров/работ/услуг (ссылок на соответствующий справочник) будет написана какая-то ересь типа "хрен его знает что на 500р."...
Даже в тривиальном экселе никому в голову не приходит вместо использования СУММ() "вручную" считать сумму по строкам и потом ещё нанимать человека чтобы он проверял "совпадает али нет" Так отчего же в нормально написанной задаче использующей СУБД нужно поступать иначе?

PaulWist
С какой стороны посмотреть - это по большому счёту деньги, те когда, на сколько и в каком количестве "посылать" на курсы аттестации/переквалификации/итп, те такая инфа становится обязательной!

Когда человека принимают на работу, то информацию о дипломах и прочем совершенно необязательно вводить. Точнее вполне можно завести на человека табель БЕЗ указания подобных "реквизитов". Вот без ТН и без ФИО это сделать наверняка нельзя.

Если же где-то бизнес-процесс построен так что без диплома ну совсем низзя (ну там приём на 2-е высшее или в какую аспирантуру/магистратуру) - то нельзя ВООБЩЕ ничего вводить в систему. Зачем там мусор? Такого чела отсеют ещё до того как начнут вбивать что-то в компьютер.
Кстати - очередной пример нереализуемой через триггер логики - если рассматривать ПО условно говоря "деканат" - где принимают на учёбу и просто выпускников школы и людей с ВО и на "обычную форму" и на "последипломное" - там бизнес логика потребует наличия в одном случае сущности аттестат, в другом - диплом, в третьем - обязательно будет "направление от организации" или "гарантийное письмо об оплате"... Т.е. вроде как и "обязательный" реквизит, а с другой стороны - лишь "условно-обязательный".
Я думаю проще повеситься чем прописывать такого рода логику в триггерах Даже в просто ХП на tsql оно будет не лучшим образом выглядеть... А учитывая что правила меняются ежегодно, и та БЛ что была в 2016 уже не покатит в 2017 - так и тем паче
По крайней мере проверенная внешним валидатором и "зафиксированная" статусом запись в БД выглядит нормально, а ЯВНО нарушающая прописанную логику ХП или триггера (поскольку тот был изменён под "новые требования") - ну "не очень" красиво выглядит...

Igor Korolyov

Владимир Максимов
Не надо в крайности впадать.

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

Так он уже ответил на это

PaulWist
Повторю ещё раз, трёхзвенка может существовать и существует успешно, но я считаю, что БД должна быть самодостаточна без всяких внешних "приблуд", ... догма/придурь/итд у меня такая.
Карфаген должен быть разрушен!

Т.е. это его "религиозная" позиция. Поэтому все аргументы особого смысла не имеют. Его позиция будет такая: для МОИХ задач ТАКОГО быть не может. Или надо менять саму постановку задачи

Собственно, ты делаешь то же самое.

Я привел пример. Естественно, достаточно абсурдный и не вполне логичный. Абсолютно такой же как и твой пример про ставку акциза и признак алкоголя. Ты же всерьез начал его анализ и именно с той же самой позиции, что и Паша. Т.е. сразу стал придираться к ПОСТАНОВКЕ! Обрати внимание ЧТО ты стал критиковать

Igor Korolyov
Я просто с трудом представляю себе "документы" которые вбивались бы на протяжении недели.

Igor Korolyov
И сразу же "тупой вопрос". Назачем "вводить" эту сумму?

Igor Korolyov
Статусы нужны совсем не для этого...

Тенденция очевидная. Ты точно также как и Паша пытаешься поменять саму постановку задачи сведя ее к ПРИВЫЧНОЙ тебе постановке. Той, в которой ты ПРИВЫК решать задачи. По сути, к своему FrameWork.

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



Исправлено 1 раз(а). Последнее : Владимир Максимов, 21.03.17 13:36

Хорошо, оставим в покое "постановку" или "пример". Будем говорит абстрактно.

Твой вариант - часть БЛ "постоянна", часть - "обозначается флажком". Это вариант - он вполне реализуем

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

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





Исправлено 1 раз(а). Последнее : Igor Korolyov, 21.03.17 17:41

Игорь, по моему ты не о том.
О чем дискуссия. О физическом месте БЛ.
Паша ратует за БД, считая его неотъемлемой частью.
Далее ты приводишь конкретные задачи, а он их по своему решает, и тд. и т.п.
На мой взгляд, неверный подход к самой дискуссии.

Я в самом начале сказал, что неудобно, иметь БЛ, в множестве ХП. куда удобнее, разместить ее в привычных классах.
Паша насчитал 509 ХП. И он ухитряется "легко" в них ориентироваться.
Уверен, ориентироваться в 2х-3х десятков классов легче.
А любую задачу, можно решить в любом месте, более привчном тебе. Потому примеры... не имеют смысла)
Это основной мой довод
И второе.
Дело в том, что я давно не встречаю, таких однозначных задач, когда есть только одна БД.
Как правило есть еще 1С, другие сервисы, программы, контроллеры.
И все это надо увязывать в одну БЛ.
Это размещать в БД.... как бы верх неразумности.
(Каюсь, и такое есть у меня, но я хоть сознаю, что это не верно!)

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

Хочется сказать, что решает Паша так, и нормально, пусть.
Вот он в базе, как 1С, еще и данные приложения держит. разные макроданные прикладного ПО. Как помнится у алекс00001 было.
Вот это... по мне совсем ни как(
Но видимо ему то так удобнее.

Пришел Максимов и поставил всех в "угол" и правильно.

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

С другой стороны, примеры Игоря было интересно посмотреть.

Ежели для решения задачи нужно выстраивать 3-этажную конструкцию из костылей (чтобы остаться в рамках своей "догмы"), то лично я предпочту просто кардинально поменять подход
Поэтому меня совсем не парит "БД как просто набор таблиц" Лишь бы к ней был придан достаточно адекватный АПИ, и тогда я спокойно забуду про то что там нет ни PK c FK, ни триггеров, ни вообще какой либо БЛ.

Igor Korolyov
Ежели для решения задачи нужно выстраивать 3-этажную конструкцию из костылей (чтобы остаться в рамках своей "догмы"), то лично я предпочту просто кардинально поменять подход Поэтому меня совсем не парит "БД как просто набор таблиц" Лишь бы к ней был придан достаточно адекватный АПИ, и тогда я спокойно забуду про то что там нет ни PK c FK, ни триггеров, ни вообще какой либо БЛ.

Ну, Володя уже сказал, что это вопрос "религиозный", решить можно и так и так, только я уже сказал, что моя "православная БД" , лучше чем всякие "БД свидетелей Иеговых"

PS шутка





Исправлено 2 раз(а). Последнее : PaulWist, 22.03.17 17:37

Главное, чтобы ваш код работал, там где надо. И даже это не главное)