none
Bloquear registros en SQL SERVER 2016 developer RRS feed

  • Pregunta

  • Hola amigos. Me gustaría saber cómo puedo hacer para bloquear determinados registros (es decir filas) en una tabla de una base de datos. Muchas gracias de antemano

    Un saludo


    Carmen

    miércoles, 24 de agosto de 2016 9:56

Todas las respuestas

  • Hola, ¿a qué te refieres con 'bloquear'?
    miércoles, 24 de agosto de 2016 11:04
  • Nenufar,

    ¿Bloquear filas?

    ¿Te refieres a permisos? ¿Te refieres al manejo de concurrencia?

    Te sugiero agregar detalle a tu requerimiento.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    miércoles, 24 de agosto de 2016 16:44
  • Hola. Esto es una aclaración para Enric y Willams. Según la Ley de Protección de Datos, cuando tienes una base de datos con los datos de tus clientes, en el caso de que uno pida la baja, no puedes borrar sus datos sin más. Protección de Datos dice que tienes que 'bloquear' los datos de ese cliente. ¿Cómo tengo que hacer esto? Muchas gracias por vuestro interés

    Carmen

    jueves, 25 de agosto de 2016 8:11
  • Hola.

    Sugiero modificar el esquema de la tabla para agregar una columna que indique que dicho registro se dió de baja con una "B" y que está de alta con una "A", agregando también columnas tipo auditoría como la fecha de esta acción, quién la realizó y alguna razón en particular.

    Luego, para facilitar consultas o mantenimiento, puedes crear una partición en esa tabla por la columna, vamos a llamarla "Status".

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    jueves, 25 de agosto de 2016 10:30
  • Nenufar,

    Es bastante frecuente y parte de la funcionalidad de una aplicación -y no sólo por el tema de protección de datos- que la eliminación de las filas no sea física, se suele realizar un borrado lógico con una marca que define el estado de la fila, dependiendo del caso dichas filas se eliminan automáticamente pasado "n" días o nunca se eliminan (por configuración), la misma funcionalidad de una papelera de reciclaje.

    Para el caso de clientes, un cliente nunca debe de ser eliminado, y no sólo por el tema legal de protección de datos, un cliente tiene operaciones regadas en la empresa, esa información pertenece a la empresa es una locura desprenderse de dicha información. Los estados ALTA o BAJA es un atributo del cliente, un cliente de BAJA no tiene representación dentro del sistema, sin embargo ese cambio de estado no exige la eliminación ni lógica ni física de la base de datos. Pregunto ¿cuando anulas una factura lo borras de la tabla? no, ¿verdad?, es lo mismo, son sólo estados.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    • Propuesto como respuesta Laura CeglzModerator viernes, 2 de septiembre de 2016 16:09
    • Votado como útil Nenufar viernes, 9 de septiembre de 2016 7:32
    jueves, 25 de agosto de 2016 15:04
  • Saludos

    Me supongo que hablas de la normativa mexicana sobre proteccion de datos, no tengo un conocimiento fino pero si nos comportes el documento podriamos ver, si tienes 2016 puedes usar Row level security para ocultar los datos, aunque se me hace un poco raro el que te prohiban el borrado pues hasta donde tengo entendido a esto es a lo que te obliga la norma.

    jueves, 25 de agosto de 2016 15:13
  • Hola Nenufar

    Adicionalmente a la información proporcionada, es una buena práctica para facilitar la auditoría y la verificación adoptar un diseño que facilite esa funcionalidad. 

    Como lo han dicho algunos compañeros, en muy pocas situaciones se deben borrar registros físicamente. La estrategia frecuentemente correcta, es marcarlos como eliminados y excluirlos de las consultas convenientemente. Pero verificables a través de módulos de auditoría.

    En muchos escenarios, a los módulos de auditoría sólo acceden algunos usuarios con permisos especiales para realizar tareas sobre un conjunto de información determinado.

    Usted puede ir adoptando esa funcionalidad, pero si ya tiene un sistema bastante avanzado, hágalo con precaución. Debe hacer muchas pruebas.

    Saludos,


    Miguel Torres





    jueves, 25 de agosto de 2016 15:17
  • Hola muchas gracias por la información. Soy nueva en esto ¿A qué se refiere con lo de la partición, cómo puedo hacerlo? Muchas gracias de antemano

    Un saludo


    Carmen

    martes, 30 de agosto de 2016 9:28
  • Muchas gracias. Estoy de acuerdo en no eliminar el cliente. Soy nueva en esto. ¿Podrías explicarme cómo sería el procedimiento a seguir? Muchas gracias de antemano

    Un saludo


    Carmen

    martes, 30 de agosto de 2016 9:30
  • Hola. No, me refiero a la normativa de España, pero es igual. ¿Qué es eso de Row level security, pará qué se utiliza y cómo? Gracias de antemano

    Un saludo


    Carmen

    martes, 30 de agosto de 2016 9:32
  • Hola Miguel. Si, estoy de acuerdo con no borrar datos. Soy nueva en esto así que de momento la base que tengo no es real, sólo es una base de práctica en la que estoy experimentando antes de tener datos reales, por eso me interesa conocer bien el manejo. En mi caso no tengo intención de que la base sea accesible por otra persona que no sea yo. Y esto me lleva a la siguiente pregunta. En este caso ¿tiene algún sentido el crear vistas de mis tablas? Me gustaría que me explicaras el procedimiento a seguir y cómo proteger mi base de datos frente al acceso. Muchas gracias de antemano

    Un saludo


    Carmen

    martes, 30 de agosto de 2016 9:38
  • Hola muchas gracias por la información. Soy nueva en esto ¿A qué se refiere con lo de la partición, cómo puedo hacerlo? Muchas gracias de antemano

    Un saludo


    Carmen

    Hola Carmen.

    En teoría, es generar un subconjunto de datos de una entidad de acuerdo con algún criterio de un campo, por ejemplo, año, aunque también he visto que segmentan la tabla por algún rango particular, como montos de facturas o en algunos casos, por algún orden alfabético o numérico incluso.

    A mí me gusta la definición que de este concepto usan en la documentación de SQL Server 2008 R2 y también el consolidado que ofrece Brent Ozar en esta página Web. Ahí tienes para entender mejor el concepto y ver como usarlo, ya de acuerdo con lo que requieras o consideres.

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    martes, 30 de agosto de 2016 13:06
  • Saludos,

    Row lvl security es algo nuevo de la version 2016 (https://msdn.microsoft.com/en-us/library/dn765131.aspx), basicamente row level security lo que te permite es que ciertas personas o con ciertos permisos no puedan acceder a ciertas files de información.

    Por decir si haces un select * from table a estas personas y marcas ciertas rows como deshabilitadas no verian estos datos, esto te permite seguir la norma sin borrar los datos, la gran desventaja es que esto solo seria en version 2016.

    Otra opciones por permisos, negar selecta las tablas y usar vistas ya filtradas, seria el facil y menos intrusivo de los métodos.


    • Propuesto como respuesta Laura CeglzModerator viernes, 2 de septiembre de 2016 16:09
    • Editado Enrique AA viernes, 2 de septiembre de 2016 16:12
    • Votado como útil Nenufar viernes, 9 de septiembre de 2016 7:34
    martes, 30 de agosto de 2016 15:34
  • Hola de nuevo. He echado un vistazo al tema de las particiones y parece bastante complejo. ¿Són realmente necesarias? En mi caso la base de datos está pensada para que la utilice yo, no tengo intención de que sea accesible desde la web, no es algo que vaya a estar en línea. Me parece interesante lo de la columna status, pero creo que esto, al igual que cualquier otro método que vaya a emplear al final será algo que me vaya a servir a mí como indicativo para crearme quizá una vista en la que filtar sólo aquellos clientes que estén activos para enviarles el catálogo y cosas por el estilo ¿no? ¿Qué opina? ¿Gracias de antemano?

    Carmen

    martes, 6 de septiembre de 2016 9:48