Como desventaja podes agregar que para acceder a campos de la clave natural, por ahi tenes que hacer joins, que si tuvieras una clave compuesta no serian necesarios:
Por ejemplo Facturas: Codigo de Proveedor + Factura Detalle Factura: Codigo de Proveedor + Factura + Producto Si uso solamente Id's como claves para llegar al numero de factura desde el detalle de la factura (o al proveedor), debo hacer un join con la tabla facturas si o si. Saludos!! ----- Original Message ----- From: "Esteban A. Zibecchi" <[EMAIL PROTECTED]> To: "dbms List Member" <[email protected]> Sent: Thursday, September 28, 2006 1:01 PM Subject: [dbms] GUID como primary keys Nuestra experiencia ha sido realmente muy buena. Te comento algunos puntos a favor y en contra que encontramos al usarlos Favor ----- * Cada tabla tiene una PK de un sólo campo y siempre del mismo tipo de dato * Los joins son más simples * Como la key no significa nada en el dominio, se pueden actualizar hasta campos no tradicionales como Cliente.Codigo * Como los GUIDs no se pueden repetir, la sincronización entre diferentes puntos se hace más simple. * Se pueden tomar secciones de una tabla para pasar a histórico y luego pueden volver a incluirse sin miedo a que cambien las PK * Las PK se pueden compartir entre diferentes aplicaciones. En Contra --------- * Ocupan más espacio que un Identity * Al hacer debugging es dificil seguir el rastro a las cosas ya que los IDs no significan nada (y encima andá a acordarte de alguno) Saludos Esteban -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dario Quintana Sent: Jueves, 28 de Septiembre de 2006 10:45 To: dbms List Member Subject: [dbms] GUID como primary keys Hola gente como están, estuve leyendo unos articulos pero me gustaría su opinión acerca de usar GUID como primary keys en todas las tablas de un db. El escenario es un esquema de sucursales y casa central. Saludos -- Dario Quintana dariodotnet.blogspot.com
