Полностью неудовлетворенный антропоид поспел первым — он вывелся две недели назад. Это жалкое существо, покрытое язвами, как Иов, полуразложившееся, мучимое всеми известными и неизвестными болезнями, страдающее от холода и от жары одновременно, вывалилось в коридор, огласило институт серией нечленораздельных жалоб и издохло. Выбегалло торжествовал. Теперь можно было считать доказанным, что ежели человека не кормить, не поить и не лечить, то он, эта, будет, значить, несчастлив и даже, может, помрет. Как вот этот помер.
А вот это как раз тот ответ, после которого шансы пройти собеседование у меня падают вдвое.
Мне не нужны абстрактные теоретики. Мне нужны люди, решающие задачи. Если человек решает задачу «абстрактно» без учета факторов, которые приведут к неверному конечному ответу — он будет работать где-нибудь, где результат неважен. В госконторе какой-нибудь.
Вашу фразу несколько выше я понял так: большинство полей в схеме Вы описываете как необязательные и контроль выполняете в конкретном компоненте бизнес-процесса на уровне приложения. Контроль на уровне базы — только в небольшом числе полей.
Так ли это?
Означает ли это также, что бОльшая часть проверок, соответственно, производится на уровне приложения?
Т.е. Вы НЕ используете средства БД по контролю целостности и никто конкретно не отвечает за то, чтобы информация по обязательности полей попала в структуру БД?
Я правильно понял ту часть, на которую Вы не стали отвечать?
Т.е. у Вас обязательность для схемы не определяется обязательностью для бизнеса, а формулируется по некоторым другим причинам? И Вы не используете средства обеспечения целостности БД, обрабатывая целостность на уровне приложения? Если не секрет — каков объем данных?
Или все же зависит? Если да, то как эта информация попадает из документации на бизнес-процессы в документацию на схему БД и кто обеспечивает управление изменениями?
Кстати, в свете некоторых Ваших комментариев у меня возник конкретный вопрос: как именно Вы документируете в модели данных тот факт, что данное поле обязательно для бизнес-процесса X, но необязательно для бизнес-процесса Y? И как в дальнейшем управляете изменениями? В частности, как именно проверяете, что не возникает ситуации, когда на шаге N уже не осталось акторов, которые могут ввести данные, обязательные для шага N+1?
Я понимаю, что возможен ответ «а само как-нибудь срастется», но верю в лучшее.
Они тупо приезжали с бумажками. Некоторые думают, что в бумажках нет обязательных полей — это не так. В которых, в общем случае, все поля являются обязательными, если не заявлено иное. Видели, как зигзагом зачеркивают незаполненный низ таблички в накладной?
Петрову сказали, а он не пришел. Петров забыл, что это нужно. Вы навязываете клиенту обязанность понимать ваши бизнес-процессы, а это куда хуже заполнения обязательных полей.
Сейчас, кстати, это работает не так. Анкету у Петрова вообще не примут, пока он не заполнит ее корректно.
Да, реализовать ввод неполной анкеты можно. Но нам придется ввести уже ТРИ типа полей: «совсем обязательные», «обязательные для приема анкеты и отпускания клиента» и «необязательные».
И процедуру приема посетителей придется доработать, организовав отдельную очередь для тех, кто пришел только доввести данные.
В очередной раз обращаю внимание: заполнение форм — только часть реальной жизни, а не ее суть. Петров пришел не для заполнения анкеты, он пришел паспорт получить.
В воображаемом мире — дозаполнить данные. А реальном — лапу сосать.
«Оформляем паспорт… Петров не заполнил адрес и телефон… напомним Петрову… эээ… как? Выйдем на улицу и на всю страну закричим: ПЕ-Е-ЕТРОВ! Заполни адрес и телефон!»
Отлично. Экспедитор приехал за товаром, кладовщик встал к терминалу — и радостно сообщил, что в накладной забыли ввести список закупленных товаров.
Никаких проблем — нужно лишь дождаться, пока в родном для экспедитора Петропавловске наступит новый рабочий день и там дозаполнят форму.А машина пока постоит на улице, экспедитор поспит в кабине.
«Данная конкретная операция» — не «нажать кнопку получения товара», а «получить товар, загрузить в машину и отправить». И банальное «донабрать недостающее» легко выливается в реальные потери.
предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design
Как ни странно, для того, чтобы система работала с неполными данными, вовсе нет нужды повышать ее «стрессоустойчивость».
Принцип здесь гораздо более простой: поток данных делится на сегменты различной полноты. Переход в следующий сегмент — только по достижению нужного уровня наполненности и непротиворечивости. При этом в полный рост сохраняется возможность использовать ограничения баз данных.
BTW, работа с противоречивыми данными гораздо важнее и сложнее, чем работа с неполными данными. Проблема обязательных полей — только верхушка айсберга «data cleansing».
аналогично — следующие два эксперимента.
Я ответил на этот вопрос выше.
Это я также прокомментировал выше.
Мне не нужны абстрактные теоретики. Мне нужны люди, решающие задачи. Если человек решает задачу «абстрактно» без учета факторов, которые приведут к неверному конечному ответу — он будет работать где-нибудь, где результат неважен. В госконторе какой-нибудь.
Одна из замечательных задачек, с помощью которых интервьюер ничего не узнает, но может показать свое превосходство.
Вашу фразу несколько выше я понял так: большинство полей в схеме Вы описываете как необязательные и контроль выполняете в конкретном компоненте бизнес-процесса на уровне приложения. Контроль на уровне базы — только в небольшом числе полей.
Так ли это?
Означает ли это также, что бОльшая часть проверок, соответственно, производится на уровне приложения?
Я правильно понял ту часть, на которую Вы не стали отвечать?
Или все же зависит? Если да, то как эта информация попадает из документации на бизнес-процессы в документацию на схему БД и кто обеспечивает управление изменениями?
Т.е. в модели данных у Вас НЕ документируется обязательность полей? А где документируется? В описании каждого отдельного бизнес-процесса?
И дизайнер базы данных изучает каждый из них в отдельности при проектировании структуры БД?
Я правильно понял Вашу концепцию проектирования?
Я понимаю, что возможен ответ «а само как-нибудь срастется», но верю в лучшее.
Если Петров может быстро предоставить эти данные — его незачем гнать из кабинета, достаточно переспросить. И поля вполне срабатывает как обязательное.
Если мы выгнали Петрова — мы обязаны добавить отдельный шаг в бизнес-процесса.
Компьютерные программы и бизнес, который они обеспечивают — не одно и то же.
Компьютерные программы и бизнес, который они обеспечивают — не одно и то же.
Сейчас, кстати, это работает не так. Анкету у Петрова вообще не примут, пока он не заполнит ее корректно.
Да, реализовать ввод неполной анкеты можно. Но нам придется ввести уже ТРИ типа полей: «совсем обязательные», «обязательные для приема анкеты и отпускания клиента» и «необязательные».
И процедуру приема посетителей придется доработать, организовав отдельную очередь для тех, кто пришел только доввести данные.
В очередной раз обращаю внимание: заполнение форм — только часть реальной жизни, а не ее суть. Петров пришел не для заполнения анкеты, он пришел паспорт получить.
«Оформляем паспорт… Петров не заполнил адрес и телефон… напомним Петрову… эээ… как? Выйдем на улицу и на всю страну закричим: ПЕ-Е-ЕТРОВ! Заполни адрес и телефон!»
Никаких проблем — нужно лишь дождаться, пока в родном для экспедитора Петропавловске наступит новый рабочий день и там дозаполнят форму.А машина пока постоит на улице, экспедитор поспит в кабине.
«Данная конкретная операция» — не «нажать кнопку получения товара», а «получить товар, загрузить в машину и отправить». И банальное «донабрать недостающее» легко выливается в реальные потери.
Так что будьте ближе к реальной жизни.
Как ни странно, для того, чтобы система работала с неполными данными, вовсе нет нужды повышать ее «стрессоустойчивость».
Принцип здесь гораздо более простой: поток данных делится на сегменты различной полноты. Переход в следующий сегмент — только по достижению нужного уровня наполненности и непротиворечивости. При этом в полный рост сохраняется возможность использовать ограничения баз данных.
BTW, работа с противоречивыми данными гораздо важнее и сложнее, чем работа с неполными данными. Проблема обязательных полей — только верхушка айсберга «data cleansing».