Hola José:
"Claro, los UUID no son para que la gente se los acuerde, si no para el
funcionamiento de la aplicación."
Es correcto, pero cuando tengas interacción con el cliente, vas a terminar
haciendo la búsqueda por el documento, entonces, porque no hacerlo de una?
Gracias
Carlos
El 17/01/11 17:37, "José C. Massón" <jose@stripped> escribió:
>El 17/01/11 10:37, Carlos Barboni escribió:
>> José:
>>
>> Yo usaría el número de documento más un código (clave
> compuesta) para
>> indicar si es Pasaporte, etc.
>> Es lo más simple y lo que el cliente se suele acordar. De lo contrario,
>> siempre terminas haciendo una consulta por nombre porque nadie sabe su
>> número de id.
>> Saludos
>
>Hola Carlos,
>
>Claro, los UUID no son para que la gente se los acuerde, si no para el
>funcionamiento de la aplicación.
>El uso de UUID está bueno porque te asegurás que nunca (bah, es *muy*
>poco probable. Para eso se crearon) vas a tener ids duplicados. Y vas a
>poder usar el mismo tipo de id en todas las tablas del sistema.
>
>Luego, si querés buscar por documento, por nombre, o por lo que quieras,
>con tan sólo crear un índice por cada uno de esos campos listo.
>
>No había usado UUID antes de ponerme a trabajar con SugarCRM. Al
>principio pensé: "para que quiero este tipos de ids??" pero luego de un
>tiempo me dí cuenta de lo piola que está usarlos. Por otra parte como
>son 36 caracteres, se puede usar un tipo de campo char(36) lo cual
>insume un poco menos de espacio que un varchar(36)
>
>
>mis 2 centavos ;-)
>--
>José C. Massón
>
>gcoop - Cooperativa de Software Libre
>Velasco 508 Depto A
>www.gcoop.coop (+54 11) 4855-4390
>Buenos Aires - Argentina
