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

Question

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

Пока что я видел его использование в 2 способах:

• Добавив поле, как iSstummy
• Добавив поле что-то под названием ObjectType, то указывает на тип: манекен

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

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

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

Спасибо!

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

Тот факт, что вы упомянуте «какие точки типа: манекен» ведет меня полагать, что вы используете какой-то ORM для обработки ваших данных. Очень хороший контрольно-пропускной пункт (хотя не только) для решений ORM, такие как NHIBERNATE, заключается в том, что ваш исходный код очень явно описывает ваши структуры данных, управляя вашим приложением. Это не только позволяет легко управлять вашим доступом к контролю источника, но он также позволяет легче отладки вниз по линии, если проблема возникнет (и рассмотрим ее, это не вопрос, если проблема возникнет, но когда).

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

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

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