Создание «фиктивной записи», чтобы заставить базу данных подчиняться бизнес-логике, хорошая идея или глупая?

Question

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

До сих пор я видел его использование двумя способами:

• Добавляя поле наподобие IsDummy
• Добавляя поле с именем ObjectType, указывающее тип: Dummy

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

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

Так что вопрос: Является ли хорошей идеей создавать фиктивные записи, чтобы сохранить бизнес-логику такой, какой она есть, не заставляя Db жаловаться? Если да, что является лучшим способом запретить разработчикам пропускать свое существование? Если нет, что вы делаете, чтобы не попасть в ситуацию, когда у вас есть единственный вариант создания фиктивной записи?

Спасибо!

Answer 1

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

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

Answer 2

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

Любое хорошее определение или модель позволит легко вносить изменения, не «затрагивая существующий код».

Вся бизнес-логика [которая определена в базе данных] должна быть реализована с использованием ограничений, проверок и правил ANSI SQL. (Конечно, структуры нижнего уровня уже ограничены с помощью доменов / типов данных и т. Д., Но я бы не классифицировал их как «бизнес-правила».) Я гарантирую, что мне не придется реализовывать пустышки, просто делая это.

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

Мне никогда не требовалось нарушать такие ограничения или добавлять фиктивные записи (и я работал с огромным количеством баз данных). Я удалил фиктивные записи (и дубликаты), когда переработал базы данных, созданные другими.

Answer 3

Использование чайников глупо.

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

Answer 4

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

Answer 5

Единственная причина, по которой я вижу добавление «фиктивных» записей, - это когда у вас серьезно плохой дизайн приложения и базы данных.

Это определенно не обычная практика.

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

Answer 6

Правильным решением было бы обновить вашу бизнес-логику.

Чтобы процитировать ваше расширенное объяснение:

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

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

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

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

Answer 7

Я должен придерживаться здравого смысла и спорить с фиктивными записями.

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

Я испытал их в унаследованных базах данных и видел, как оба вышеперечисленных произошли.

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

Answer 8

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

Тот факт, что вы упоминаете «что указывает на тип:Пустышка "заставляет меня поверить, что вы используете какой-то ORM для обработки вашего доступа к данным.Очень хорошая контрольная точка (хотя и не единственная) для решений ORM, таких как NHibernate, заключается в том, что ваш исходный код ОЧЕНЬ ТОЧНО описывает структуры данных, которые определяют ваше приложение.Это не только позволяет легко управлять вашим доступом к данным под контролем исходного кода, но также упрощает отладку по линии в случае возникновения проблемы (и давайте посмотрим правде в глаза, дело не в том, ЕСЛИ проблема, а КОГДА).

Когда вы вводите какой-то «костыль», такой как фиктивная запись, вы игнорируете точку базы данных.База данных существует для обеспечения соблюдения правил в отношении ваших данных, чтобы устранить необходимость в подобных вещах.Я рекомендую вам сначала взглянуть на логику своего приложения, прежде чем прибегать к такой технике.Подумайте о своих коллегах или о новом найме.Что делать, если им нужно добавить функцию и забыть логику "фиктивной записи"?

Вы упоминаете себя в своем вопросе, чувствуя опасение.Иди со своей интуицией.Избавьтесь от фиктивных записей.