Это уже не первый заход на эту тему.

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

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

Естественно, это лишь частное мнение, не претендующее на "истину в последней инстанции".

Владимир Максимов
Все-таки не утерпел. Начал

Дык кто "заводит" то

Владимир Максимов
1. Качество приложения...

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

Владимир Максимов
2. Любая идея доведенная до своего логического завершения становится абсурдной

Нет. Метод "доведение до абсурда" применим лишь к изначально ущербным/ошибочным теориям/идеям. Корректная идея таким способом не разрушается.

Владимир Максимов
Вот с чего ты решил, что если ослабить контроль корректность в момент сохранения, то нельзя будет выполнить контроль корректности ПОТОМ?

Проверить то можно - это не самая большая проблема (хотя таки проблема - т.к. придётся кодить руками всё то что нормальные СУБД умеют делать БЕЗ кода - "легко и просто"), но что будет "в промежутке" в БД? И если речь идёт про систему, а не одно единственное приложение, то возникает 100500 вопросов по созданию либо общего слоя доступа/АПИ который относительно "прозрачно" изолирует "мусор" от "данных", либо от внедрения во всех компонентах системы единообразной (и достаточно непростой) логики для этого самого отсеивания зёрен от плевел...

Владимир Максимов
Вот с чего ты решил, что нельзя разделить данные на предварительные и окончательные?

Предварительные данные - это всё же не мусор. Они по сути должны удовлетворять тем же правилам что и "окончательные" (Они вообще чаще всего должны менять свой статус на "утверждено" БЕЗ всякого изменения). Вот "недовведенные" данные (имя ввёл, а фамилию не стал), или просто открыл форму, и вообще забил на всё и пошёл домой - это мусор.

Владимир Максимов
"Мусор", конечно, будет. Но он будет занимать строго отведенное ему место

Ага, в той же таблице что и чистые данные, а для реальной системы, где "документ" это даже не 2 а все 10-15 а то и 20 таблиц, то понять к чему относится эта конкретная запись - к мусору или к полезной инфе - мягко говоря очень сложно.

Владимир Максимов
Для меня кажется странным запретить немедленное сохранение при вводе документа на 100500+ строк. Как в таких условиях работать-то? Это сутками не есть не спать, вводить ОДИН документ? Глупость какая-то!

Для меня кажется очень странным НАЛИЧИЕ в системе "документа" на 100500 строк, который реально требует пару суток для ввода. Почему он не разделён на логически завершённые части/разделы/поддокументы?
У нас, когда заходит речь о реально сложном и массивном документе (там даже не 20, там в общей сложности хорошо за сотню таблиц фигурирует) то вводятся понятия "разделов", ответственных за их ввод лиц, достаточно строгий порядок ввода данных разделов (грубо говоря сначала вводим параметры "шасси" и только потом допустимый на это шасси "навес", а не наоборот), сложная схема утверждения/согласования разделов, и, что самое важное, ВСЕ эти "черновики/заготовки" ПРОВЕРЯЮТСЯ на соответствие основным правилам бизнес-логики. Т.е. в принципе можно из 10 требуемых "агрегатов" указать только 1 и сохранить данные (на утверждение это не пойдёт), но НЕЛЬЗЯ ввести агрегат без наименования/ссылки на справочник, или там "мощность" указать в 100гигаватт, или наоборот "в ноль". Т.к. "сложные" бизнес-правила не могут проверяться декларативно, и потому программная проверка может быть приурочена к моменту "подачи на согласование", но простые то правила проверяются сразу, и тупо допускать г*но в БД просто потому что "всё одно это реально будет играть роль когда-то потом" я не вижу ни малейшего смысла.

Т.е. я к тому что проверка проверке рознь, но к наличию мусора в БД "сложность и длительность ввода" никак не относится. Неполнота - да, но явная ошибочность - никогда.

А мне кажется вы о разном, и Игорь не спорит с Владимир Максимов
Он начал спорить с

Crispy
Т.е. на этот момент все должно быть по умолчанию сохранено. И это бывает лучше всего - стараться сохранять всегда сразу же при занесении.

И тут есть к чему придраться. Да Crispy думаю все же написал не то что думал. Наверное и он сохраняет какими то логическими блоками.
Потому как, сохранять каждое поле, сразу после введения... такой подход... точно смерть)
Вот Божья_коровка поняла о чем Игорь )

 



Исправлено 2 раз(а). Последнее : Crispy, 07.08.17 09:42

 



Исправлено 1 раз(а). Последнее : Crispy, 07.08.17 09:42

 



Исправлено 5 раз(а). Последнее : Crispy, 07.08.17 09:43