Dígale al desarrollador que puede agregar esa lógica al código de la aplicación para evitar esas actualizaciones. Pero también que no vas a eliminar el DENY. Si / cuando llega el día (ytal vez noprobablemente no) que alguien reciba un error al intentar actualizar una de estas columnas, entonces puede tener una discusión sobre si eliminará o no DENY, lo que requerirá una justificación real y sólida de por qué alguien estaría actualizando ese valor en el primer lugar.
El punto es: debe haber un caso de negocios real que impulse lo que la gente pasa su tiempo. El tiempo es de gran demanda pero escaso, por lo que usted (y todos los demás) tienen cosas más importantes que hacer que cambiar el sistema según la opinión de alguien. Siempre habrá una variedad de opiniones (espacios frente a pestañas, ¿alguien?) Y podría pasar años cambiando esto de un lado a otro si ese desarrollador se va y es reemplazado por uno que se opone firmemente a que esos campos sean actualizables. Si ningún cliente está pidiendo esto (o algo que lo requiera), y no hay un beneficio tangible (incluso un beneficio retrasado, como la limpieza de la deuda técnica, que es difícil mostrar el ROI, pero vale la pena dado que el las posibilidades de que el tiempo empleado no resulte en un ahorro de costos real a largo plazo son escasas o nulas), luego, cierre la solicitud o póngala en la lista de pedidos de baja prioridad, incluso en los casos en que el idealismo dice que debe cambiarse (este no es uno de esos casos, pero se menciona para aquellos que piensan que sí). El idealismo es ideal para las conversaciones, pero las empresas no pueden pagar alquileres, servicios públicos, empleados, impuestos, etc. con ideales.
@ jpmc26 es correcto acerca de la necesidad de comunicación, pero no es exactamente correcto con respecto a lo que debe comunicarse. Sí, debe escuchar lo que otros solicitan y tratar de comprender su razonamiento, lo que incluye hacer preguntas si no tiene claro nada.
SIN EMBARGO, la base de datos no está subordinada a la aplicación, y los profesionales de la base de datos (administradores, ingenieros, cualquier nombre que use su empresa) no están subordinados a los desarrolladores (como parece estar implícito en esa respuesta). No trabajas para los desarrolladores, trabajas para la empresa, igual que ellos. Este es un esfuerzo de equipo y no debes pedir perdón por hacer tu trabajo. Dicho esto, nos computery tipos no son (en general) conocidos por nuestras habilidades de comunicación entre humanos, así, que realmente necesita para asegurarse de que otros entienden que , lo que su razonamiento es, cuáles son sus responsabilidades, y cómo estas cosas realmente funciona .
Puse esa última parte porque hay un alto grado de malentendidos, desinformación y falta de conocimiento (incluso algunos aquí en esta misma página). Por ejemplo, parece existir esta noción de que todas las reglas son reglas comerciales. Necesitamos explicar que hay una distinción entre las reglas de datos y las reglas comerciales (@Aaron se refirió a esto como "restricción de flujo de trabajo versus restricción de datos" en un comentario sobre la pregunta), y que si bien la mayoría de los datos pertenecen naturalmente a la aplicación, algunos datos en realidad pertenece al modelo de datos. ¿Debería un DBA dictar a los desarrolladores cómo se restringirán los datos de la aplicación ? Por supuesto no. Es nuestro trabajo ofrecer cómo los datos de la aplicación puedenestar limitado Si una violación de una regla comercial relacionada con los datos de la aplicación puede causar daños, y la aplicación no es la única forma 100% de manipular los datos, entonces tal vez una restricción de verificación realmente podría ayudar (y no son difíciles de cambiar o eliminar )
PERO, viniendo desde la otra dirección, los desarrolladores no deberían dictar cómo se manejan los datos del modelo de datos (es decir, los metadatos). Esto incluye campos de auditoría (como las columnas created_on/ created_by) y las columnas PK / FK (se supone que estos valores solo se conocen internamente y no se dan a los clientes). Estos datos no son lo que la aplicación almacena sobre los clientes (incluso si la aplicación puede ver los valores e incluso usarlos, como con ID), es lo que el modelo de datos almacena sobre los datos de la aplicación.
Por lo tanto, tiene sentido usar reglas de datos para proteger los datos del modelo de datos. Y hacerlo no implica que esté a punto de comenzar a agregar restricciones o restricciones en los datos de la aplicación. PERO, será difícil avanzar la conversación de una manera verdaderamente productiva si no se entiende esta distinción.