Проекты и методы для защиты от ошибочных нулевых записей из базы данных

9

Одна часть моей программы извлекает данные из многих таблиц и столбцов в моей базе данных для обработки. Некоторые из столбцов могут быть null, но в текущем контексте обработки это ошибка.

Этого не должно "теоретически" происходить, поэтому, если это так, это указывает на неверные данные или ошибку в коде. Ошибки имеют различную серьезность, в зависимости от того, какое поле null; то есть для некоторых полей обработка должна быть остановлена, и кто-то должен уведомить об этом, а для других обработка должна быть разрешена для продолжения и просто уведомить кого-то.

Есть ли хорошая архитектура или принципы дизайна для обработки редких, но возможных nullзаписей?

Решения должны быть реализованы с помощью Java, но я не использовал этот тег, потому что я думаю, что проблема несколько не зависит от языка.


Некоторые мысли, которые у меня были:

Использование NOT NULL

Проще всего было бы использовать ограничение NOT NULL в базе данных.

Но что, если первоначальная вставка данных важнее, чем этот последующий этап обработки? Таким образом, в случае, если вставка вставит nullв таблицу (из-за ошибок или, может быть, даже по какой-то уважительной причине), я бы не хотел, чтобы вставка не удалась. Допустим, что многие другие части программы зависят от вставленных данных, но не от этого конкретного столбца. Поэтому я бы предпочел рискнуть ошибкой на текущем шаге обработки вместо шага вставки. Вот почему я не хочу использовать ограничение NOT NULL.

Наивно в зависимости от NullPointerException

Я мог бы просто использовать данные, как если бы я ожидал, что они будут всегда (и это действительно должно иметь место), и перехватить результирующие NPE на соответствующем уровне (например, так, чтобы обработка текущей записи остановилась, но не весь ход обработки) ). Это принцип «быстро провал», и я часто его предпочитаю. Если это ошибка, по крайней мере, я получаю зарегистрированный NPE.

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

Проверка nullперед каждым доступом и выдача пользовательских исключений

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

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

Если я решу пойти по этому пути, какие шаблоны лучше всего подходят для этого подхода?


Любые мысли и комментарии по поводу моих подходов приветствуются. Также лучшие решения любого типа (шаблоны, принципы, лучшая архитектура моего кода или моделей и т. Д.).

Редактировать:

Есть еще одно ограничение: я использую ORM для преобразования из БД в объект персистентности, поэтому проверка на ноль на этом уровне не будет работать (так как одни и те же объекты используются в тех частях, где ноль не приносит никакого вреда) , Я добавил это, потому что ответы, предоставленные до сих пор, оба упомянули эту опцию.

jhyot
источник
5
«Некоторые столбцы могут быть нулевыми, но в текущем контексте обработки это ошибка. ... если вставка поместит в таблицу пустое значение, я не хочу, чтобы вставка завершилась неудачно.» Эти два требования противоречат друг другу . Это невозможно найти решение , пока не расслабить одно из двух условий.
Килиан Фот
@KilianFoth Хорошо, мое расслабление заключается в том, что ошибка в контексте «текущей обработки» менее серьезна, чем при вставке. Поэтому я принимаю редкие ошибки обработки, но хочу иметь хороший надежный дизайн для их обработки. Вот почему NOT NULL, что в противном случае было бы хорошим решением, здесь невозможно.
Jhyot
1
Если вы принимаете так много ошибок, создатели этих ошибок никогда не исправят их. Если их грязные операторы вставки преуспевают, какой стимул они когда-либо должны исправить? Считаете ли вы надежным, не отказывая, но принимая плохие данные?
Тулаинс Кордова
@ user61852 Я явно не принимаю ошибки, но хочу изящно их обработать. Глотание нулевых указателей исключено. Кроме того, что, если моя часть действительно объективно (как определено бизнесом) менее важна, чем многие другие части, которые требуют вставки для успеха, но не требуют, чтобы это конкретное поле было установлено? Вставки происходят не из пользовательской записи, где я мог бы заставить их добавить значение, а из другого кода, где упущение, скорее всего, является ошибкой (но не настолько важным, чтобы прервать вставку).
jhyot
1
Лучшим решением было бы пометить их как NOT NULL в базе данных, если столбец обнуляем, то код должен будет обрабатывать тот случай, когда он есть, даже если он не ожидается, поскольку механизм хранения позволяет это.
Джон Рейнор

Ответы:

9

Я бы поставил нулевые проверки в вашем коде отображения, где вы строите свой объект из набора результатов. Это помещает проверку в одно место и не позволит вашему коду пройти половину процесса обработки записи до появления ошибки. В зависимости от того, как работает ваша прикладная программа, вы можете захотеть выполнить сопоставление всех результатов как этап предварительной обработки вместо сопоставления и обработки каждой записи по одной.

Если вы используете ORM, вам придется выполнять все проверки на ноль перед обработкой каждой записи. Я бы порекомендовал recordIsValid(recordData)метод -типа, чтобы вы могли (снова) хранить всю логику проверки нуля и другую проверку в одном месте. Я определенно не стал бы смешивать нулевые проверки с остальной частью вашей логики обработки.

TMN
источник
Спасибо, это хорошее понимание! Я действительно использую ORM, поэтому проверки на этом уровне не будут работать. Но у меня есть также некоторое сопоставление с реальными объектами домена из объектов постоянства. Я проверю, возможно ли выполнить сопоставление и проверку на этапе предварительной обработки.
Jhyot
А если вы переключите свой ORM, то что тогда? Лучше защитить это в источнике (см. Ответ Дока Брауна).
Робби Ди
@RobbieDee: Не важно. Если вам нужно переписать код сопоставления, то либо в нем есть нулевые проверки, и вы измените их как часть перезаписи, либо у вас есть отдельный метод, который выполняет нулевые проверки ваших бизнес-объектов, поэтому перезапись не требуется. И, как предполагает Док Браун, иногда важно заметить, что данные отсутствуют, а не скрывать этот факт значением по умолчанию.
TMN
Это должно произойти дальше в потоке ETL. Вы все еще рискуете дублировать усилия таким образом.
Робби Ди
6

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

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

Восстановить Монику
источник
2
Спасибо за ответ. Я согласен, что ваше решение - верный способ сделать это, и вы сформулировали это кратко. Ограничения вне моего влияния могут сделать это трудным или невозможным (например, недоступные ресурсы для тестирования или для того, чтобы сделать существующий код автоматически тестируемым), но я определенно должен проверить, может ли это решение работать, прежде чем пробовать другие способы. В своем первоначальном мышлении я, возможно, слишком быстро предположил, что не могу решить проблему у источника.
Jhyot
@jhyot Хорошо. Это расстраивает, когда ты не можешь делать вещи чистым способом. Надеюсь, мой ответ, по крайней мере, полезен для тех, кто сталкивается с подобными проблемами, но которые могут устранить основную причину вместо того, чтобы навести порядок.
Восстановить Монику
5

В отношении этого предложения в вопросе:

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

Я всегда ценил эту цитату (любезно предоставленную этой статьей ):

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

По сути: звучит так, будто вы одобряете закон Постеля , «будьте консервативны в том, что вы посылаете, будьте либеральными в том, что вы принимаете». Несмотря на большой теоретический потенциал , на практике этот «принцип надежности» приводит к тому, что программное обеспечение не является надежным , по крайней мере, в долгосрочной перспективе, а иногда и в краткосрочной перспективе. (Сравните статью Эрика Аллмана « Пересмотренный принцип надежности» , которая является очень тщательным рассмотрением предмета, хотя в основном и сосредоточена на случаях использования сетевых протоколов.)

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

Прагматично говоря, однако, иногда вам нужно разрешить «сломанному» поведению продолжаться, по крайней мере, временно, особенно в рамках плавного перехода от слабого нарушенного состояния к строгому, правильному состоянию. В этом случае вы хотите найти способ, позволяющий неправильным вставкам успешно выполняться, но при этом позволить «каноническому» хранилищу данных всегда быть в правильном состоянии . Есть несколько способов сделать это:

  • Используйте триггер базы данных, чтобы преобразовать неправильно сформированные вставки в правильные вставки, например, заменив отсутствующие / нулевые значения значениями по умолчанию
  • Неправильные программы вставляют в отдельную таблицу базы данных, которая может быть «неправильной», и имеют отдельный запланированный процесс или другой механизм, который перемещает исправленные данные из этой таблицы в каноническое хранилище данных
  • Используйте фильтрацию на стороне запроса (например, представление), чтобы гарантировать, что данные, извлеченные из базы данных, всегда находятся в правильном состоянии, даже если данные в покое не

Один из способов обойти все эти проблемы - вставить слой API, которым вы управляете, между программами, которые создают записи, и реальной базой данных.

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

Как только вы получите больше , чем несколько систем, которые разрешено изменять данные в каноническом производстве данных хранения вы собираетесь быть в беде: нет никакого способа , чтобы централизованно поддерживать что - либо об этой базе данных. Лучше было бы разрешить как можно меньшему числу процессов выполнять записи и использовать их в качестве «привратников», которые могут предварительно обрабатывать данные перед вставкой по мере необходимости. Точный механизм для этого действительно зависит от вашей конкретной архитектуры.

Даниэль Приден
источник
«Если у вас есть программы, которые некорректно вставляют данные в вашу базу данных, эти программы повреждены и должны быть исправлены». в теории это тоже здорово, но реальность такова, что они все еще будут добавлять записи, в то время как некоторые комитеты продолжают спорить о том, использовать ли «NA» или «None».
JeffO
@JeffO: Ни один комитет не должен обсуждать, сохранять ли «NA», «None», NULL или что-то еще в базе данных. Нетехнические заинтересованные стороны заинтересованы в том, какие данные поступают из базы данных и как они используются, но не во внутреннем представлении.
Даниэль Приден
@DanielPryden: На моей последней работе у нас был Совет по пересмотру архитектуры (с подкомитетом DBA), который рассматривал междоменные технические изменения. Очень технически, но они встречались только каждые две недели, и если вы не предоставите им достаточно подробностей, они отложат решение до вашего ... на следующей встрече. Большинство нетривиальных системных изменений, которые не заключаются в добавлении функциональности через новый код, обычно занимают месяц или около того.
TMN
@DanielPryden - я сидел на совещаниях с высшим руководством, обсуждая ярлыки текстовых полей. Вы можете утверждать, что это не имеет никакого отношения к тому, что вы собираетесь назвать в приложении или базе данных, но это так.
JeffO
В ответ на комментарии о получении дополнительных одобрений для изменений такого рода: моя точка зрения о том, что значения являются «неправильными», предполагает, что допустимые значения уже где-то задокументированы - поэтому ОП говорит, что эти значения следует считать ошибкой. Если схема базы данных указана для разрешения значения, то это значение не является ошибкой. Дело в том, что если у вас есть данные, которые не соответствуют вашей схеме, то что-то не работает: ваш приоритет должен состоять в том, чтобы данные и схема соответствовали. В зависимости от команды, это может включать изменение данных, схемы или того и другого.
Даниэль Приден
2

« Есть ли какая-нибудь хорошая архитектура или принципы дизайна для обработки редких, но возможных нулевых записей? »

Простой ответ - да.

ETL

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

Как человек, который был одновременно браконьером (dev) и хранителем игр (DBA), я по горькому опыту знаю, что третьи стороны просто не решат свои проблемы с данными, если их не заставят. Постоянный изгиб назад и массирование данных через создает опасный прецедент.

Mart / Repository

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

Значения по умолчанию

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

Провалиться рано

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

Робби Ди
источник
+1 Это то, что я хотел бы сделать, собрать все данные и создать действительный набор данных для обработки вашего приложения.
Квеббл
1

Всякий раз, когда ваш вариант использования позволяет безопасно заменить NULL на хорошее значение по умолчанию, вы можете выполнить преобразование в SELECTоператорах Sql с помощью ISNULLили COALESCE. Так что вместо

 SELECT MyColumn FROM MyTable

можно написать

 SELECT ISNULL(MyColumn,DefaultValueForMyColumn) FROM MyTable

Конечно, это будет работать только тогда, когда ORM позволяет напрямую манипулировать операторами выбора или предоставлять изменяемые шаблоны для генерации. Следует убедиться, что никакие «реальные» ошибки не маскируются таким образом, поэтому применяйте его только в том случае, если замена значением по умолчанию - это именно то, что вам нужно в случае NULL.

Если вы можете изменить базу данных и схему, и ваша система БД поддерживает это, вы можете рассмотреть возможность добавления значения по умолчанию к определенным столбцам, как предложено @RobbieDee. Однако для этого также потребуется изменить существующие данные в базе данных, чтобы удалить все ранее вставленные значения NULL, и это впоследствии лишит возможности различать правильные и неполные данные импорта в дальнейшем.

Из своего собственного опыта я знаю, что использование ISNULL может работать на удивление хорошо - в прошлом мне приходилось поддерживать устаревшее приложение, в котором оригинальные разработчики забыли добавить ограничения NOT NULL для большого количества столбцов, и мы не могли легко добавить эти ограничения позже по некоторым причинам. Но в 99% всех случаев 0 по умолчанию для числовых столбцов и пустая строка по умолчанию для текстовых столбцов были полностью приемлемыми.

Док Браун
источник
Хотя это работает, вы можете в конечном итоге дублировать защитный код для каждого SELECT. Гораздо лучший подход заключается в определении значения по умолчанию для столбца, когда вставляется значение NULL, хотя это может быть невозможным / нежелательным по ряду причин.
Робби Ди
@RobbieDee: спасибо за это замечание, я изменил свой ответ соответственно. Однако, если это «намного лучше» спорно. Когда код CRUD находится в одном месте, дублирующийся защитный код не может быть большой проблемой. А если это не так, то уже есть некоторое дублирование кода заранее.
Док Браун
Простые операции CRUD, конечно, идеальны. Но в реальном мире системы часто имеют сложные представления пользовательского интерфейса, мастера создания данных, отчеты и т. Д. Но, как вы указали, значения по умолчанию должны присутствовать с нуля или, по крайней мере, требовать некоторого начального преобразования. То, что вы описали, может быть предпочтительнее при разработке месторождения.
Робби Ди
Лучший ответ. Новые приложения обычно добавляют новые данные, которые могут быть вне вашего контроля. Ошибочные значения NULL обычно возникают при импорте устаревших данных в переработанные базы данных. Для этого ограничения отключены, чтобы завершить его за несколько часов вместо нескольких дней. «Большой сбой» часто возникает, когда администраторы БД пытаются повторно включить ограничения. Так как это никогда не планировалось, руководство часто останавливается на тех неделях работы, которые часто требуются для исправления неверных данных, поэтому оно остается. Все приложения должны корректно обрабатывать значения NULL, вставляя значения по умолчанию и сообщая или запрашивая недостающие данные в противном случае.
DocSalvager
1

ОП предполагает ответ, который объединяет бизнес-правила с техническими деталями базы данных.

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

Это все бизнес-правила. Бизнес-правила не заботятся о нулевом per se. Всем известно, что база данных может иметь значение NULL, 9999, "BOO!" ... это просто другая ценность. То, что в СУБД null имеет интересные свойства, а уникальное использование является спорным.

Единственное, что имеет значение, это то, что означает «нулевое значение» для данного бизнес-объекта (ов) ...

Есть ли хорошая архитектура или принципы дизайна для обработки редких, но возможных нулевых записей?

Да.

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

Бросать исключение при извлечении данных не имеет смысла.

Вопрос в том, должен ли я хранить «плохие» данные? Это зависит:

  • Могут использоваться неверные данные - Никогда не сохраняйте недопустимые объекты или составные объекты. Сложные данные / деловые отношения повсюду. Пользователи могут выполнять любую функцию в любой момент времени, возможно, используя эту бизнес-сущность в нескольких контекстах. Эффект (если таковые имеются) плохих данных во время их сохранения неизвестен, поскольку они сильно зависят от будущего использования. Не существует единого / единого процесса для этих данных.
  • Не может прогрессировать, если есть плохие данные - Разрешить сохранение плохих данных. Однако следующий шаг в процессе не может продолжаться, пока все не будет действительным. Например, делать подоходный налог. При извлечении из базы данных программное обеспечение указывает на ошибки, и оно не может быть передано в IRS без проверки достоверности.
radarbob
источник
0

Существует множество способов обработки нулей, поэтому мы перейдем от уровня базы данных к уровню приложения.


Уровень базы данных

Вы можете запретить нули ; хотя тут это нецелесообразно.

Вы можете настроить значение по умолчанию для каждого столбца:

  • это требует, чтобы столбец отсутствовал в insert, поэтому не охватывает явную вставку нуля
  • это предотвращает обнаружение из строк, где insertошибочно пропущен этот столбец

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

  • это требует наличия необходимой информации для выполнения этого вычисления
  • это замедлит insert

Слой запроса

Вы можете пропустить строки, где присутствует неудобство null:

  • это упрощает основную логику
  • предотвращает обнаружение «плохих строк», поэтому для их проверки потребуется другой процесс
  • это требует, чтобы каждый запрос был инструментирован

Вы можете указать значение по умолчанию в запросе:

  • это упрощает основную логику
  • предотвращает обнаружение «плохих строк», поэтому для их проверки потребуется другой процесс
  • это требует, чтобы каждый запрос был инструментирован

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


Прикладной уровень

Вы можете предварительно проверить таблицу на запрещенное null:

  • это упрощает основную логику
  • это улучшает время до отказа
  • требуется постоянная логика предварительной проверки и применения

Вы можете прервать обработку при обнаружении запрещенного null:

  • избегает дублирования знаний о том, какие столбцы могут быть, nullа какие нет
  • это все еще относительно просто (просто чек + возврат / бросок)
  • это требует, чтобы ваш процесс был возобновляем (если вы уже отправили электронное письмо, не хотите отправлять его дважды или сто раз!)

Вы можете пропустить строку при встрече с запрещенным null:

  • избегает дублирования знаний о том, какие столбцы могут быть, nullа какие нет
  • это все еще относительно просто (просто чек + возврат / бросок)
  • это не требует, чтобы ваш процесс был возобновляемым

Вы можете отправить уведомление при обнаружении запрещенного null, либо по одному, либо в пакетном режиме, что дополняет другие способы, представленные выше. Однако наиболее важным является «что тогда?», В частности, если вы ожидаете, что строка будет исправлена ​​и вам потребуется повторная обработка, вам может потребоваться убедиться, что у вас есть какой-то способ отличить уже обработанные строки от строк, нуждающихся в перерабатывается.


Учитывая вашу ситуацию, я бы обработал ситуацию в приложении и комбинировал бы либо:

  • прервать и уведомить
  • пропустить и уведомить

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

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

В противном случае я бы использовал боковую таблицу для строк, которые должны быть исправлены (и повторно обработаны). Эта дополнительная таблица может быть либо простой ссылкой (без внешнего ключа), либо полной копией: последняя, ​​даже более дорогая, необходима, если у вас нет времени для обращения к ней nullперед очисткой основных данных.

Матье М.
источник
-1

Нули могут быть обработаны при переводе или отображении типов базы данных в языковые типы. Например, в C #, вот универсальный метод, который обрабатывает ноль для вас для любого типа:

public static T Convert<T>(object obj)
        {
            if (obj == DBNull.Value)
            {
                return default(T);
            }

            return (T) obj;
        }

public static T Convert<T>(object obj, T defaultValue)
        {
            if (obj == DBNull.Value)
            {
                T t = defaultValue;
                return t;
            }

            return (T) obj;
        }

Или, если вы хотите выполнить действие ...

 public static T Convert<T>(object obj, T defaultValue)
        {
            if (obj == DBNull.Value)
            {
                //Send an Alert, we might want pass in the name
                //of column or other details as well
                SendNullAlert();
                //Set it to default so we can keep processing
                T t = defaultValue;
                return t;
            }

            return (T) obj;
        }

И затем в сопоставлении, в данном случае с объектом типа «Образец», мы обработаем нуль для любого из столбцов:

public class SampleMapper : MapperBase<Sample>
    {
        private const string Id = "Id";
        private const string Name = "Name";
        private const string DataValue = "DataValue";
        private const string Created = "Created";

        protected override Sample Map(IDataRecord record)
        {
            return new Sample(
                Utility.Convert<Int64>(record[Id]),
                Utility.Convert<String>(record[Name]),
                Utility.Convert<Int32>(record[DataValue]),
                Utility.Convert<DateTime>(record[Created])
                );
        }
    }

Наконец, все классы сопоставления могут быть автоматически сгенерированы на основе задействованного запроса SQL или таблиц, просмотрев типы данных SQL и переведя их в типы данных для конкретного языка. Это то, что многие ORM делают для вас автоматически. Обратите внимание, что некоторые типы баз данных могут не иметь прямого сопоставления (геопространственные столбцы и т. Д.) И могут нуждаться в специальной обработке.

Джон Рейнор
источник
Если кто-то хочет опубликовать эквивалентную версию Java, это было бы здорово ...
Джон Рейнор
Я думаю, что пример кода вполне понятен и для разработчиков Java. В моей ситуации у меня уже есть ORM, поэтому не нужно его внедрять. Но ваш ответ касается только значений по умолчанию для нулей, тогда как в моем случае на самом деле гораздо более важный случай - обнаружение нуля и запуск действия (например, информирование администратора об ошибочных данных).
Jhyot
Аааа, я буду обновлять свой ответ на основе этого.
Джон Рейнор
Ваш отредактированный код теперь имеет одно действие по умолчанию для любого нулевого значения (т. Е. Оно полностью универсальное). Это очень похоже на мой второй вариант в исходном вопросе, то есть просто бросить на ноль и поймать его где-нибудь. Но, как указано там, мне нужно различать действия, основанные на том, какое значение отсутствует.
Джиот