Tabla sin clave primaria

29/09/2005 - 12:17 por Elena | Informe spam
Buenas,

tengo una base de datos con una tabla ControlAcceso donde se van almacenando
los accesos de los usuarios a la base de datos tanto consulta, inserción,
modificación, eliminación. Por lo que está continuamente creciendo. Los
campos son:
Usuario
Fecha
Tabla
TipoAcceso
Registro
Acceso
Motivo

¿puede haber algún problema si esta tabla no tiene clave primaria? es una
tabla sin ninguna restricción y ninguna relación. ¿Puede que relantice la
aplicación?

Gracias

Preguntas similare

Leer las respuestas

#1 Carlos Sacristán
29/09/2005 - 12:49 | Informe spam
Aparte de que viola las reglas de normalización de base de datos
relacionales, si nos centramos en SQL Server, es muy recomendable que toda
tabla tenga siempre clave primaria. En tu caso, una buena candidata sería la
que compondrían los campos Usuario + Fecha


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Elena" escribió en el mensaje
news:
Buenas,

tengo una base de datos con una tabla ControlAcceso donde se van


almacenando
los accesos de los usuarios a la base de datos tanto consulta, inserción,
modificación, eliminación. Por lo que está continuamente creciendo. Los
campos son:
Usuario
Fecha
Tabla
TipoAcceso
Registro
Acceso
Motivo

¿puede haber algún problema si esta tabla no tiene clave primaria? es una
tabla sin ninguna restricción y ninguna relación. ¿Puede que relantice la
aplicación?

Gracias


Respuesta Responder a este mensaje
#2 Maxi
29/09/2005 - 14:17 | Informe spam
Hola amigo!! mmm dejame discrepar un poco contigo!! que sucede si tenemos
muchos usuarios y con el mismo nombre de usuario en distintos equipos y en
el mismo instante se realiza una accion? daria un error de PK porque estamos
asumiento que Usuario + Fecha es unico!!

En estos casos (tipo de tabla y para lo cual esta pensada) yo recomiendo
usar un identity como PK y luego los indices que necesite!!


Salu2
Maxi


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
Aparte de que viola las reglas de normalización de base de datos
relacionales, si nos centramos en SQL Server, es muy recomendable que toda
tabla tenga siempre clave primaria. En tu caso, una buena candidata sería
la
que compondrían los campos Usuario + Fecha


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Elena" escribió en el mensaje
news:
Buenas,

tengo una base de datos con una tabla ControlAcceso donde se van


almacenando
los accesos de los usuarios a la base de datos tanto consulta, inserción,
modificación, eliminación. Por lo que está continuamente creciendo. Los
campos son:
Usuario
Fecha
Tabla
TipoAcceso
Registro
Acceso
Motivo

¿puede haber algún problema si esta tabla no tiene clave primaria? es una
tabla sin ninguna restricción y ninguna relación. ¿Puede que relantice la
aplicación?

Gracias






Respuesta Responder a este mensaje
#3 Carlos Sacristán
29/09/2005 - 15:02 | Informe spam
Sí, podríamos encontrarnos en esa situación, por eso dije que una buena
candidata sería Usuario + Fecha, porque sobreentendía que "Usuario" es un
login único y que por tanto no habría problemas con la fecha, pero no dije
que tuviera que poner esa ni que fuera la única. Está claro que no conozco
los requisitos de la aplicación para poder seleccionar los campos de la
clave

Ahora, que si es por discrepar, discrepemos entonces ;-)


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Maxi" escribió en el mensaje
news:#wg3$$
Hola amigo!! mmm dejame discrepar un poco contigo!! que sucede si tenemos
muchos usuarios y con el mismo nombre de usuario en distintos equipos y en
el mismo instante se realiza una accion? daria un error de PK porque


estamos
asumiento que Usuario + Fecha es unico!!

En estos casos (tipo de tabla y para lo cual esta pensada) yo recomiendo
usar un identity como PK y luego los indices que necesite!!


Salu2
Maxi


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Aparte de que viola las reglas de normalización de base de datos
> relacionales, si nos centramos en SQL Server, es muy recomendable que


toda
> tabla tenga siempre clave primaria. En tu caso, una buena candidata


sería
> la
> que compondrían los campos Usuario + Fecha
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Elena" escribió en el mensaje
> news:
>> Buenas,
>>
>> tengo una base de datos con una tabla ControlAcceso donde se van
> almacenando
>> los accesos de los usuarios a la base de datos tanto consulta,


inserción,
>> modificación, eliminación. Por lo que está continuamente creciendo. Los
>> campos son:
>> Usuario
>> Fecha
>> Tabla
>> TipoAcceso
>> Registro
>> Acceso
>> Motivo
>>
>> ¿puede haber algún problema si esta tabla no tiene clave primaria? es


una
>> tabla sin ninguna restricción y ninguna relación. ¿Puede que relantice


la
>> aplicación?
>>
>> Gracias
>>
>>
>
>


Respuesta Responder a este mensaje
#4 Alejandro Mesa
29/09/2005 - 15:26 | Informe spam
Maxi,

Hola amigo!! mmm dejame discrepar un poco contigo!! que sucede si tenemos
muchos usuarios y con el mismo nombre de usuario en distintos equipos y en
el mismo instante se realiza una accion?



En ese caso recomendaria rediseñar la aplicacion o arquitectura. Es como las
aplicaciones que usan un unico usuario para realizar toda operacion sobre la
base de datos. Lo he visto mucho, por ejemplo usan "sa" y su password en la
cadena de conecccion. La teoria de base de datos relacionales (aunque esta no
se considere perfecta por muchos contrarios) se basa principalmente en la
existencia de una clave natural que identifique unicamente las ocurrencias de
una cierta entidad. No dejo de reconenocer que el uso de una columna con
propiedad identity es muy practico en muchos de estos estos casos, pero el
problema esta mas alla de su uso. Por ejemplo, habria que ver si un mismo
usuario puede ejecutar una misma accion sobre una misma tabla, en un mismo
hilo y al mismo tiempo?. Yo por mi parte no recomiendo el uso de columnas
datetime como parte de una clave primaria, puesto que este tipo de datos es
mantenido por sql server con una exactitud de 1/300 del segundo (0.00333) y
por lo tanto valores diferentes pueden ser almacenados como si fuesen iguales.

Ejemplo:

select
cast('2005-09-29T09:02:45.003' as datetime),
cast('2005-09-29T09:02:45.004' as datetime)

Yo preferiria buscar una columna(s) que nos permita ordenar las acciones
cronologicamente. De ser cierto que el mismo usuario puede ejecutar la misma
accion sobre la misma tabla, en el mismo hilo e instante, entonces la columna
con propiedad identity no nos ayudaria puesto que sql server asignaria
valores diferentes a ambas acciones y en realidad no sabriamos que estas
ocurrieron en el mismo instante, nos pareceria como que una se ejecuto
primero que la otra. Pudieramos adicionar el nombre de la maquina y quizas
hasta un numero (no se si este existe) indicando el hilo o posiblemente el
spid en el cual se ejecuta la accion, entonces ya podemos hacer un analizis
mas exhausto (corriganme esta palabra) de la data.

Otra cosa que si recomendaria es crear un indice clustered. Aca adjunto un
link donde podemos leer por que esto es importante.

Cluster That Index!
http://www.quest-pipelines.com/news...1103_B.htm

Cual(es) columna(s) usar para el indice clustered?, bueno, eso se lo dejo a
quien desarrolla la aplicacion, creo que solo el sabe que columnas seran
usadas en consultas de rango, group by, etc., o si es mas importante que las
inserciones se hagan de una forma monolitica para evitar division de las
paginas (page split) y para lo cual la columna con propiedad identity viene
como anillo al dedo.

Ahora tengo una pregunta para Elena, y esta es:

Cual es el uso que le daras a esta tabla?


AMB



"Maxi" wrote:

Hola amigo!! mmm dejame discrepar un poco contigo!! que sucede si tenemos
muchos usuarios y con el mismo nombre de usuario en distintos equipos y en
el mismo instante se realiza una accion? daria un error de PK porque estamos
asumiento que Usuario + Fecha es unico!!

En estos casos (tipo de tabla y para lo cual esta pensada) yo recomiendo
usar un identity como PK y luego los indices que necesite!!


Salu2
Maxi


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Aparte de que viola las reglas de normalización de base de datos
> relacionales, si nos centramos en SQL Server, es muy recomendable que toda
> tabla tenga siempre clave primaria. En tu caso, una buena candidata sería
> la
> que compondrían los campos Usuario + Fecha
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Elena" escribió en el mensaje
> news:
>> Buenas,
>>
>> tengo una base de datos con una tabla ControlAcceso donde se van
> almacenando
>> los accesos de los usuarios a la base de datos tanto consulta, inserción,
>> modificación, eliminación. Por lo que está continuamente creciendo. Los
>> campos son:
>> Usuario
>> Fecha
>> Tabla
>> TipoAcceso
>> Registro
>> Acceso
>> Motivo
>>
>> ¿puede haber algún problema si esta tabla no tiene clave primaria? es una
>> tabla sin ninguna restricción y ninguna relación. ¿Puede que relantice la
>> aplicación?
>>
>> Gracias
>>
>>
>
>



Respuesta Responder a este mensaje
#5 yodelmis
29/09/2005 - 20:54 | Informe spam
AMIGO ALEJANDRO
SOY DE LOS QUE TIENE UNA APLIACCION DONDE TODOS LOS USUARIOS SE
CONECTAN COMO SA Y ME HA PREOCUPADO LO QUE COMENTAS SOBRE LOS QUE
UTILIZAMOS ESTE METODO.
¿PODRIAS ACLARAR ESTO.?

VER
http://groups.google.com/group/micr...f87c6d2952
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida