Реальные требования против требований бизнеса

Question

Допустим, у меня есть форма для создания учетной записи, которая заполняет базу данных пользователей.Допустим, эта таблица базы данных состоит из 6 столбцов: UserID, UserLogin, Password, Email, Demographic1, Demographic2.

Программа действительно требует UserID, UserLogin и Password.Это не может функционировать без.Остальные - «бизнес-требования», компания хотела бы знать эти вещи.Они «обязательны».

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

Моя интуиция говорит мне2-й вариант, но почти во всем производственном коде, который я видел, 1-й обычно имеет место.

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

Answer 1

Реальные требования для нас обычно относятся к Техническим требованиям, которые действительно необходимы для работы программы.Мы обычно применяем их в структурном проекте, таком как ограничение БД в вашем случае.

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

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

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

Надежда, которая помогает

Answer 2

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

1. База данных является вашей ссылкой. Это должно быть так же правильно, как возможный. Помещение ненулевых ограничений в базу данных помогает этому. Он обеспечивает соблюдение некоторых бизнес-правил, даже если это не фронт конец GUI, который вставляет данные, например массовые вставки из Пакетный или разработчик / DBA изменяя данные с помощью SQL, чтобы «исправить» проблема.
2. Это действительно помогает разработчику понять ограничения данных. Копаться в коде, чтобы выяснить, не может ли значение быть нулевым, иногда немного сложно, но посмотреть на БД легко. Точно так же, если вы создаете отчеты и знаете, что столбец не является нулевым, это становится проще.
3. Если вы ЗНАЕТЕ, что значение не должно быть нулевым, и если оно пустое, это ошибка, это допускает отказоустойчивое поведение. Если кто-либо вставит нулевое значение без прохождения бизнес-логики или из-за ошибки, то ошибка будет обнаружена быстрее, чем если бы вы допустили пустые значения в базе данных.

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

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

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

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

Answer 3

Иди за то, что ты считаешь лучшим; ВЫ являетесь программистом -> одна база данных с UserID, UserLogin и Password и связываете с ней другие базы данных.

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

Answer 4

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

Answer 5

Вы должны сделать оба.Заставьте базу данных потребовать этого и, если необходимо, обнулите исключение.Это так, что если вы когда-нибудь сделаете вставку / обновление sql, то это правило будет там.

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