Я полностью согласен с @Aaron по техническим аспектам этого.
Принимая во внимание, что работа / ответственность администратора баз данных заключается в защите данных, подход по умолчанию должен состоять в том, чтобы делать именно это, как администратор базы данных считает целесообразным, и требовать веского экономического обоснования для внесения изменений. Гипотетический потенциальный будущий, несколько возможный, учитывая определенные условия, которые будут подвергнуты мозговому штурму, позже, и подтверждены, гораздо позже, но, может быть, изменились, позже или, возможно, никогда Фактически возникающая причина (то есть, «по какой-то причине») кажется немного неубедительной, особенно когда тема меняет стандарт / практику компании.
Никогда не доверяйте тому, кто хочет внести изменения в то, что никогда не должно меняться ;-), (даже более того, если они даже не знают, почему хотят).
Скажите разработчику, что он может добавить такую логику в код приложения, чтобы предотвратить эти обновления. Но также то, что вы не собираетесь удалять DENY
. Если / когда наступит деньможет невероятно, не будет) что кто-то получит ошибку при попытке обновить один из этих столбцов, тогда вы можете обсудить, удаляете ли вы или нет DENY
, что потребует фактического, веского обоснования того, почему кто-то будет обновлять это значение в первое место.
Суть в том, что должно быть реальное экономическое обоснование того, на что люди тратят свое время. Время пользуется большим спросом, но его не хватает, поэтому у вас (и у всех остальных) есть более важные дела, чем изменение системы на основе чьего-либо мнения. Всегда будут разные мнения (пробелы и вкладки, кто-нибудь?), И вы могли бы потратить годы, изменяя это взад и вперед, если этот разработчик уйдет и его заменит тот, кто решительно возражает против возможности обновления этих полей. Если ни один клиент не просит об этом (или что-то, что требует этого), и нет ощутимой выгоды (даже отсроченной выгоды, такой как очистка технического долга, что трудно показать окупаемость инвестиций, но оно того стоит, учитывая, что шансы того, что потраченное время не приведет к реальной экономии средств в долгосрочной перспективе, невелики), затем либо закройте запрос, либо поместите его в очередь с низким приоритетом, даже в тех случаях, когда идеализм говорит, что он должен быть изменен (это не один из тех случаев, но упоминается для тех, кто считает, что это так). Идеализм хорош для разговоров, но компании не могут платить идеалы за аренду, коммунальные услуги, сотрудников, налоги и т. Д.
@ jpmc26 правильно говорит о необходимости общения, но не совсем верно относительно того, что нужно сообщить. Да, вы должны прислушиваться к тому, что просят другие, и стремиться понять их аргументацию, которая включает в себя задание вопросов, если вам что-то неясно.
ОДНАКО база данных не подчиняется приложению, а специалисты по базам данных (администраторы, инженеры, независимо от того, какое имя использует ваша компания) не подчиняются разработчикам (как, по-видимому, подразумевается в этом ответе). Вы не работаете на разработчиков, вы работаете на компанию так же, как они. Это командная работа, и вы не должны просить прощения за свою работу. Тем не менее, мы, компьютерные типы, (в общем) не известны нашими навыками общения между людьми, поэтому вам действительно нужно убедиться, что другие понимают вас , каковы ваши рассуждения, каковы ваши обязанности и как эти вещи на самом деле работают ,
Я включил эту последнюю часть, потому что там есть высокая степень непонимания, дезинформации и недостатка знаний (даже некоторые прямо здесь, на этой самой странице). Например, кажется, существует понятие, что все правила являются бизнес-правилами. Нам нужно объяснить, что существует различие между правилами данных и бизнес-правилами (@Aaron в комментарии к вопросу назвал это «ограничение рабочего процесса против ограничения данных») и что большинство данных, естественно, принадлежит приложению, некоторые данные на самом деле принадлежит модели данных. Должен ли администратор БД диктовать разработчикам, как будут ограничены данные приложения ? Конечно нет. Наша задача - предложить, как данные приложения могутбыть ограниченным. Если нарушение бизнес-правила, связанного с данными приложения, может нанести вред, и приложение не является 100% -ным способом манипулирования данными, тогда, возможно, ограничение проверки может действительно помочь (и их нетрудно изменить или удалить). ).
НО, исходя из другого направления, разработчики не должны диктовать, как обрабатываются данные модели данных (т.е. метаданные). Это включает в себя поля аудита (например, столбцы created_on
/ created_by
) и столбцы PK / FK (предполагается, что эти значения известны только для внутреннего использования и не предоставляются клиентам). Эти данные не то, что приложение хранит о клиентах (даже если приложение может видеть значения и даже использовать их, например, с идентификаторами), это то, что модель данных хранит о данных приложения.
Поэтому имеет смысл использовать правила данных для защиты данных модели данных. И это не означает, что вы собираетесь начать добавлять ограничения или ограничения на данные приложения. НО, будет трудно продвинуть разговор действительно продуктивным способом, если это различие не понято.