Las aclaraciones estuvieron muy buenas.
 
Gente: El objetivo era discutir los GUID versus otras claves.
 
Mi comentario y que origino que nos fueramos por las ramas, no pasaba por el hecho de si el cliente era o no un atributo clave de la tupla, y evidentemente cuando vendo no lo es y cuando compro si. Pero de alli a usar una clave GUID estamos lejos de llegar a una conclusion unica.
 
No estoy sugiriendo usar Identity ya que no es necesario, lo importante aqui es si uso claes naturales o subrogadas en un sistema transaccional y si las claves alternativas a las naturales que son provistas por el sistema (codigos de las entidades) conviene que sean numeros enteros o GUID por ejemplo.
 
 
Saludos

--
--------------------------------
Atte.
Ing. Jose Mariano Alvarez
 
 
On 10/1/06, José Luis Agosta <[EMAIL PROTECTED]> wrote:

Hola.

aporto mi comentario, con respecto a la memoria fiscal cuando se lleno una memoria, cambia el puesto de trabajo y pasa a ser un numero mas del ultimo puesto que tenga la empresa, por ejemplo si la empresa tiene una sola impresora fiscal el puesto seria 0002, ya que 0001 es para facturas manuales, y si tiene mas de una impresora fiscal es 0003, 0004 y así sucesivamente, y si se lleno la memoria pasaría a ser un nuevo puesto, en el caso de una sola impresora seria 0003, con respecto al proveedor yo utilizo para validar que no se repitan los numero de factura   el código de proveedor+el numero de puesto+ el numero de factura, o sea el proveedor 0001 numero de factura completo es 0002-00022330 la búsqueda seria así 0001000200022330, y nunca falla.

 

Atte, José Luis Agosta

 


De: [email protected] [mailto:[email protected]] En nombre de Julio.Novomisky.Mug
Enviado el: Sábado, 30 de Septiembre de 2006 17:35
Para: dbms List Member
Asunto: [dbms] GUID como primary keys

 

Alejandro

Luis no necesita quien lo patrocine o lo defienda

Pero te diría que releas los mails, porque los dos números 1 son de proveedores, y si dos proveedores te pueden dar el mismo numero de factura

Julio

 


From: [email protected] [mailto: [email protected]] On Behalf Of Alejandro David Nelis Robles (GUFA)
Sent: Sábado, 30 de Septiembre de 2006 04:42 p.m.
To: dbms List Member
Subject: [dbms] GUID como primary keys

Lamento contarles que es falso el tema de emitir dos facturas con el mismo número de factura al vender, si tienen impresoras fiscales el número de factura si se repite ya que al dar de baja la memoria fiscal y darla de alta (cuando se agoto) empieza desde el número 1 de nuevo as que tu teoría se rompe, espero que esto te ayude.

 

Alejandro David Nelis Robles
Socio MUG 1703

----- Original Message -----

From: Luis Musa

Sent: Friday, September 29, 2006 11:14 AM

Subject: [dbms] GUID como primary keys

 

Cambia si es proveedor o cliente.... si es un proveedor me DEBE aceptar el mismo numero de factura para 2 proveedores distintos... vos y yo alguna vez tuvimos la factura numero 1 y podemos ser proveedores de la misma empresa, no? Entonces le podriamos dado los 2 esa # de factura a la misma empresa? Y esa empresa debe registrar en un iva compras por ejemplo las facturas de los proveedores... entonces en un sistema de proveedores, el proveedor tiene que ir en la clave. Si es un sistema de clientes no iria en la clave, porque yo no puedo emitir 2 veces el mismo numero de factura.

 

Saludos!!!

----- Original Message -----

Sent: Friday, September 29, 2006 10:22 AM

Subject: [dbms] GUID como primary keys

 

Mi objecion no es por si una factuira corresponde a un proveedor. Cambia cliente por proveedor y la pregunta sigue siendo la misma.-

 

Tu dices que usarias una PK de factura que incluya el numero de Cliente?

O sea que si hay un error en el sistema o en algun proceso que modifica datos o cualquier cosa que se te ocurra (buena o mala), la tabla podra aceptar perfectamente debido a tu modelo de datos el mismo numero de factura para dos clientes distintos?

 

Saludos

 



 

On 9/29/06, Luis Musa < [EMAIL PROTECTED]> wrote:

Jeje... estaba pensando en un sistema de proveedores, lo que pasa es que omiti ponerlo en el ejemplo... igual creo que lei mal el motivo de la discusion... saludos!!!

----- Original Message -----

Sent: Thursday, September 28, 2006 7:04 PM

Subject: [dbms] GUID como primary keys


 

Va de nuevo

 

 

Podrias explicarte mejor.

 

Tu dices que usarias una PK de factura que incluya el numero de proveedor?

O sea que si hay un error en el sistema o en algun proceso que modifica datos o cualquier cosa que se te ocurra (buena o mala), la tabla podra aceptar perfectamente debido a tu modelo de datos el mismo numero de factura para dos clientes distintos?

 

Saludos



 

On 9/28/06, Luis Musa < [EMAIL PROTECTED]> wrote:

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!!



--
--------------------------------
Atte.
Ing. Jose Mariano Alvarez




--
--------------------------------
Atte.
Ing. Jose Mariano Alvarez



__________ Información de NOD32, revisión 1.1784 (20060929) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com


--
S.J.L. Soft Computación, utiliza software original.
Se certificó que el correo Entrante no contiene virus.
Verificado por Anti-Virus AVG.
Versión: 7.1.407 / Base de datos de virus: 268.12.10 /459 - Fecha de la versión: 29/09/2006


--
S.J.L. Soft Computación, utiliza software original.
Se certificó que el correo Saliente no contiene virus.
Verificado por Anti-Virus AVG.
Versión: 7.1.407 / Base de datos de virus: 268.12.10 /459 - Fecha de la versión: 29/09/2006



Responder a