Vale, gracias a los dos,
Tenía pensado hacer la prueba, pero los resultados hay que explicarlos, así que también sumo las buenas explicaciones de Raul. Salu2 Omar De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Mariano Abdala Enviado el: Monday, December 10, 2007 12:52 AM Para: [EMAIL PROTECTED] Asunto: [dbms] varchar en primary key Omar, quizás más fácil e impactante que entregar documentación es hacer una pruba. Generá un ambiente lo más parecido posible al de tu cliente y duplicá las tablas, unas con int/guid de Pk y las otras con varchar. Después hacete dos SPs que hagan 1.000.000 operaciones de join, búsqueda, etc. De seguro los resultados en tiempo te den suficiente razón para el cambio. Saludos, Marino Abdala. From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Raul Gimenez Sent: domingo, 09 de diciembre de 2007 08:32 p.m. To: Mariano Abdala Subject: [dbms] varchar en primary key 1) El indice va a ocupar mas espacio y van a caber menos claves por pagina. Y mas espacio en disco, significa mas I/O, con lo cual, mas importante que ocupar espacio, perdes performance al tener que hacer mas operaciones en disco. 2) Se va a generar un monton de page split en el indice (y ni que hablar si el indice de la primary key es clustered, que es la opcion por default). Esto impacta tremendamente en la performance a la hora de los delete/update/insert, ya que tiene que ir moviendo paginas de datos. Ademas esto va a fragmentar la tabla o el indice, lo que te impacta a la hora de hacer consultas en disco. 3) Todos los indices NONCLUSTERED, ademas de tener los campos indexados, tienen como puntero la clave del indice CLUSTERED, por lo cual, si la primary key es varchar y clustered, este problema lo vas a arrastrar a todos los demas indices de la tabla. 4) Con los datos varchar, hay un pequeño overhead, ya que el SQL server tiene que guardar 2 bytes adicionales de offset para saber cuando termina el varchar. Con lo cual no solo en la tabla vas a tener este overhead, sino tambien en todos los indices de la tabla (si la PK es CLUSTERED, sino solo en el indice PK). 5) A nivel CPU, es mucho mas rapido resolver una busqueda de 4 bytes (un campo int), que un varchar. 6) Por ultimo y mas importante, QUE VENTAJAS HAY DE TENER UNA PK COMO VARCHAR????? El día 9/12/07, Omar del Valle Rodriguez <[EMAIL PROTECTED]> escribió: Hola gente, Tengo que presentarle a un cliente el por qué no es bueno tener relaciones entre tablas a partir de campos de tipo varchar. Los detalles técnicos los domino, pero quería encontrar alguna documentación más profesional, no importa que esté en ingles. Tendrían algún enlace en la web sobre el tema?. Entre los aspectos que creo en contra está el indexado de campos de tipo cadena, y el espacio a ocupar, si tienen algún aporte nuevo, igual se los voy a agradecer. Salu2 Omar __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/
