Cómo agregar una lista de claves externas dentro de un servidor sql de columna

Tengo un modelo de comentario que tiene un "Id. de propietario", que es la persona que lo creó y los usuarios tienen la opción de indicar que les gusta/no les gusta un comentario y realizar un seguimiento de cuánto les gustó/no les gustó un comentario. Creo que necesito una lista de claves foráneas. También existe la opción de hacer otra tabla con la identificación del comentario y la identificación del usuario, pero ¿no es esto peor?

Answer

Como algunos dijeron?

NO intente modificar esto almacenando múltiples valores en una columna. Parece una gran idea, pero REALMENTE pierde todas y cada una de las habilidades para permitir lo hermoso que hemos llamado una base de datos relacional.

Muerde la bala: toma esa taza de café y hazlo bien.

Entonces, crea una nueva tabla. Esa tabla es una lista de comentarios votados. MUCHO mejor es que ahora puedes usar sql para:

  • Haga que el usuario actual vote (hacia arriba o hacia abajo): es fácil dejar que cambien.

  • Obtenga el número total de votos (hacia arriba o hacia abajo) con la consulta sql

  • Agregue y amplíe fácilmente el diseño: diga la fecha en que se votó hacia arriba o hacia abajo.

La lista anterior podría ser más larga, pero en realidad, incluso cuando muestra los comentarios, sin duda desea mostrar la elección de los usuarios ACTUALES (o tal vez no tengan otra opción, pero esas operaciones serán UN registro, y puede cambie el voto a favor, el voto a favor y, como se indicó, tal vez incluso guarde la fecha en que el usuario hizo esto.

Va a ser una mesa sencilla. Di así:

ingrese la descripción de la imagen aquí Quiero decir, ¿solo para contar los votos positivos, solo para editar y guardar?

Todo esto se convertirá en operaciones de datos de plane jane.

¿Intentas meter en una columna todas esas identificaciones? Ahora tiene que analizar, buscar la identificación única, tal vez no encontrada. Y luego, ¿qué tal una consulta simple para mostrar los votos positivos y negativos? De nuevo, desordenado.

Si esto fuera un xml, o incluso una base de datos json (no-sql), entonces tal vez esté bien.

Pero, si esta es una base de datos sql? Entonces haz esto de la manera correcta. Me encantan las bases de datos json o incluso xml, pero ¿en sql land?

Hacer como lo hacen en Roma, y ​​en este caso?

¡Haz lo que hacen en el país de sql land!

Editar: el problema de eliminación en cascada de la tabla de votos ascendentes del usuario

Ok, tenemos un problema de seguimiento.

Supongamos que tenemos esta configuración.

Tengo Usuarios->comentarios->votos a favor.

Entonces cada tabla es un hijo de la anterior.

Entonces, si eliminamos comentarios, eliminamos votos en cascada

Entonces, si eliminamos un usuario, eliminamos en cascada los comentarios, que a su vez eliminarán los votos en cascada.

PERO TAMBIÉN queremos eliminar en cascada los votos de un usuario determinado, incluso si nunca hizo un comentario, aún podría tener muchos votos a favor.

Entonces, supongamos que tenemos la primera parte: ahora tenemos 3 tablas como esta:

ingrese la descripción de la imagen aquí

Entonces, cada tabla secundaria (comenzando en el lado izquierdo - usuarios), se eliminará en cascada.

Ahora, nuestro último número. PODRÍAMOS y PODEMOS hacer cumplir la integridad reverencial cuando agregamos un registro de votación, ese ID de usuario DEBE existir.

Ahora, diría que es imposible equivocarse, ya que si un usuario va a votar, entonces DEBE existir, ¿verdad?

Por lo tanto, TODAVÍA podemos, sin embargo, hacer cumplir lo anterior, y por el bien de la documentación, deberíamos hacerlo.

¡¡¡SIN EMBARGO!!! - NO podemos activar la eliminación en cascada. Primero hagamos cumplir esta regla, y ahora tenemos esto:

ingrese la descripción de la imagen aquí Por lo tanto, podemos hacer cumplir esta regla, pero NO podemos configurar la eliminación en cascada aquí.

¿Por qué?

Bueno, cuando eliminas un usuario, eliminamos en cascada ->comentarios->votos

Pero, TAMBIÉN podemos eliminar en cascada de usuarios->votos. ¡Entonces, dos operaciones pueden caer en cascada a la MISMA tabla!

Esto SOLO ocurriría en el caso de que un usuario hiciera un comentario y TAMBIÉN votara a favor de su propio comentario. Es posible que esto no esté permitido, pero el servidor SQL no lo sabe.

Por lo tanto, dos eliminaciones potenciales no solo podrían ocurrir en la misma tabla, sino que, de hecho, ¡INCLUSO en el mismo registro!

Desafortunadamente, el servidor SQL NO permite lo anterior. (y creo que debería!!!).

MS-Access permite esto, pero no es una base de datos 100% "ACID". Y qué pasa si eliminamos algunos votos eliminando al usuario y la cascada proviene de la tabla de comentarios, Y LUEGO se dispara la cascada de usuarios->votos.

No tengo experiencia con, por ejemplo, Oracle o MySQL para saber si esto está permitido, pero NO está permitido con el servidor SQL. (otra vez: creo que debería serlo). Sospecho que dado que cada operación tiene que ser "distinta" y también ejecutarse como subprocesos separados para el rendimiento, ahora tendríamos dos cascadas en las operaciones que potencialmente podrían eliminar el mismo registro.

¿La única solución práctica entonces?

Debe agregar un disparador de eliminación al evento de eliminación de usuario. Cuando elimina, lo deja en cascada y ENTONCES tendrá que ejecutar una consulta para eliminar todos los votos que pertenecen al usuario.

Ahora también podrías hacer esto al revés. Ponga un activador en la tabla Comentarios para eliminar votos y luego una eliminación en cascada de usuarios->votos.

Creo que es mejor hacer que tblComments elimine los votos, y luego ejecuta ese activador para la tabla de usuarios->votos.

Como se señaló, no se permite tener las dos cascadas que finalmente se resuelven en la misma tabla DESDE UNO, y el servidor sql arrojará un mensaje que dice:

Unable to create relationship 'FK_tblCommentVotes_Users'.
Introducing FOREIGN KEY constraint 'FK_tblCommentVotes_Users' on table 'tblCommentVotes' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. Could not create constraint or index.

La parte crítica de arriba es esta:

puede causar ciclos o múltiples rutas en cascada.

así que ese mensaje de error es, en pocas palabras, exactamente el mismo problema que describí aquí en mi narración: existe más de una ruta a una eliminación en cascada desde una misma tabla principal posible.