2009-07-07 6 views
6

Editar: Cuando digo "SQL Server", realmente estoy hablando de Management Studio. Lo siento si eso fue confuso.SSMS permite registros duplicados en una tabla, pero no actualizaciones posteriores

Oh Odio cuando pasan cosas como esta. Ayer estaba trabajando con SQL Server y probando el comando PIVOT para intentar descubrir cómo funcionaba. Así que creé una nueva tabla con cuatro columnas, y la primera columna iba a tener el mismo valor para las primeras filas.

Agregué el "valor1" a la primera fila, primera columna, y presioné enter - sine no se agregaron claves o restricciones aún, me permitió ingresar a la siguiente fila con NULLs para las otras columnas en el primer fila (lo cual está bien). Para mi sorpresa, también me permitió ingresar "value1" en la segunda fila e ingresar down - esto debería ser imposible ya que ahora hay dos filas idénticas. Sin embargo, como solo estaba jugando, esto no me molestó. Así procedo a crear cuatro filas como tal:

Tabla 1

Col1  Col2  Col3  Col4 
--------------------------------- 
Value1  NULL  NULL  NULL 
Value1  NULL  NULL  NULL 
Value1  NULL  NULL  NULL 
Value1  NULL  NULL  NULL 

Obviamente esto es extraño y se rompe la teoría relacional, pero no me importó, ya que esto es sólo una tabla que he creado para perder el tiempo con. Sin embargo, casi me quité el pelo por lo que sucedió a continuación. Después de tener estos datos, no pude hacer nada en la tabla. Si traté de rellenar col2, col3 o col4 en cualquiera de las filas, SQL Server me gritaba por tener filas duplicadas: "No se actualizó ninguna fila. Los datos en la fila 1 no se confirmaron ... El valor de la fila (s) actualizadas o eliminadas, ya sea que no hagan que la fila sea única o alteran varias filas (4 filas) ".

En otras palabras, SQL Server me permitió ingresar en filas duplicadas, pero cuando traté de actualizar las filas para hacerlas únicas, no me lo permitió, citando que hay filas duplicadas como su razón. La peor parte es que ni siquiera podía eliminar ninguna fila (recibo el mismo mensaje de error). La única solución que encontré una vez en este escenario fue eliminar la tabla y comenzar de nuevo, lo cual es ridículo.

Mi pregunta es, ¿cómo puede existir este tipo de comportamiento en un programa bien conocido que ha evolucionado durante más de una década? ¿Soy yo el que no tiene cerebro y debería aceptar el comportamiento de SQL Server? Para mí esto es inaceptable y SQL Server nunca debería haberme permitido ingresar filas duplicadas, o debería haberme permitido actualizar las filas duplicadas hasta que fueran únicas y luego intentar guardarlas.

Esto de ninguna manera pretende ser algún tipo de publicación de odio de SQL Server. Es relativamente raro que me encuentre con un comportamiento como este, pero cuando lo hago, realmente me puede retrasar y volverme loco. Simplemente no entiendo por qué el programa tiene un comportamiento incorporado así. ¿Por qué en el mundo me permitió ingresar las filas duplicadas en primer lugar si no planeaba dejarme arreglarlo?

Recuerdo haber trabajado con MS Access durante el día y me encontraba con el mismo tipo de comportamiento extraño y arcaico. Algunas veces tuve que copiar enormes cantidades de datos, volver a crear la tabla y volver a copiarla solo porque Access me había permitido hacer algo que no debería tener, y ahora me está bloqueando cualquier cambio para solucionarlo. - produciendo efectivamente un punto muerto.

¿Qué está pasando aquí? ¿Necesito algún tipo de cambio de paradigma cuando me acerco a SQL Server? ¿Soy yo o SQL Server el problema? (Puede decir que soy yo, puedo aceptarlo)

Respuesta

9

Todo el estudio de administración que alguna vez tiene es una interfaz de usuario para crear SQL para usted y ejecutarlo contra la base de datos.

En su caso, cada vez que agregó una fila, produjo una instrucción INSERTAR. Esto es perfectamente válido.

Cuando intentó utilizar la interfaz de usuario para ELIMINAR o ACTUALIZAR un registro individual de todos estos registros duplicados, no pudo generar el SQL para hacerlo. La razón es que, como no había ninguna clave en la tabla, no hay forma de producir una cláusula WHERE que represente el registro que intentaba ACTUALIZAR o ELIMINAR.

Sus mensajes de "error" suenan perfectamente claros y válidos para mí.

En cuanto a su comentario:

Para mi sorpresa, sino que también me permitió introducir "valor1" en la segunda fila y entrar abajo - esto debería ser imposible ya que ahora hay dos idénticos filas Sin embargo, como estaba solo jugando, esto no me molestó.

Obviamente, esto es extraño y rompe teoría relacional, pero no lo hice realmente cuidado ya que esta es sólo una tabla que creado a perder el tiempo con.

No hay nada de malo en tener una tabla de base de datos que permita duplicados, es una cosa perfectamente válida que hacer si es lo que necesita. En cuanto a no "preocuparse" o "molestarse" por haber permitido duplicados. Ahí es donde yace el error. Es entonces cuando debería haberse dado cuenta de que olvidó agregar una clave principal.

+0

Gracias por explicar las razones detrás de permitir las inserciones pero no permitir las actualizaciones/eliminaciones. Esto fue muy útil. – JoeCool

+1

Ah, entiendo el mensaje de error mucho mejor ahora. Al principio pensé que el error era una realización latente de las filas duplicadas, como que SSMS era una especie de "despertar" y ver que si borraba una fila, habría tres duplicados todavía allí, y no podría permitir duplicados. Pero no, fue incapaz de eliminar la fila porque no sabía cuál de las cuatro eliminar. – JoeCool

1

El editor de registros en Sql Server Management Studio es una parte pequeña (y relativamente no importante) de la oferta de productos de SQL Server.Creo que puede aceptar las peculiaridades del editor sin preocuparse por la calidad relativa del servidor.

Detrás de escena, Management Studio está ejecutando sentencias SQL para realizar sus acciones, como si hubiera escrito ese SQL usted mismo. Entonces si rompes una regla, pagas la multa.

+0

Sí, creo que ese es mi problema. Me imagino en mi cabeza que SSMS está estrechamente relacionado con el servidor real, pero en realidad está enviando y recibiendo sentencias SQL como cualquier aplicación que escribo para mi base de datos. – JoeCool

1

Una peculiaridad sí, pero un defecto, no. Es perfectamente legítimo tener una tabla sin clave única, pero no es posible eliminar una fila de ella con el editor de tablas en SSMS (o Enterprise Manager antes) si hay filas idénticas.

No es el SSMS el que le permite crear las filas duplicadas, es usted el que lo permitió cuando creó su tabla sin clave principal. Siempre puede crear una columna de identidad de incremento automático que resolvería el problema.

No usaría el editor de tablas para este tipo de cosas, me gustaría crear guiones de instrucciones INSERT.

+0

Si SSMS le permite ingresar filas duplicadas, pero no eliminarlas, eso me parece sospechoso. No veo ninguna razón para permitir eso. En mi opinión, debería permitir ambos o ninguno. – JoeCool

+3

Pero un ELIMINAR FROM mytable sin una condición eliminará los registros, por lo que no es como si no tuviera una forma de eliminarlos. SSMS parece asumir un cierto nivel de competencia mínima; no necesariamente controlará todo por ti. Bienvenido a la programación. –

+2

Si agrega una clave principal, todo el problema desaparecerá. –

1

No estoy seguro de cómo esperaría que la herramienta supiera qué fila borrar si no tenía una clave única. ¿Le gustaría eliminar solo uno de los duplicados o ambos? si solo uno, ¿cuál es la clave que debería usar?

El estudio de administración es una herramienta . Su función no es hacer cumplir el diseño de tabla perfecto o la base de datos básica 101, que incluiría tener alguna clave única la mayoría de las veces. ¿Qué pasa si tienes algún modelo de negocio loco que requiere filas duplicadas? ¿No sería la queja entonces que la herramienta impidió roles duplicados?

En pocas palabras es 1.No debe editar ni eliminar datos con la herramienta de todos modos. Deberías escribir las declaraciones para la mayoría de las cosas.
2. Debería tener una clave única

No se puede culpar a ninguna herramienta por no tener esas cosas en su lugar.

+1

He escuchado esta declaración antes. Siempre debe usar scripts para todo y nunca use un editor. ¿Por qué es esto? ¿Masoquismo? –

+1

@Robert Harvey, sé que este es un comentario muy antiguo, pero las razones por las que debería usar scripts son: primero, la GUI a menudo hace las cosas de la manera más ineficiente causando bloqueos de tabla que no habrían sucedido si se usara un script. A continuación, todos los cambios en las bases de datos se deben programar y poner en control de origen para que tenga los scripts disponibles para ejecutar en otros entornos cuando sea el momento de pasar de dev a QA a prod. En tercer lugar, hay cosas que la GUI le dirá que no puede hacer, que son posibles si escribe el script SQL. – HLGEM

Cuestiones relacionadas