Campos Autoincrementales ó tabla con campos para numerar

[Marcelo Juárez]

Estimados Colegas: Se me planteó la duda de que es más eficiente, agregar en las tablas campos autoincrementales o bien recurrir a una tabla donde tenemos los campos clave que queremos ir numerando. ¿Es más lento el acceso a la tabla usando campo autoincremental que sin el mismo? ¿y en Bases de datos como MySQL es lo mismo?

Gracias por sus comentarios..

[Carlos Miguel FARIAS]

Tu consulta en parte se explica en:

http://www.forosdelweb.com/f21/utilizar-int-varchar-claves-1028448/

y como se instrumentan en diferentes SGBD

https://en.wikibooks.org/wiki/SQL_Dialects_Reference/Data_structure_definition/Auto-increment_column

curiosamente, ORACLE, posiblemente el SGBD más avanzado, lo construye en forma compleja (crea un serial y luego lo asocia mediante un trigger).

Acá alguien le "pega" a los AI

Si lees otros post del foro, se discutió (PK war, AI War) sobre el tema.

En el caso de mysql, es preferible usar GUID antes que AI

ver4: http://stackoverflow.com/questions/30461895/the-differences-between-int-and-uuid-in-mysql

Un artículo interesante es: https://bmegias.wordpress.com/2011/01/31/%C2%BFclaves-primarias-naturales-o-subrogadas/

Y pueden bajarse el libro (en ingles) SQL Antipatterns. Léanlo y compréndanlo.

En él podrán ver explicado con ejemplos que es lo que corresponde en cada caso.

Cabeza dura yo, sigo prefiriendo mis claves calculadas a partir de datos de quien, cuando, donde sobre los autoincrementales (las GUID son buenas pero muy grandes, nunca las usé).

He usado naturales y AI y los AI los reemplacé por PK = F(who, when, where)

Se aceptan zanahorias de donación.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, KCC o KPC o a la inversa (aunque no es viernes, de vacaciones)

[Antonio Meza]

Antes que nada debes tener bien claro para que son los campos Autoincrementables, ya que si no entiendes su propósito real te confundirás en el camino como le pasa a la mayoría de los programadores y terminan despreciando esta nativa función de los servidores de base de datos, encontraras debates y debates de su uso, pero realmente no hay un debate solo hay desconocimiento generalizado.

En cuanto a usar autoincremetnables en tablas de VFP ya no las use, lo que si recuerdo es que tienen un problema que no recuerdo de momento y por ello no los use, pero en un servidor de base de datos son lo máximo para cumplir su función, como te dije al principio si no la tienes clara te confundirás y te confundirán.

En base de datos RELACIONALES como es el caso de Mysql, FireBird, MariaDb, SqlServer, PostGreSql, etc, debes usar normalizacion si o si al menos las 3 primeras Formas Normales, esto te permitirá generar reportes y todo tipo de consulta sin problema, el no cumplir estas 3FN lo pagaras en los reportes y consultas, para prueba de ello aquí en este foro es de todos los días que quieren sacar un reporte con tablas que no cumplen las 3FN en su diseño y ahí se complica todo.

La mayoría de los programadores se van por el camino fácil (eso creen los ilusos jeje) para que la interface (formularios) les sea mas sencilla de diseñar y la base de datos la dejan en segundo o tercer plano, pero al final el precio lo pagan caro en las consultas o reportes incluso al ampliar algo en la base de datos, un buen programador es aquel que enfoca el problema partiendo del diseño de la base de datos, de ahí lo demás es fácil.

En lo personal te recomiendo los autoincrementables para lo que fueron diseñados y nada mas para ello no para otras cosas que muchos hacen y que se puede pero no se debe, de ahí la confusión, es decir un campo PK (Primary Key) que identifique de forma inequívoca un registro en una tabla, que te permitirá relacionar de forma sencilla con otras tablas, y que te permitirá Actualizar (Update), Eliminar (Delete) y consultar en algunos casos (Select) sin problema alguno.

Los PK autoincrementables JAMAS, de los JAMAS, NUNCA, se le deben mostrar al usuario ya que su uso es exclusivo del diseño de la base de datos y del programador, para el usuario se deben guardar campos que el reconozca en su vida cotidiana como DNI, etc, 

A caso han visto su Campo ID (Autonumetico PK o autogenerados) en la pagina de Facebook, en el portal de tu Banco? en tus usuarios de los diferentes correos de GMAIL, Outlook, verdad que no los muestran? y es mas que nada por seguridad de la propia base de datos.

En conclusión los campos Primary Key Autoincrementables son lo mejor que puedes usar solo para identificar un registro en una tabla de forma inequívoca, relacionarlo con otras tablas, actualizarlo, eliminarlo y en ocasiones consultarlo cuando conoces su valor y si la memoria no me falla nada mas para eso.

Usar campos UUID, campos combinados o definidos y creados por el programador como Primary Key es simplemente desconocimiento del significado de una llave primaria, pues el programador es el encargado de armarlos y los autoincrementables lo hace el propio servidor de base de datos por lo que no hay que preocuparse mas que de obtenerlo cuando lo genera el servidor y el campo combinado o definido por el programador lo tienes que crear y validar.

Un ejemplo sencillo de controversias igual que pasan con los autoincrementables son el uso de las variables Publicas, la mayoría las usa porque así les enseñaron o porque así es mas fácil programar (eso creen) , los buenos programadores NO las usamos (jejej), el hecho que estén ahí no quiere decir que su uso sea lo correcto, y es un debate generalizado por mala información generalizada, pero realmente no es un debate simplemente es desconocimiento de la Programación Orientada a Objetos, siempre hay formas de evitarlas solo que requiere mas conocimiento y ganas de hacer las cosas usando BUENAS PRACTICAS!!!

Lo mismo pasa con los servidores de base de datos RELACIONALES hay que usar buenas practicas pero aquí se conocen como NORMALIZACION.

Cualquier duda o ampliación en un punto estoy para apoyar.

saludos

Antonio Meza

[Saúl Piña]

AMEN a eso,

¿Acaso es una Broma Marcelo Juarez? 

Jamás dejaría de utilizar el Autoincrementable....
 

[Antonio Meza]

Saul hace rato me dio el tip para explicar mejor el uso de los autoincrementables contra cualquier otra forma.

NO usar autoincrementables como llave primaria (PK) es como querer inventar la rueda o el hilo negro, es decir para que reinventar algo que ya se tiene de forma nativa, es mejor aprovecharlo, así de sencillo y desde luego el saber utilizarlo para lo que es realmente y nada mas.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Ya expuse mis argumentos, los documente, puse referencias de peso.
No voy a meterme en una flag pk ward por el tema.
Los autoincrementales sirven para ciertos tipos de problemas, simples o no, depende de una valoración subjetiva.
Usarlos o no depende de los requerimientos del sistema y no de sin fáciles de usar o si el SGBD los provee o no.
Tan esenciales no son, si ORACLE, que no necesitó explicar que es como SGBD, provee IA pero mediante triggers, y no tan directo como otros gestores.
Si fueran esenciales, no lo haría tan "complejo".
En ciertas circunstancias puede complicar o imposibilitar la solución.
La propuesta de clave calculada que explique en otras oportunidades no tiene el problema de los AI.
Es una solución simple (lo suficiente como para que se me haya ocurrido a mi). Fácil de instrumentar. Portable a cualquier SGBD.
Cada cual sabrá cuanto ajo y agua soportará.

Saludos: Miguel, La Pampa (RA)

[Marcelo Juárez]

Gracias a todos por sus respuestas, el tema que expuse es porque leyendo la ayuda del Visual Fox Pro 9, dice:

Considerations for Autoincrementing Field Values

A field that contains automatically incrementing values becomes read-only and cannot be changed with an insert, update, or replace operation. Attempting to update such a field generates an error message unless you set the cursor AutoIncError property using the CURSORSETPROP( ) function to False (.F.) or turn the error message off by using the SET AUTOINCERROR command. For more information, see CURSORSETPROP( ) Function and SET AUTOINCERROR Command.

Tables containing automatically incrementing field values append table-buffered records approximately 35% slower than tables without automatically incrementing field values, which might affect performance. When using table buffering, the table header is locked when the record is appended.

Visual FoxPro does not manage gaps in generated sequences. Gaps can be caused by reverting an appended or inserted record or by failing to update the base table and so on. In all cases, the unused value is lost, and the next generated value remains the same as if the append or insert operation succeeded.

Versions prior to Visual FoxPro 8.0 cannot recognize tables that use automatically incrementing field values. If you remove autoincrementing for fields, the current state containing the last incrementing and incremental values is cleared from the table (.dbf) field subrecord and discarded. The table (.dbf) type is restored to the current Visual FoxPro type value. The automatically incrementing values stored previously in each record remain

Dice que son un 35% más lentas una tabla que contiene campos autoincrementales que una que no lo contiene, además en el ejemplo de Antonio Meza sobre el uso de Foxydb, en lugar de utilizar un campo autoincremental en la tabla usaba la función code para obtener un código correlativo, que reemplazaba en la tabla auxiliar donde tenía los datos y luego pasaba dicha información a MySQL.

Yo, desde que salió la versión 6.0 de Visual Fox que la uso y hace unos cuatro años me pasé a la versión 9 y ahí comencé a utilizar los campos autoincrementales. En la versión 6, al no existir dicha posibilidad, no me quedaba otra que hacer una tabla donde tener los campos claves para ir numerando.

El tema es ése, al leer en la ayuda de Visual Fox que era un 35% más lenta.... me hizo dudar de todo.

Gracias por sus respuestas

[Saúl Piña]

Creeme no es buena idea dejar a un lado los autoincrementables, ya que de ellas se relacionan las tablas y es mucho mas facil armar SQL incluso con inner y left join, etc.

Eso de que son más lento al utilizar autoincrementables, no lo creo, al menos a mi no me ha sucedido, sino que por el contrario, por no utilizar autoincrementables y al tratar de armar consultas, el proceso de mostrar la consulta se torna lento y malas prácticas de programacion.

En SGBD debes si o si utilizar los autoincrementables, sería lo ultimo que yo dejara de utilizar.

Es cierto, Antonio tiene la opcion de tambien "trabajar con correlativos" pero eso para nada es un ID y la opcion que dices de "Code" es precisamente un autoincrementable.


Saludos y que la fuerza los acompañe...je,je,je

[Saúl Piña]

Saludos,

pero me pregunto yo, para que complicarse con algo que ya existe?

Tan esenciales no son, si ORACLE, que no necesitó explicar que es como SGBD, provee IA pero mediante triggers, y no tan directo como otros gestores.
Si fueran esenciales, no lo haría tan "complejo"

Solo por que el lo hace de ese modo, no quiere decir que forzosamente hay que hacer complejo todo.

"Acordemos no estar de acuerdo"

[Antonio Meza]

Que seria este foro sin Miguel y yo hablando de Primary Key jajajaja

Analicemos los link!!!

http://www.forosdelweb.com/f21/utilizar-int-varchar-claves-1028448/

Hay unas pocas ventajas en usar una clave primaria numérica:
1) Son más rápidas en las búsquedas, porque su matching es binario, lo que aprovecha directamente los recursos del hardware (UAL).

Correcto!!!
2) Ocupan menos espacio (máximo 8 bytes o 64 bits).
Correcto!!!

3) Son fáciles de recordar para el usuario, en el caso del ingreso y validación de datos.
INCORRECTO!!! este es el error principal que genera el debate, ya que el usuario final no debe NUNCA JAMAS (piter pan) conocer y usar este valor ya que es interno y para uso del programador o administrador de la base de datos.

4) Son sencillos de poner en las sentencias, ya que no requieren conversiones ni charsets.
Correcto!!!
5,6,7... Son Generados automáticamente por el servidor, no hay que preocuparse por generarlos y validarlos, en las relaciones (JOIN) con otras tablas son mas sencillos de armar ya que solo usas por ejemplo INNER JOIN a.id = b.id, 

Tienen algunas desventajas en el uso:
1) Generan problemas para integración de datos, ya que diferentes instancias de una misma clase pueden estar usando el mismo ID numérico si están en bases de datos separadas.
SI y NO!! porque dependerá del tipo de Replica o Migración, un sencillo Scrip lo soluciona, nada del otro mundo

2) Generan serios problemas ante truncados accidentales o intencionales, ya que el reinicio de los números produce serios problemas de consistencia histórica.
Incorrecto!! El termino TRUNCAR en una tabla es vaciarla o borrar todos sus registros, lo que normalmente reinicia el Autoincrementable a Cero pero esto no tiene nada que ver con problemas, mas bien es no saber lo que se esta haciendo y no conocer como funciona un autoincrementable, es como si se dice que usar muchos indices no es correcto solo porque alenta las inserciones, es cuestión de análisis y saber como y para que funciona un indice y entonces se usaran menos y en campos estratégicos.

3) No permiten una fusión de datos sin necesidad de largas tareas de migración que compense los diferentes IDs. Y como ese ID muy probablemente sea FK en otras tablas, la cadena de dependencias debe ser tomada en cuenta en esa migración, haciendo la tarea más compleja.
SI y NO!!! es lo mismo que dice en el punto 1.

4) El borrado de datos genera discontinuidades que los usuarios no comprenden y resulta difícil explicar por qué no se deben "llenar".
INCORRECTO!!! de nuevo el usuario no tiene porque hijos de la china saber que es un campo de autoincrementable jajajaja y luego borrar datos pues como que tampoco debe ser, ya me estoy dando cuenta que tipo de DBA es jajajaja

5) Otros... muchos otros (puse sólo algunos).

Otros muchos? será?

Por su lado, una PK basada en atributos propios tiene muchas ventajas:
1) No causa problemas de consolidación ni integración (cada ID es único en todo sentido).
Correcto!!! pero tampoco es nada del otro mundo hacer lo mismo con los autoincrementables (muy negativo este cuate) jajaj 

2) El borrado o truncado accidental no produce conflictos con los backups.
No estoy de acuerdo, borrar una tabla por accidente simplemente sacas el respaldo y ya tienes los ID nuevamente, creo que fumo yerba de la barata jajaja, ahora que si pierde los datos e inserta registros nuevos y luego los quiere comparar con un respaldo pues esta operado del cerebro jajaja que tipo de administrador de base de datos es? jajaja

3) Si las PK son numéricas (aunque no AI) o de fecha y hora, conserva todas las ventajas de una AI, sin ninguna de las desventajas.
Como? le entro la nostalgia o arrepentimiento? si voy a usar un campo numérico como PK que tengo que generar manual pues mejor uso un autoincremental y me evito tener que generarlo y validarlo jajaja, de cual fumo!!! un campo Primary Key tipo fecha? de que los hay los hay jajaja ya nada mas falta que diga que usa TimeStamp para acabar con broche de oro jajajaj

4) Como son atributos propios, las búsquedas son más rápidas ya que los datos importantes se recuperan al mismo tiempo (mejora el uso de índices).
INCORRECTO!!! Confunde claramente lo que representa un campo Primary Key mas allá de que si es autoincrementable o compuesto, usar un campo como el DNI para buscar un registro es lo normal que hará un usuario NUNCA buscara por el ID, o sea como pues!!!! jajajaj

5) Consume menos tiempo de red, al no tener que traer datos no relevantes (los AI).
JAJAJAJAJAJA que buen chiste!!! o sea no me traigo el campo Primary Key para ahorrar datos en la red jajajajaj, y cuando regrese un UPDATE le digo al Update ...... where campo1 = ?a and campo2 = ?b and campo3 = ?c, en vez de hacer algo tan simple y sencillo como Update .... where id = ?x 

6) Otros...

Que bueno que ya no continuo jajajaj

Como desventajas, este otro tipo de claves pueden tener:
1) Suelen ser más largas, y eventualmente si se usan VARCHAR volverse un poco lentas en ciertos casos.
Desde luego que si tiene razón y no se como las recomienda jajajaj

2) Los índices pueden ser más grandes.
Por supuesto que van hacer mas grandes, donde esta la ventaja!!!

3) Al programador puede darle más trabajo depurar las consultas por errores de programación no muy visibles.
Ciertamente, entonces para que usar este tipo de PK

4) Los usuarios no comprenden bien la lógica de usar tipos de claves no numéricas, por lo que esto debe ser completamente transparente para ellos.

Los usuarios no deben ni tienen que entender que es un Indice, un PK, etc, si luego le dices que capturen el Sexo de una persona y le ponen M aun Hombre porque dicen que selecciono MACHO!!!! jajajajaj ahora para que le sirve saber que es un campo numérico o alfanumérico que compondrá la llave primaria, luego te dirá que cual usara en la secundaria y bachillerato jajajaj

Resumiendo: Si lo analizamos como sistema, es mejor usar claves que sean atributos propios, y no crearlas artificialmente sólo porque sea cómodo. A la larga produce más beneficios.
A caray no entendi si  y no ??

Por otro lado, se suele sugerir usar claves numéricas en las tablas (para simplificar el proceso) si, y sólo si llegados a la normalización y estando en la 3FN (ver Formas Normales en Wikipedia) aún no se ha determinado una clave candidata, o no una eficiente.

Desde luego que en tablas Relacionales se debe si o si usar al menos las tres primeras formas normales, si no mejor usen Excel!!!

Luego sigo analizando los demás links!!! lastima que este cuate no se puede defender de mis comentarios locos jajajaja

saludos

Antonio Meza

[Antonio Meza]

Hola Marcelo en tablas DBF ese fue el detalle por el que no use campos autoincrementables pero eso es un problema exclusivo de VFP con los DBF, en el caso de cualquier servidor de base de datos es todo lo contrario ganas velocidad y rendimiento en todo momento.

OJO!!!! además en el ejemplo de Antonio Meza sobre el uso de Foxydb, en lugar de utilizar un campo autoincremental en la tabla usaba la función code para obtener un código correlativo, que reemplazaba en la tabla auxiliar donde tenía los datos y luego pasaba dicha información a MySQL.

Mal interpretaste el uso de la función foxydb.Code() ya que es para obtener un consecutivo único y no es para reemplazar nunca a un autoincrementable y mucho menos para usar con una tabla auxiliar, en el ejemplo uso una tabla Clientes con estos campos

Clientes

id  int(11)                      * Campo Primary Key Autoincrementable

codigo Char(10)           * Código Único como clave para el cliente generado por .Code()

Cliente  VarChar(100)  * Nombre del cliente

Como puedes ver el campo Código es un campo para el usuario y el campo ID es para uso interno del sistema y base de datos.y el error que comente la mayoría es usar el campo ID para que el usuario lo digite para sus búsquedas y ahí empieza la historia, desconocimiento y debate. jejeje

saludos

Antonio Meza

[Antonio Meza]

FireBIrd también provee AI por medio de tiggers y eso no tiene nada que ver con el uso y aplicación.

Es como abrir un puerta con la llave o usar un desarmador (destornillador), un martillo, etc, para que usar un martillo si para ello esta la llave? mas simple !!!

saludos

Antonio Meza

[mapner]

Firebird a partir de la version 3 (actualmente en Beta) incorpora el tipo Identity

http://www.firebirdnews.org/firebird-support-for-identity-columns-in-3-0/

[Carlos Miguel FARIAS]

No voy a retrucar a Saúl, con referencia a que transcribió y refutó de uno de los artículos que les pase, lo bueno sería que todos los interesados, lean todos los artículos y saquen sus propias conclusiones (o todos viertan sus opiniones)

Bueno, es la opinión de algunos aquí (Saúl y algunos otros, con el respeto que me merecen) contra lo que dicen Codd (inventó bd relacionales), Date y todos los expertos en bd (y digo expertos, porque tienen doctorados en el tema), que he podido consultar y leer.

Recomiendo leer el libro " SQL Antipatterns" que mencione previamente, que explica muy claramente cuando conviene o no usar diferentes técnicas cuando se usa SQL, además de lo referente a usar o no IA. Este libro tiene cosas muy interesantes, aparte del tema en cuestión, por lo que amerita su lectura, tiene un enfoque práctico, e indica cuando una alternativa es aplicable y cuando no.

En cuanto a un tema mencionado aquí de que las claves numéricas son mejores que las alfanuméricas, es relativo. Lo que si es importante que la clave sea lo más chica posible (eso es indiscutible). Si tienes un clave numérica entera (sea o no autoincremental), puede almacenarse en 4 bytes (hasta 9 dígitos en rango completo) u 8 bytes (hasta 19 dígitos, casi completos). En los casos de algunos SGBD (p.e. mySQL) pueden usarse campos binarios aún más pequeños (tinyint y smallint), y además indicar que el campo es sin signo (se duplica la capacidad de valores posibles).

En fox, las claves numéricas, cualquiera sea su tipo base, ocupan 8 bytes en el índice, por eso recomiendan convertirlas a caracter con bintoc y recuperar con ctobin (ocupan menos bytes) y achica el índice.

El párrafo anterior es fácil de deducir a partir de si conocen o no la forma de almacenar indices en arboles B+, que es una estructura de índices de uso común en SGBDs.

Lo de normalización no se discute (y justamente, cualquier técnica o metodología de normalización solo aplica claves subrogadas, artificiales o IA cuando no existan clave primarias naturales).

El desempeño de VFP malo con IA se debe a que en realidad a los archivos no lo está accediendo un solo motor de BD, si no que cada aplicación que accede está compitiendo por el uso del IA con su propio motor de BD y tiene que establecer bloqueos adicionales para usarlos.

En cualquier SGBD decente, éste con su estructura ACID como único motor de BD accediendo, puede coordinar la generación de números para IA, porque no debe coordinar el acceso con nadie, pero igualmente, requiere un tiempo adicional (con CPUs actuales, insignificante).

En el siguiente escenario, usar clave natural es más rápido que usar IA (y no es algo excepcional).

Persona = {iDocumento, cAyN, dNacimiento, etc.}  && diseño con pk natural

y

Persona = {idPersona, iDocumento, cAyN, dNacimiento, etc.}  && diseño con pk IA

donde negrita denota clave unique y subrayado clave primaria. En el primer caso, un solo campo (menos espacio) sirve como clave primaria. En el segundo caso, idPersona puede ser un campo más pequeño (int contra bigint de iDocumento, si quiero por ejemplo manejar CUIL/CUIT), pero el indice sobre iDocumento lo necesito igual, ya que debo buscar personas por documento por él, y debo verificar (o el SGBD) que no se repita.

Pero en fin, si te quieres colgar de un framework, y el framework trabaja solo con IA, ajo y agua.

Django por ejemplo, por omisión, utiliza IA, pero permite otro tipo de accesos.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, a mi me abandona y me voy para el WC

[Antonio Meza]

Los ejemplos valen mas que mil palabras!!!

Ahora se esta poniendo de moda usar UUID como primary Key, y llegara el momento en que los propios servidores de base de datos los van a optimizar para aprovechar sus ventajas, en las que destacan las 2 principales que no los necesitas generar en el servidor si no desde cualquier lado y nunca sera repetido o existirán 2 iguales, entonces así uso

Primary Key (PK)

AI = Siempre

UUID = Los tengo en la mira

Naturales = NUNCA

Manual = NUNCA

Usar una clave natural se me hace ilógico en todos los casos y usar un AI se me hace mejor jajaja, en un futuro estoy seguro que cambiare de AI por UUID, pero mis sistemas con AI por el momento son suficientes, usar un campo definido o manual NUNCA!!!

Un error común por ejemplo la mayoría (yo no) guarda en un campo la letra para definir el Sexo de una Persona, por desconocimiento, por no conocer normalizacion, porque resulta mas cómodo, mas fácil, mas sencillo, porque la competencia así lo usa, pero la realidad es que NO, en base de datos se debe siempre analizar y pensar a futuro y partir de la base de datos hacia la interface. no al revés, ejemplo:

Tabla Persona

id     persona     sexo
1      Juan          H

3      Luis           H

11    Ofelia        M

Luego en la interface (formulario) muestran un textbox para que el usuario ingrese la letra H o M, en un textbox o label muestran el significado de la letra Hombre / Mujer, este diseño en el futuro a muchos les afecto para incluir ahora los diferentes tipos de Sexo que hay jajaja tienen que modificar la interface, reportes, su reglas de negocios, y un sin fin de cuestiones, y no olvidar que tiene que validar que solo pueda teclear H o M y los nuevos, todo esto porque según es mas fácil usar el campo Sexo en la tabla principal (personas) y porque asi lo usa la mayoria y es mejor!! sera?!!!!

Si se implementa Normalizacion desde un principio, no tendría que hacer nada mas que agregar el nuevo tipo de sexo y listo, así de sencillo, pero en un principio fue mas fácil hacer lo de arriba y como así lo hacen todos pues todo mundo copia y pega, y ya ni hablar de lo sencillo que sera la interface con la tabla bien diseñada, entonces lo correcto es:

tabla Sexos

id  Sexo        clave

1   Hombre   H

2   Mujer       M

5   Otro         O

tabla Personas

id   idSexo   Persona

1      1          Juan

3      1          Luis

11    2          Ofelia

15    5          Agapito

Lo que me encanta ver comentarios de muchos programadores que se quejan que al usar AI, y al revisar las tablas no les dice nada jajajaj que necesitan hacer los JOIN o buscar el valor del campo ID para saber que significa a diferencia de usar claves naturales (que tontería) porque si quiero analizar esta tabla se hace a través de un Join o los Join que se necesiten, están mal acostumbrados a la vida real que todo lo quieren repetir en las bases de datos jejeje es decir tienen el síndrome de Bases de datos de Excelencia o son programadores de Excelencia porque usan EXCEL jajajajaja

Para mostrar ese registro en un formulario se hace un inner Join y como a nadie le gusta escribirlos y son tan sencillos pues prefieren agregar el campo en la tabla principal y hacer una de artimañas con la interface y luego en los reportes están sufriendo porque no pueden armarlos jajajaj

Select 

              personas.persona
            , sexos.sexo

            , sexos.clave as sexo_clave

        form personas

        inner join sexos

             on personas.idsexo = sexos.id

Se puede usar "AS" pero en lo personal no me gusta NUNCA me ha gustado, hay que recordar la regla del 80/20 en programación, que significa que el 20% nos la pasamos escribiendo código y el 80% analizando el código es decir visualizando o revisando, entonces me es mas fácil analizar el Select de arriba que usar así

Select 

              p.persona
            , s.sexo

            , s.clave as sexo_clave

        form personas as p

        inner join sexos as s

             on p.idsexo = s.id

La ventaja sera que envías menos caracteres al servidor pero no hay que exagerar, prefiero mandarle mas caracteres al servidor que andar viendo que es P que es S etc. jajaja al final es cuestión de gustos para el servidor le da igual jajaja

Entonces Obtenemos así

Cursor Personas

id    persona   sexo         sexo_clave

1     Juan        Hombre    H

3     Luis         Hombre    H

11   Ofelia      Mujer        M

15   Agapito   Otro          O

Luego en el formulario muestro en un Combo el campo Sexo y no tengo que validar ni pedirle al usuario que teclee ni que tenga que recordar que es H o que es M , luego en los reportes algo clásico IIF(persona.sexo="H","HOMBRE","MUJER") y todo por no usar normalizacion y evitar los JOIN.

En mi caso la clave la traigo para poder determinar algo en la interface o en las consultas, porque los campos ID como ven en los ejemplos pueden variar su valor y no ser consecutivo algo que muchos se quejan porque los quieren usar como sustituto de claves naturales y solo son para uso interno del servidor y no para otra cosa, es decir es un error utilizarlo como una clave para sustituir la clave del Sexo en este ejemplo, es decir traer el campo IDSEXO y luego preguntar si IDSEXO = 1 para Hombre o IDSEXO = 2 para mujer, esto es un error de desconocimiento para que sirve un campo Primaty Key independientemente de que sea autoincremental, y es lo malo de usar claves naturales es un error por todos lados requieren validaciones y muchas yerbas mas jajaja

En conclusión a diferencia de que me den un ejemplo, donde es mejor usar un Primary Key con una clave Natural (DNI, Fecha, Factura, Contrato, etc) contra una clave subrogada (sea AI, Manual, UUID, etc) seria interesante porque en todos los casos que se me han presentado NUNCA eh visto un beneficio mas allá del que al listar la tabla sepa que es un campo pero eso no me sirve en los procesos, no es excel es un servidor de base de datos.

En cuanto AI vs UUID ya la cosa cambia es de analizar, pero AI vs Manual o predefinida NUNCA!!! es mi punto de vista personal y no soy ni tengo ni tendré doctorado ni maestría ni nada de esas yerbas en Bases de datos jajajajaj

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Sonamos, era un discusión entre AI y naturales, y apareció la manual (Manuelita? mental).

Y la variante predefinida?, ninguna tabla (entidad) tiene un PK predefinida, terminada la normalización y definidos los atributos de una entidad, la PK surge del atributo o conjunto de atributos que siendo mínimos (la menor cantidad, menor tamaño o ambos) permita identificar en forma univoca una fila, o de no haber tales atributos una clave artificial, subrogada, etc. (en este último caso, una forma de instrumentarla es a través de IA).

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe para leerse un buen libro sobre el tema (si son más, mejor)

[mapner]

Si bien esta discusión genera una especie de Deja Vu o sensación de estar discutiendo algo ya conversado en exceso, creo que cada posición (Antonio y Miguel) tienen algo de razón, cada uno en lo suyo:

- Usar AI: Son PK sencillas de generar, no semánticas (no tienen sentido para el usuario) y de un sólo segmento. 

- Alternativas a AI: se pueden usar campos o combinaciones de campos para buscar "claves candidatas" que aseguren unicidad, por ejemplo: Tipo de Comprobante y Número de Comprobante, (no se tienen que agregar campos adicionales a los que componen el modelo de datos). El tema de claves candidatas es: Aseguran Unicidad? Tienen muchos segmentos? Son invariables en el tiempo? la verdad que muchas preguntas a responder y ahí los AI se imponen por simplicidad.

Los que trabajan en informáticas hace muuuchos años quizá tengan (tengamos) algunos vicios de vieja data como el evitar crear campos adicionales al modelo, esto viene de la época donde cada byte contaba y se debía ahorrar espacio de almacenamiento a como sea. Hoy en día con las actuales capacidades de disco, eso no tiene demasiado sentido.  Yo hoy sugiero usar PK AI por la simplicidad que conllevan.

Saludos!

[Antonio Meza]

Hay muchos temas polémicos que pocos alzan la mano para comentar a fondo, caso de Miguel y su servidor que normalmente solemos contestarles a los que preguntan sobre el tema del diseño de base de datos, a veces se genera un cruce de palabras mas palabras menos pero bueno son circunstanciales y si lo vemos del lado positivo son beneficiosas para poder crear criterios y entre mas fueran los que se involucraran con su experiencia seria mas conocimiento.

Creo que mi ejemplo fue muy ilustrativo en general, de como un mal diseño de la base de datos nos lleva hacer muchas cosas raras en todas partes, un buen diseño nos simplifica todo, seria bueno ver ejemplos que solo experiencias pues la literatura puede ser buena pero sin ejemplos luego no se entiende!!!

Mi idea de ampliar estos temas es que no los hay en internet y los que hay la verdad son de chiste, y como me gusta compartir mi conocimiento pues es una forma mas de hacerlo y si en algo estoy equivocado pues es bueno saberlo para no decir tonteras en el futuro jajajaja

NOTA: Predefinida me refería a que el programador la predefine, diseña, crea, etc. no hay campos predefinidos de nada y sobre nada.

saludos

Antonio Meza

[Antonio Meza]

Mapner, te comento que había escuchado decir " Deja Vu" y como no sabia que significaba ahora ya se jajaja

déjà vu

1. nombre masculino

   Sensación de haber pasado con anterioridad por una situación que se está produciendo por primera vez.

Déjà vu o deja vu es un término francés que significa “ya visto”. 

saludos

[mapner]

En la primer película de la saga Matrix, el personaje de Neo ve pasar un gato negro dos veces y dice "Deja Vu" a lo cual Orfeo le responde, es una falla de la Matrix...

[Carlos Miguel FARIAS]

Estimados: Si a un jefe DBA que es ingeniero de sistemas, con doctorado en data mining (o algo así), le llevo la justificación de uds. de que usar PK con IA porque es más simple, me manda a freír churros (encima, no se cocinar).

Aclaro que tengo muchos sistemas que usan AI, por ejemplo, en los casos de gestores de contenido, mensajes entre usuarios, gestores de documentos, gestión de personas con múltiples documentos identificadores, alternativos, etc.

En ningún momento cuestione la simplicidad de instrumentación inicial de los IA, tampoco cuestione, es más fundamente porque los indices numéricos pueden ser más eficientes, y como en Fox, pueden ser peores si no tiene en cuenta como se almacenan en el indice y como se puede evitar ese problema.

En mis primeros sistemas (inicios de los '80), achicar los indices era fundamental, porque con 128 Mb en disco y 128 kb de memoria, con S.O. que no permitía fragmentar los archivos (S/34) y atendiendo 7 usuarios más procesos por lotes, ahorrar un byte por registro representaba horas menos de proceso, o que pudiera hacer una copia de seguridad (en dkt de 8" y 1,2 Mb de capacidad c/u).

Todos los indices eran numéricos y compactos, y si eran varios campos numéricos, se concatenaban y se almacenaban concatenados, como números.

En el libro que les pase, toda la fundamentación se hace con ejemplos, no hay nada técnico, y además, lo recomiendo porque da muchos ejemplos y soluciones a problemas (algunos a mi no se me habían presentado nunca) de diversa índole, donde lo de los IA es uno en 40 o 50 casos.

Es más, hay soluciones para algunos problemas que a veces algunos colegas han presentado en el foro.

La clave primaria (y todo el diseño de la bd) debe responder a las necesidades del sistema, no a las limitaciones del programador (intelectuales, temporales, voluntad, etc.)

Ya para tratar mañana (viernes)

El ejemplo de sexos, donde se indica una tabla aparte ya me parece un mal diseño. Es más eficiente un SP que dado un código, me devuelva el descriptor, o una función en el aplicativo.

Además tener una tabla para el sexo, puede ser incomodo. Extender la tabla mientras estas en línea puede ser frustrante, te puede quedar el sistema colgado.

O te pegas un porrazo.

Los tipos de sexo no cambian en el tiempo (hay dos físicos, y varios operativos).

Cuanto sexos hay?, depende (en mi caso, cada vez menos), según Facebook, 54 o 57.

Tu solución de hacer Join con una tabla para ver la descripción del sexo, me parece absurda, en mi caso, el join es con la pareja de turno ;-D y para ver la descripción, dejo la luz prendida.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, hacerlo en una tabla requiere equilibrio, valentía, mucha fuerza y 9 semanas y media

[Saul Piña Hernandez]

Saludos Miguel,

yo creo que tengo todas las ventajas en cuanto a autoincrementables se trate, ya que dejo que el propio server haga su trabajo, lo demás, pues ahora si que está demás (valga la redundancia)

y la tabla de los sexos es el claro ejemplo de como se optimiza para trabajar y armar los select. y para nada se cuelga al contrario vuela y el rendimiento es mayor.

Largo entendimiento y libera tu mente a las nuevas formas!!
que la fuerza te acompañe, bueno a todos nos acompañe...ja,ja,ja

por cierto, yo si se freir churros.

[Antonio Meza]

Hola Miguel te agracederia mucho si das el ejemplo de como dices que es mejor, de esa forma aprendo mas, que te parece si así como yo lo puse podías darme el ejemplo? y como se mostraría la descripción en la interface (formulario) y reporte (frx), esta interesante lo que comentas pero seria mas interesante ver el ejemplo.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Saludos Miguel, 
Un gusto Saul

yo creo que tengo todas las ventajas en cuanto a autoincrementables se trate, ya que dejo que el propio server haga su trabajo, lo demás, pues ahora si que está demás (valga la redundancia) 

Si te sirve, es una buena solución para ti

y la tabla de los sexos es el claro ejemplo de como se optimiza para trabajar y armar los select. y para nada se cuelga al contrario vuela y el rendimiento es mayor.

No entendiste de que porque el sexo en una tabla puede dejar tu sistema colgado (que parte de que se debe analizar el viernes no entendiste)

Largo entendimiento y libera tu mente a las nuevas formas!!

Tus nuevas formas, son viejas formas resurgidas, movimiento pendular que se llama. En mi caso uso híbrido, según convenga a la simplicidad del sistema, para mi AI es una forma más, no la única, mi mente esta abierta a todas las formas (natural, AI, GUID, UUID, hash, etc.)

Es más, ni mi importa si tiene PKs o no (en la oscuridad no se ve mucho, no?)

que la fuerza te acompañe, bueno a todos nos acompañe...ja,ja,ja 

Igualmente, del lado claro por supuesto, al lado oscuro, con ella me conformo

por cierto, yo si se freir churros.

Me gustan con dulce de leche, pero nunca me comería un churro

[mapner]

Miguel,

Vos decís: "La clave primaria (y todo el diseño de la bd) debe responder a las necesidades del sistema, no a las limitaciones del programador "

Me parece que acá empieza la confusión, una cosa es el "modelo" o sea la estructura de datos que representa el mundo real, con semántica o significancia para el usuario y
otra cosa son las implicancias tecnológicas que requiere una solución informática para que trabaje en forma eficiente.

Un ejemplo de clave primaria hecha únicamente con datos semánticos según proponés:

Sistema de Liquidación de Sueldos: (Daja Vu again, creo que en anteriores debate ya puse este ejemplo)

Recibo Cabecera - Segmentos de Clave Primaria para asegurar unicidad con campos semánticos
- Año de Liquidación
- Mes de Liquidación
- Tipo (Normal, Aguinaldo, ...)
- Nº Empleado
...

Recibo Detalle - Segmentos de Clave con campos semánticos - Se deben heredar la clave primaria de la tabla padre más sus propios campos que aseguren unicidad
- Año de Liquidación (Heredado de Recibo cabecera)
- Mes de Liquidación (Heredado de Recibo cabecera)
- Tipo (Normal, Aguinaldo, ...) (Heredado de Recibo cabecera)
- Nº Empleado (Heredado de Recibo cabecera)
- Concepto de Liquidación
...

o sea en esta última tabla tenemos una clave primaria de 5 segmentos!!!

No sería más fácil usar PKs AI?

Una Tabla que sea Períodos Liquidación
- Liq_ID (PK AI)
- Año de Liquidación
- Mes de Liquidación
- Tipo (Normal, Aguinaldo, ...)

Tabla Recibo Cabecera
- RCAB_ID (PK AI)
- Liq_ID (FK a Tabla Períodos Liquidación)
- Nº Empleado
...
...

Tabla Recibo Detalle
- RDET_ID (PK AI)
- RCAB_ID (FK a Recibo Cabecera)
- Concepto
...
...

Como ves en este último esquema se reducen ampliamente la cantidad de campos en Recibo Cabecera y Recibo Detalle y estas tablas se enlazan por PK->FK en claves de un solo segmento (surgidas de AI). Se redujo complejidad!!!

Imagina sentencias SQL JOIN entre tablas donde la relación se tenga que establecer con cuatro o más segmentos de clave!!!

Hay gerentes de TI que avalan estas prácticas?

Saludos!

[Carlos Miguel FARIAS]

Cuando los datos que normalmente se codifican tienen pocas variantes, son estáticas (caso de sexo, tipos de documento, alguna que sabes que solo cambian cada 5 años), que sería el caso de los conocidos dominios de valores (consisten en un código, que se almacena en la bd y una descripción, que se muestra al usuario). Conviene que sean provistos por una función en lugar de una tabla.

FUNCTION Sexo(cCodigo)

   DO CASE

   CASE cCodigo = "V"

       RETURN "Varón"

   CASE cCodigo = "M"

       RETURN "Mujer"

   CASE cCodigo = "T"

       RETURN "Traba"  && "travestí, travesaño, trabuco" casi es vienes

   ENDCASE

   RETURN "Incorrecto"

ENDFUNC

Luego en el select

SELECT nDocumento, cAyN, Sexo(cCodigo) FROM TuTabla WHERE <lo que quieras>

o con una clase

DEFINE CLASS TSexo AS CUSTOM

   cSexos = "V:Varón,F:Mujer,T:Trava"

   lnQ = 0

   DIMENSION lSexos(3,2)

   FUNCTION INIT()

      LOCAL li, li2 AS INTEGER

      WITH THIS

         .lnQ = ALINES(la, cSexos, 0, ",")

         LOCAL ARRAY la(.lnQ), la2(2)

         DIMENSION .lSexos(.lnQ, 2)

         FOR li = 1 TO .lnQ

            li2 = ALINES(la2, la[li], 0, ":")

            .lSexos(li, 1) = la2(1)

            .lSexos(li, 2) = la2(2)

         ENDFOR

      ENDWITH

   ENDFUNC

   FUNCTION SexoDes(cCodigo)

      LOCAL lnC AS INTEGER

      lnC = ASCAN(THIS.lSexos, cCodigo, 1, ALEN(THIS.lSexos), 1)

      RETURN IIF(lnC>0, THIS.lSexos[lnC], "Incorrecto")

   ENDFUNC

   FUNCTION SexoList()

      RETURN @THIS.lSexos

   ENDFUNC

ENDDEF

oSex = CREATEOBJECT(TSexo)

SELECT nDocumento, cAyN, oSexo.SexoDes(cCodigo) FROM TuTabla WHERE <lo que quieras>

y con

oSex.SexoList obtienes un arreglo para poblar un desplegable o una lista

Esto tambien lo puedes instrumentar en stored procedure

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, y que el oscuro de la fuerza no los obligue

[Víctor Hugo Espínola Domínguez]

Una alternativa a la función puede ser un campo calculado, la mayoría de los SGBD los soporta. También se puede usar para concatenar Nombres y Apellidos.

El tema del sexo en una tabla si es en inglés es una práctica muy usada en algunos productos de Hollywood :-)

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Hola Victor!!

Y podrías poner un ejemplo referente a la misma tabla de sexo usando un campo calculado? o concatenado, no hay como ver ejemplos!!!

saludos

Antonio Meza

[mapner]

Tabla Sexo:

- M - Masculino

- F - Femenino

- N - NULL

- PF - Por favor!

- EVT - Eventual

- CMO - Cada muerte de Obispo...

(mañana es viernes...)

[Antonio.xt]

Yo tengo la idea, y es que asi lo he visto, de que los profesionales usan mas codigo porque estan optimizando los procesos; y uno trata de simplificarlo y hacerlo hasta donde los conocimientos alcanzan.

No quiero entrar en la polemica, pero de todo se aprende.

Pero tengo una duda con tu codigo Miguel, de verdad es mejor o mas rapido usar por ejemplo la funcion "Sexo" o la clase "TSexo" que una tabla del dato "sexo"; no te estoy cuestionando, de verdad tengo esa duda, porque si es mejor o mas rapido ese metodo, pues para adoptarla como buena practica.

Entiendo que son datos que cambian muy poco, que tienen pocas variantes, entonces una tabla o una funcion no cambia tanto, pero estos repercuten en tablas que llegan a tener muchos registros.

Mañana es viernes, repito... MAÑANA es viernes, procuremos dejar los chistoretes para mañana, ahora es jueves; lo menciono porque de repente estoy leyendo un texto y ya no se si es algo serio o un chiste de viernes... en jueves.

[Víctor Hugo Espínola Domínguez]

Un ejemplo para SqlServer: http://sqlfiddle.com/#!3/4f5b2/1

Saludos,

Víctor.

Lambaré - Paraguay.

[Víctor Hugo Espínola Domínguez]

http://forums.devshed.com/firebird-sql-development-61/computed-columns-firebird-2-0-3-a-491985.html

Saludos,

Víctor.

Lambaré - Paraguay.

El 28 de enero de 2016, 14:41, Antonio Meza<solv...@gmail.com> escribió:

[Antonio Meza]

Hola Victor!!

Create Table Personas (IdPersona Int Identity(1,1) Primary Key

                     , Nombres Varchar (50)

                     , Apellidos Varchar (50)

                     , NomApe As RTrim(Nombres) + ' ' + RTrim(Apellidos)

                     , CodSexo Char (1)

                     , DesSexo As Case CodSexo 

                           When 'M' Then 'Varón'

                           When 'F' Then 'Mujer'

                           When 'H' Then 'Hermafrodita'

                           Else 'Indefinido' End 

                      );

Deja que lo vea Miguel y te va a regañar jajajaja bueno al menos que el comparta su uso, en mi caso NO, y te explico:

1. En tablas que están en uso aplicar un ALTER TABLE es un error, de que se puede se puede pero bueno.

2. Relacionado con el primer punto al agregar un campo nuevo o modificar una tabla grande es muy tardado el proceso (en algunos casos)

2. La mas importante y por lo que no se me hace una buena practica, ya le vendí al usuario el sistema y después de 5 años se va a Veracruz (México) y se aplica la operación jarocha (se cambia de sexo jajaj) y resulta que quiere que su nuevo sexo aparezca en los reportes, entonces como no tienen la mas mínima idea de lo que es una base de datos el solo captura y guarda e imprime, pues necesita de ti para hacer la modificación, pero ya te jubilaste y andas en Hawái que va hacer el usuario?

saludos

Antonio Meza

[Antonio Meza]

En este caso es para unir (juntar) dos campos eso no le veo utilidad para sustituir el JOIN de la tabla sexos, o como seria ?

[Antonio Meza]

Es correcto todo lo que comentas Miguel, sin embargo se tiene el mismo problema que le planteo a Victor Hugo al usar el campo con CASEy en tu caso usar una FUNCIÓN, dejas la aplicación dependiendo del programador o administrador de la base de datos para algo tan pero tan sencillo se complique solo para evitar escribir un simple JOIN y crear una tabla como esta bien explicado en la normalizacion, yo veo conjuntos tal vez ustedes ven datos y de ahí la diferencia.

Si uso funciones en Mysql para cálculos y otras yerbas, pero no para reemplazar Campos.

saludos

Antonio Meza

El jueves, 28 de enero de 2016, 11:15:32 (UTC-6), Miguel escribió:

[Arnaldo Toledano]

hummmmmm
Sospecho que te has comido VARIOS CHURROS !!!!
Según dicen tu sobrenombre es "tiburón blanco".


mñn es viernes.


Arnaldo

[Víctor Hugo Espínola Domínguez]

Yo no quiero opinar sobre cuál alternativa es mejor, simplemente puse  ejemplos de campos calculados. Pero estoy de acuerdo con Miguel: Tener sexo en una tabla es algo ridículamente peligroso, digno de figurar en el programa "La ciencia de lo absurdo".

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

jajajaja

saludos!!!

[Carlos Miguel FARIAS]

Bueno, contestando un poco a todos:

Mapner: tus ejemplos comparando bd con pk naturales y pk AI no responde al mismo relevamiento de requisitos. (Y ojo, no valorizo correctos o no, porque se presupone que en cada caso, el analista hace el relevamiento en función de los pedido por el cliente).

Me gusta más la elucidación del segundo caso, porque al momento de una liquidación de sueldos, la liquidación es una entidad que tiene sus propias propiedades (fecha de pago, de deposito de cargas sociales, de impresión de recibos, etc.)

El modelo quedaría  Liquidación ++--+<Recibos++--+<Detalles>0--++Concepto

Donde una liquidación es 1:n con recibos y estos 1:n con detalles y estos a su vez n:1 con Concepto.

Una liquidación debe tener al menos un recibo, un recibo al menos un detalle y los conceptos pueden no tener detalles (por ejemplo el aguinaldo que se paga dos veces al año).

En liquidaciones se pueden pk IA, en lugar de los campos de una posible pk natural (año, mes, tipo liquidación), porque en este caso la supuesta pk natural no es tal bajo ciertas circunstancias (por ejemplo, pago fraccionado del sueldo, y no teniendo un tipo de liquidación ad hoc disponible).

Como las liquidaciones son procesos consecutivos, generados en su solo entorno, una IA los enumera y eso no está mal, en realidad estas enumerando las liquidaciones y en lugar de generar el dato por calculo de aplicación, utilizas la facilidad de secuenciar del SGBD, un smallint sin signo permitiría, unas 65000 liquidaciones (a 20 liquidaciones anuales, te quiero ver en 3250 años... serías pura tela).

Si el SGBD no permite IA de 2 bytes (p.e. Fox), en lugar de usar una secuencia, se podría usar un campo calculado, como propone Victor Hugo (tampoco lo veo para el caso del sexo).

En el campo calculado que luego oficia de PK, puedes fácilmente meter año, mes y tipo.

En el caso de usar IA, igual tienes que crear una clave candidata (unique) sobre los campos separados, porque si no, como evitas que te "liquiden dos veces" el mismo mes y/o el mismo tipo de liquidación? Esto puede pasar por error o por malicia.

En el caso de los recibos, el uso de IA también tiene el mismo problema, como evitas que te carguen dos veces la misma liquidación al mismo empleado?, si no chequeas contra la primaria natural que seria pkLiquidacion + pkEmpleado.

Lo mismo pasa con detalle, si usas IA, igual tienes que forzar el control sobre pkLiquidación, pkEmpleado, pkConcepto (en tu caso sería pkRecibo, pkConcepto, pero en este punto pkRecibo podría ser un recibo mellizo).

Entonces, en tu ejemplo, no veo simplificación en usar IA, ya que igual tienes que adicionar el control sobre la candidata, para evitar que errores o malicias dupliquen registros. Liquidaciones con datos "maliciosos" conozco, y fueron detectadas porque el liquidador quiso mayor % y el "beneficiado" no quiso pagar y lo denunció, de otra manera, la ilegalidad pasaba por alto en una nomina de más de 15000 empleados.

Con referencia al nomenclador de sexos, demuestra que tienes inteligencia para nomenclar, y para hacernos c.g.r de risa, aunque el código CMO pareciera que el obispo se hizo 3.1415 * 2.

Antonio.xt: Preguntabas por la velocidad de usar una tabla o función. Aclaro, por si no se entendió, solo lo veo aplicable para reemplazar tablas estáticas y con pocas entradas.

Por lo demás, linda pregunta.

Depende si usas una función en la aplicación o una función (SP) en el servidor. Si es el la aplicación, es más rápido, porque la aplicación está en el cliente (salvo TS u otras por el estilo), y por lo tanto la descripción no circula por la red (el SGBD solo pasa el código).

Si es un SP, entiendo que correr sería más rápido, ya que el SP queda compilado en el servidor, en cambio una tabla, por más que quede mapeada el plan que elabora el servidor, y siendo una tabla chica, quedaría todo en cache, para hacer el join, tiene que aplicar la lógica de ir al índice, y de ahi a la tabla, o recorrer la tabla, eso habría que testearlo.

La ventaja real que le veo a un sistema de tablas chicas relativamente estáticas, instrumentadas como SP o funciones es que, si surge la necesidad de cambiar la tabla, no lo puede hacer el cliente, lo tiene que hacer el programador y ahí se aplica PELG.

Antonio Meza y el campo calculado: Coincido, el campo calculado (que podría ser reemplazado en ese caso por campo tipo enumeración), podría ser reemplazado el cliente, en cambio, si se usa una función o sp, el cliente no puede cambiarla directamente y entonces si necesita cambiar: PELG

Además, si vendes un sistema, todo lo que está en datos, de cortarse el contrato pertenece al cliente, todo lo que tienes en una función de la aplicación, el cliente no puede (no debería) verlo y entonces si quiere lo que está en el fuente: PELG

En el caso que planteas que te jubilas, entonces al que te reemplaza en el mantenimiento: PELG

El post siguiente, no entiendo que preguntas.

En post de 17:09: Una normalización perfecta posibilitaría la eliminación de la codificación, si aplicas la lógica de Alan Turing, los clientes podrían resolver casi todo con tablas de cálculo (lo he hecho pero lo dejo para otro post si a alguno le interesa) y pierdes entonces la posibilidad del PELG

Arnaldo: Acaso me viste vendiendo pan casero?

Saúl: Como decís eso, que va a opinar Marcelo?

Victor: Coincido con lo de la tabla.

Y si quieren saber que PELG, esperen al viernes.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe hasta la Galaxia Muy Lejana

[Antonio Meza]

"El modelo relacional, según se lo expresa mediante cálculo relacional y álgebra relacional, no distingue entre clave primaria y otros tipos de claves. Las claves primarias fueron agregadas al estándar SQL principalmente para conveniencia del programador. En una arquitectura entidad-relación, la clave primaria permite las relaciones de la tabla que tiene la clave primaria con otras tablas que van a utilizar la información de esta tabla."

Vaya encontré alguien que entiende o ve las cosas de la misma forma, lo que quiere decir que ya somos dos locos en este mundo que pensamos igual jajajajaj y diferente a la mayoría

https://firebird21.wordpress.com/2013/03/15/entendiendo-a-las-primary-keys/

Aquí nace el origen de la controversia y grandes debates porque los de la vieja escuela forzosamente quieren que sea cual sea o cuales sean los campos que definirán la llave primaria cumplan sus 2 funciones, identificar el registro de forma inequívoca y a demás garantizar la unicidad de la información es decir si es una tabla de clientes que tiene un campo DNI esa seria la llave primaria y nos permitirá evitar que 2 clientes tengan el mismo DNI con un solo indice y eso es lo que los de la vieja escuela no ven en los AI, quieren que a fuerza cumpla esas dos funciones y no es así y si así fuera pues se pierde su beneficio y no tendrían razón de existir.

Al usar PK AI el concepto cambia totalmente, el AI solo es para identificar entre registros de forma inequívoca, para relacionar con otras tablas de forma mas sencilla, para Actualizar, Eliminar y en algunos casos Seleccionar registros de forma mas sencilla y punto y se acabo solo para eso sirve, por lo tanto Forzosamente se requiere un campo Unique sobre el campo DNI para garantizar que no se repitan los DNI, pero ya estamos hablando de 2 entidades distintas, AI para uso interno y exclusivo de la base de datos y DNI para el usuario final, este es el problema de porque unos dicen que no y otros dicen que si jajajaja porque no logran separar el termino PK en un campo AI, lo quieren ver como un todo que me identifique y me restringa, y al final el AI es un insignificante y miserable peón jajajaj que solo va a realizar unas cuantas tareas y no tiene que andar de chismoso si el DNI esta repetido o existe o no existe no le debe importar nada mas que me diferencie una fila de otra y listo para eso sirve el condenadote, pero la vieja escuela dice que NO que NO y que NO y que NO jajajajaj 

Veamos lo que dice nuevamente "Las claves primarias fueron agregadas al estándar SQL principalmente para conveniencia del programador",entonces si fueron agregadas para conveniencia de los programadores porque no aprovechar esa conveniencia si al final el cálculo relacional y álgebra relacional, no distingue entre clave primaria y otros tipos de claves. 

Pero a muchos les cuesta entender esa parte. Si no afecta separar los AI de las restricciones para que tanto drama si al final no hay conflicto y sin embargo se ganan muchas pero infinidad de ventajas, ahora bien usar UUID para remplazar los AI me parece acertado en sistemas GRANDES, pero en un sistema pequeño es mas grande el valor de un UUID con lo que se almacenaría en una tabla pequeña jajaja y el resultado sera el mismo, si hablamos de replicacion donde el AI es donde realmente tiene los inconvenientes mirar a los UUID es necesario darles confianza y dependerá del tipo de replicacion. pero si tu sistema no sera replicado, no tendrás un servidor Maestro y varios esclavos puedes vivir feliz con AI. mas allá de usar otras cosas raras.

En conclusión AI solo sirve para diferenciar un registro de otro, no necesita saber si un campo existe o no existe y si falta un valor en la tabla se puede guardar, es decir si la tabla clientes su PK es el DNI y el usuario no cuenta con el numero no podrá ingresarlo a la base de datos, en cambio con el AI lo podrá ingresar y luego sin problemas agregar el valor cuando se tenga solo por dar un ejemplo de que un AI no tiene nada que ver con restrinciones, ni duplicidad de datos en campos individuales solo sirve para identificar entre registros.

Listo hasta la próxima!!!

saludos

Antonio Meza

[Víctor Hugo Espínola Domínguez]

Hola Antonio

No creas todo lo que leas en Wikipedia, Selecciones, la biblia, el corán, ni lo que veas o escuches en Infobae, CNN y algunos otros medios.

Además si fuera cierto que las claves primarias fueron agregadas para conveniencia de los programadores debería ser un motivo de orgullo para nosotros, pues eso es lo pretendemos que los demás crean que somos. También Fortran, Cobol, Pascal fueron inventados para conveniencia de los programadores (nosotros?) y no creo que esa sea una característica descalificadora.

La elección del tipo de clave primaria (natural o subrogada también conocida como sustituta) es dependiente del alcance del sistema y del gusto del programador, además una clave natural puede ser utilizada si el alcance lo justifica y se garantiza plenamente su invariabilidad, por ejemplo en un sistema solo para los EEUU para almacenar los estados es suficiente usar como clave primaria las siglas de cada estado (clave natural) pero para un sistema en mi país (Paraguay) no puedo usar el número de cédula de identidad porque está comprobado que existen repeticiones del mismo número para distintas personas; y si mi cliente que me encargó el sistema es un banco o una compañía aérea no puedo usar solo AI para claves primarias!

Lectura recomendada: http://comunidadvfp.blogspot.com/2014/09/que-es-una-clave.html

Otro asunto, las claves subrogadas (AI o calculadas) no es necesario que el usuario las conozca pero TAMPOCO ES PROHIBIDO! (creo que esto es tirar gasolina al fuego :-) ) yo los muestro y permito que los usen cuando se pide el ingreso de una clave foránea, el usuario puede ingresar el ID o parte o total de  cualquier dato que identifique una fila, si hay varias le muestro un grid para elegir.

 

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Hola Victor Hugo!!

Creo que no analizaste el párrafo, no esta culpando a nadie (programadores) ni justificando el origen de los PK, simplemente intento explicar con ese pequeño párrafo que me pareció acertado (copie y pegue) entre miles de hojas que hay sobre el tema, que no importa si el servidor de base de datos maneja Llaves Primarias o no, al final solo son conjuntos de datos, relaciones con entidades de conjuntos de datos.

Para simplificar las relaciones pues surgieron los PK así como otras mejoras gracias a los programadores como los SP, etc, al final si o si digan lo que digan y no digan es mejor usar una clave subrogada del conjunto de datos que no tenga la mas mínima relación entre las entidades, de esta forma garantizas siempre las relaciones entre los conjuntos de datos a diferencia de usar naturales que no sirven mas que para causar problemas a futuro

Si en tu caso te va bien usando Naturales pues felicidades porque conozco infinidad de compañeros de trabajo que por no aceptar una recomendación o no investigar a fondo terminaron cambiando toda la data por usar claves naturales que cambiaron en el futuro.

En el entendido de que una clave subrogada es mil y una vez mejor que una natural ya elegir AI, UUID o definidas por el programador pues ya es cuestión personal, me gusta lo practico y el AI de momento me va bien, en un futuro usare UUID ya que los programadores de DBA los optimicen mas o en su caso requiera replicar la data con varios centros de datos.

No hay como dar ejemplos de cuando es mejor usar Naturales a Subrogadas, nada mas dicen pero no los ponen, como saber si es cierto jajajaja

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Estimado Antonio: Mencionas un artículo de mi estimado Walter Ojeda, al que respeto por toda su "apertura" a ofrecer conocimientos del uso de Firebird (y supo ser colaborador asiduo de este foro hasta que su intolerancia a ciertos temas hizo que se alejara).

Si lees bien el artículo, él se equivoca al decir que los IA como están disponibles y facilitan la tarea de los programadores (o fueron hechos para facilidad de los programadores) deben usarse en detrimento de otros tipos de indices.

Tu te cierras en los AI, como la panacea para todo. En cambio, los expertos "reales" indican los AI como una alternativa para ciertas situaciones.

Tus mismos ejemplos (sueldos) dan por tierra tu "empecinamiento" sobre usar solo AI.

En el caso citado, usar AI te crea posibilidades de doble liquidaciones, doble recibos, etc si solo usas AI, tienes que agregar control sobre la pk natural para evitar "estropicios", entonces, usar pk AI, es una ventaja para el programador, no para la aplicación. Esta tiene que mantener dos indices con carga de claves únicas no nulas, posiblemente indices del mismo tamaño o similar, donde el indice sobre la candidata no puedes omitir, entonces ¿donde está la ventaja?

En el caso del estado, si o si el proveedor que registre tiene que tener identificación fiscal (CUIT en Argentina), pasa lo mismo como empleados. Si usas AI, igual tienes que mantener ambas claves (IA y pk natural)

Si es aplicable el AI en el caso de clientes de un negocio común, solo guardas el CUIT (o equivalente en otros países) que te exige el organismo fiscal (AFIP en Argentina), de los otros clientes no necesitas guardarlos. Pero justo ahí, las especificaciones del sistema te dice que la entidad clientes NO TIENE una pk Natural, y si la entidad no tiene PK natural, es lógico usar una PK subrogada (AI, calculada, UUID).

Otro caso es el manejo de documentación en el estado. En Argentina, normalmente, un documento público se lo denomina Expediente. La clave natural de un expediente es Organismo emisor, año y número correlativo. Si el sistema maneja ese tipo de documentos, exclusivamente. La pk lógica a usar es la natural, porque si uso AI, igualmente tengo que crear una clave unique sobre los campos que forman la pk natural, para evitar duplicaciones.

Tengo sistemas donde uso AI, para aquellas entidades que no tienen pk natural, por ejemplo gestores de documentos, que requiere gestionar todos los documentos juntos, pero estos tienen individualmente pk naturales disimiles, y la única forma de compatibilizarlas es pasarlas a cadenas, que luego el sistema formatea para mostrarlas de acuerdo al tipo de documento.

Preguntarás porque no normalizo en tablas separadas? Por la sencilla razón de que la cantidad de documentos diferentes es indefinida (debe admitir nuevos documentos a futuro) pero las consultas necesitan recorrer todos los documentos (búsqueda por palabras -tipo Google- o fulltext).

Hice sistemas donde la pk natural era compuesta (contribuyente, año, periodo) pero por razones de espacio y simplificación de índices, cree una PK calculada, guardando una única clave numérica entera binaria.

Entonces, como indiqué desde el principio, el uso de uno u otro tipo de PK, que cumpla de unicidad y minimalidad, dependerá circunstancialmente de las especificaciones de cada sistema. No puede depender de las facilidades que les da al programador, porque esa "supuesta" facilidad inicial, se complica al tener que luego agregar control sobre las pk naturales, que uses lo que uses como pk, debes instrumentar.

Concluyendo: Veo en este hilo dos posturas. Usar solo AI vs usar PK acorde a lo que necesita el sistema (incluso AI). Cada cual usará el sayo que mejor le calce

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe (PARA AGUANTAAARNOOOOSSS!!)

[Antonio Meza]

Creo que hablo como Juancho !!! Ay don sink so!!!! jajajaja porque no me entienden o no lo quieren entender!!! jajaja

Miguel!!! donde dices esto:

"Entonces, como indiqué desde el principio, el uso de uno u otro tipo de PK, que cumpla de unicidad y minimalidad, dependerá circunstancialmente de las especificaciones de cada sistema. No puede depender de las facilidades que les da al programador, porque esa "supuesta" facilidad inicial, se complica al tener que luego agregar control sobre las pk naturales, que uses lo que uses como pk, debes instrumentar."

Claramente no leíste con atención mi mensaje ni analizaste el de Walter, tanto Walter como yo, indicamos que se necesita un indice o varios adicionales para salvarguardar la integridad de los datos, así de sencillo, los AI son para manejo de datos no son para validar, ni restringir ni asegurar unicidad de información critica, solo son para manipular datos, un AI no necesita saber que es un DNI o si existe un DNI, un folio de factura, un numero de No. recibo (ojo fue Antonio.tx jajaja), una clave de país, a los AI no les interesa nada de eso porque su función es otra, pero para asegurar la integridad si o si complementas con indices sobre claves naturales como bien lo explicas son necesarias al 100%,

Estamos totalmente de acuerdo que un AI adicionalmente requiere de indices adicionales sobre las claves naturales si o si, para garantizar unicidad de los datos, entonces ya tenemos los datos seguros ahora sencillamente los manipulamos a través de los AI (subrogadas : UUID, AI, manuales) así de sencillo porque no lo puedes aceptar que es mejor hacer esa separación?

Es ilógico que los expertos digan que es mejor separar en capas las reglas de negocios, los datos y la interface, pero no separar el manejo de datos del control de datos jajajajaja

saludos

Antonio Meza

[Antonio.xt]

"un AI no necesita saber que es un DNI o si existe un DNI, un folio de factura, un numero de No. recibo (ojo fue Antonio.tx jajaja)"

Eh tocayo, yo cuando dije eso ?? Y es Antonio.xt, no "tx"

[Antonio Meza]

UPS!!! perdón!!! fue Mapner el que puso ejemplo de Recibo!!! ajaja

ACLARO: No fue ANTONIO.TX 

Corrección: se escribe ANTONIO.XT

Los amigos gritaban "Ansina Ansina vas a ir a jugar"

Sale la Mama y dice: "No se llama Ansina se llama José y Ansina quiero que le digan" jajajajajaj

"Ansina" significa "así". El término aún está en el diccionario de la Real Academia Española, pero marcado como “en desuso”

saludos

Antonio Meza

[mapner]

Antonio Meza,

Tampoco fui yo el de la frase que citas. 

En principio te sugiero amablemente que leas 5 veces antes de citar a alguien. 

[Carlos Miguel FARIAS]

Cuando yo cite a mi señora, no la leí precisamente ;-D

Antonio: Y el resto, no lo leíste? Solo lo de Walter.

Tu mismo matas tu justificación. Una pk en principio debe servir para definir la identificación univoca de registros, si tu AI no alcanza para definir dicha condición (identificación unívoca) entonces no sirve como pk. Que simplifica la relación entre tablas puede ser, pero si no, no es apropiada (que funcione, es otra cosa, pero hasta el DOS funcionaba)

Para ser viernes, este es cómico..

- Manuel! Que estas comiendo?

- Queso

- Pero Manuel, eso es un pan de jabón.

- No importa, lo como igual, tiene gusto a Queso

- Tonio, como definiste el campo precio de la luz?

- Autoincremental

- Pero es un importe...!!!

- No importa, asi le gano de mano al gobierno

- Tonio, por que llegas tarde? (mujer al marido)

- Porque tuve que agregar claves únicas, porque las autoincrementales no alcanzan para validar unicidad de filas

- Y porque no las definistes de entrada?

- Viste que lindo ramos de rosas te traje?

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, este hilo va para largo.

[mapner]

Miguel,

Leyendo tus chistes todos acordamos que tenés un gran futuro como programador...

:)

[Carlos Miguel FARIAS]

Sonreíste como la foto?, para mi es suficiente!!!

Abrazo: Miguel

[Saúl Piña]

JA,JA,JA,  buenos chitorines de viernes..

[Antonio Meza]

hay Miguel Miguel, !!! 

No se que entiendes y resalto la frase que escribiste "Una pk en principio debe servir para definir la identificación univoca de registros, " y te pongo un ejemplo para que aceptes lo que no quieres aceptar porque Walter o yo lo decimos jajajaj 

Tabla Clientes con PK AI

id  Cliente

1   Agapito

2  Rosa Mela

3  Telorino

5  Sacarias

7  Proculo

8  Pepa

10  Toribio

Mi indice Primary Key AI me permite identificar, diferenciar cada registro de la tabla clientes sin importarme como se llame el cliente, de forma univoca, o sea mas claro ni el agua jajaja

Select id, cliente from Clientes where id = 1

1  Agapito

Select id, cliente from Clientes where id = 10

10  Toribio

Lo que tu dices Miguel es que yo estoy equivocado y entonces el servidor también lo esta y si hago el siguiente select obtengo:

Select id, cliente from Clientes where id = 1

1  Pepa

El servidor de base de datos me va a decir que el ID = 1 es "Pepa" ???? solo porque mi llave Primaria Autoincremental hace referencia a todo el conjunto del registro y no especifico una clave natural??? 

En verdad Miguel crees que estoy mal y que tengo que aceptar la ayuda de los expertos con Maestria y leer libros y otras yerbas para darme cuenta que un PK AI me identifica un registro de manera univoca en una tabla?? que es para lo que yo uso los AI para identificar un registro de otro??

Donde esta mi error dime para corregirlo de inmediato porque así manejo todos mis sistemas y ya me estoy poniendo nervioso!!!!!

saludos

Antonio Meza

[Carlos Miguel FARIAS]

No estoy en contra de los IA (lee bien todo lo que escribo), y menos porque lo digas vos o Walter ("las ideas no se matan": Domingo F. Sarmiento, y los que piensan tampoco: (?)).

En el ejemplo con el que intentas retrucarme, ya lo había indicado cuando mencioné el ejemplo de clientes de un negocio, donde no todos necesitaban indicar un documento de identidad, que si era aplicable una pk con AI.

Y mencioné varios otros ejemplos donde las pk IA son aplicables (les comente y mencioné sistemas donde las uso), por lo que tu tratas de convencerme de que las pk AI son buenas y no dije que eran malas.

Pero hay muchos modelos de negocios donde p.e. el documento de identidad es obligatorio (todo lo que es con AFIP, pasajes en micro <larga distancia> o avión), todo lo que haces a nivel bancos. Migraciones, etc. Y todos de "jalan" por documento. Por lo que es evidente de que el Documento debe estar declarado como UNIQUE, y si ya tengo un campo UNIQUE, porque no usarlo como PK (si además es numérico y esencialmente pequeño).

Una pregunta, en tu tabla de clientes, como evitas que te carguen dos veces el mismo cliente?

He visto sistema, de los cuales tuve que importar datos (proveedores) con 13000 registros, que luego de controladas y depurados duplicados y datos gaseosos quedaron menos de 3000.

Este sistemas usaba pk AI.

Este caso lo correcto era usar DNI, CUIT u otro documento que permitiera identificar cada proveedor (como el sistema no lo exigía, cargaban fruta podrida).

Por razones de mal manejo político del área sistemas del Municipio, se instrumentaron sistemas sin coordinar los respectivos nomencladores de calles, que por lógica, por simplicidad (y en eso estoy de acuerdo en cuanto a diseño) usaban pk AI como indice, pero...

... son 6 o más sistemas que debemos unificar, en cada uno se cargaron los datos según demanda de cada cual, consecuencia:

a) dentro de cada sistema hay calles cargadas por prueba o por "molestar" de los usuarios.

b) también hay calles cargadas dos o mas veces.

c) La misma calle correctamente cargada en cada sistema tienen todos distintos pk AI entre uno y otro sistema.

Como hacemos para unificar los sistemas?

Como se puede solucionar? Calculando la clave, diseñe un algoritmo simple, computable mentalmente por humanos (o por computadora) a partir del nombre, crea un mnemónico de 6 caracteres.

Por lógica, también se puede hacer con AI, como vez, no me opongo a su uso cuando el modelo de datos así lo requiere.

Desde el punto de vista de auditoria de sistemas desde el punto de vista de datos (en eso tengo alguna calificación como CP), un sistema con pk AI deja un agujero de seguridad que permitiría que usuarios "preparados" sumado a fallas en reglas de seguridad de la bd (por DBA..Diseñador inoperantes o "adrede") y aplicaciones permisivas permitan clonar transacciones (desfalcos, fraude, "choreo", etc.)

Comentario relacionado: mysql (sql server, oracle y postgresql a sus respectivas maneras) tienen un clausula

INSERT bla VALUES(bla) ON DUPLICATE KEY UPDATE bla bla

que si al insertar un registro, su pk ya existe (o algún unique), en lugar de insertar, actualiza datos.

No funciona con pk AI, porque al insertar, crea un nuevo valor de pk y ya el registro es distinto, no se actualiza y quedan datos duplicados (si hay unique no pk por lo que lei, tiene inconvenientes)

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe (el lunes vuelvo de las vacaciones)

[Víctor Hugo Espínola Domínguez]

Yo me declaro fan de la clave subrogada, para aplicaciones sencillas que no sean distribuidas y no necesiten sincronización de tablas los IA me parecen aplicables, pero renunciando a la escalabilidad.

Estoy construyendo un framework donde permito que la clave primaria sea IA o calculada y en la capa de datos va el método NewPK(tcTaba As String) As Variant donde puedo definir la fórmula para calcular la PK. Para evitar el ingreso de claves naturales repetidas está el método vheCkOk( tcTabla, tcCamposCK, tcTiposCamposCK, tcDatosCK, tcCampoPK As String, tuValorPK As Variant) As Boolean, como refuerzo en el SGBD se puede incluir los constrains necesarios para preservar la unicidad de las claves candidatas.

En resumen los IA son muy útiles pero tiene un costo alto: El sistema NO es escalable!

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Se me borro lo que estaba escribiendo cuando apareció el comentario de Victor Hugo jajaja Pues ni modo va de nuez!!! jajaj

Ejemplo de la tabla Clientes 

ID INT(11) PK AI

Cliente Varchar(200) Indice Unique

RFC varchar(20) indice Unique

etc

Donde RFC es el equivalente al DNI, un buen sistema no solo es un buen diseño del mismo ni de la base de datos, adicionalmente deben existir reglas o procedimientos para el buen uso del mismo y captura de la información, El campo Cliente para una razón social debe cumplir ciertos requisitos en su captura inicial, para que sea posible detectar si otro usuario intenta guardar el mismo cliente con una comas menos o mas y por error esta usando un RFC erróneo que rompen los campos unique, en conclusión no solo basta con la seguridad que se le de a la base de datos y a los programas también hay que invertir en un buena Política de Uso del sistema. Por ejemplo la que siempre implemento es que los catalogos del sistema solo deben ser captuirados por ciertos usuarios, normalmente los mas responsables y cuidadosos de su trabajo, NUNCA dejaría que un vendedor registre un cliente, ya que con las prisas o con las ganas de no estar en la oficina lo hace con las patas jajajaj

Para tratar de unir dos o mas sistemas las claves subrogadas no son para eso, solo son para lo que ya he mencionado anteriormente y nada mas, por lo tanto se deben buscar claves naturales que existan en ambos sistemas para poder hacer la unificación.

Es un error muy común darle atributos a un campo AI de los que no se debe y es donde aparecen los malos usos y los debates, es como usar variables publicas cuando tienes OOP. usar sabanas de datos tipo excel cuando tienes normalizacion, como querer ponerle agua al tanque de gasolina de un carro, todo se puede pero que sea lo correcto es muy diferente.

Victor Hugo, hay muchos tipos de replicacion, cuales has usado en el que un AI no te sirve? tengo un sistema con Mysql donde se tiene instalado en varias sucursales en diferentes ciudades y en la sucursal principal esta de igual forma separado como las otras y se tiene adicionalmente un servidor donde se replica la información de todas las sucursales para los reportes globales, todo trabaja perfectamente con AI, hay Scrip (SP y tiggers) que resuelven los problemas de AI que una sucursal tiene igual a otra, pero insisto cual es la situación real que tienes o viviste y no pudiste resolver? porque decir que para replicar no funcionan es como decir que VFP no sirve jajajajaj, ejemplo

tabla Clientes Servidor central

id

cliente

rfc  (Unique)

etc

tabla clientes en cualquier sucursal 

id

idid (id de del servidor central)

cliente

rfc (Unique)

etc

Cuando una sucursal requiere registrar un nuevo cliente, el sistema verifica si hay conexión al servidor Central, si la hay verifica el RFC y si existe retorna los datos para agregar el nuevo cliente en la sucursal, si no hay conexión la sucursal tiene que facturar si o si, así que se registra el nuevo cliente en la sucursal (protocolo de autorización para el alta en sucursal), el campo IDID esta en 0, cuando se realiza la replica el servidor central verifica la tabla clientes de la sucursal si encuentra campos IDID = 0 busca su respectivo RFC en el servidor si no esta lo registra con los datos de la sucursal, y le guarda el IDID nuevo a la sucursal, y listo sencillo y facilito. El cervidor central trabaja con sus ID y las sucursales con sus ID, mas detalles ya cuesta un billete jajajajajaj

saludos

Antonio Meza

[Víctor Hugo Espínola Domínguez]

Si la PK del cliente en la sucursal es Id, IdId entonces esa PK no es IA, es una subrogada compuesta de 2 IA, que deberás registrar también el la cabecera de la factura.

Saludos,

Víctor.

Lambaré - Paraguay.

[Víctor Hugo Espínola Domínguez]

La única manera que conozco de usar IA replicable es usando un valor inicial distinto en cada local, Central empieza con 1, Sucursal 1 empieza con 2, sucursalN empieza con N+1, el incremento para todos los IA es CantidadDeLocales:

Para 2 sucursales, incremento = 3:

IA en central: 1,4,7,10,13,16, etc...

IA en suc. 1 : 2,5,8,11,14,17, etc..

IA en suc. 2 : 3,6,9,12,15,18, etc..

Saludos,

Víctor.

Lambaré - Paraguay.

El 30 de enero de 2016, 23:09, Antonio Meza<solv...@gmail.com> escribió:

[Antonio Meza]

Miguel 

Me falto comentar que una vez que ya tienes identificados la o las claves naturales que van a unir los sistemas entonces ya tienes de un lado el valor del ID y del otro si usa ID pues también y a trabajar con los ID jejeje

"Desde el punto de vista de auditoria de sistemas desde el punto de vista de datos (en eso tengo alguna calificación como CP), un sistema con pk AI deja un agujero de seguridad que permitiría que usuarios "preparados" sumado a fallas en reglas de seguridad de la bd (por DBA..Diseñador inoperantes o "adrede") y aplicaciones permisivas permitan clonar transacciones (desfalcos, fraude, "choreo", etc.)"

Como lo he dicho antes no tengo titulo de DBA ni certificados de nada. mas que de la vacuna de mi perro servirá? jajajaj pero no necesito nada de esas yerbas para comentarte que usar AI no tiene nada que ver con la seguridad eso es otro detalle de como administras la base de datos, como te conectas al servidor, si usas ROOT pues claro que le das la puerta a todos, si las tablas tiene permisos, en fin es un tema de seguridad que no tiene nada que ver con los AI, en tablas criticas uso HASH si alguien cambia una dato fuera del sistema pues ese HASH no es valido y por lo tanto el registro tampoco, a demas no podria alguien hacer eso pues hay un tiggers lo impide, si me hablas ya de un hacker pues nada es seguro y el AI que culpa? jajaja, insisto los AI solo son para manipular conjuntos de datos no son para sustituir a las claves naturales, para la seguridad de los datos y otras funciones, no se si me explico?

Lo del Insert On Duplicate no se que, es lo mismo todo esta relacionado con la seguridad no con el manejo de datos del AI, el AI es un aliado no es un guardián, es un mandadero, es un va y viene, es un cargador de cajas, para eso sirve, no sirve para evitar duplicidad, ni datos erróneos, etc etc, para eso están los Unique, SP, tiggers, HASH, todo el armamento pesado de la base de datos y la debida seguridad de la aplicacion y a demas las POLITICAS DE USO DEL SISTEMA!!!!!

saludos!!

Antonio Meza

[Antonio Meza]

Ese modelo lo he visto y me parece erróneo, hay otros que empiezan así pero es erróneo hacer eso, bueno para mi en lo personal jajaja

Suc. 001 ID .- 1,000,000

Suc. 002 ID .- 2,000,000

Suc. 003 ID .- 3,000,000

Están limitando la base de datos lo que NUNCA se debe hacer, claro que funciona pero es un mal diseño por donde lo quieras ver, porque no tienen proyección y ya tienes una limitación, tu ejemplo se pueden duplicar y en este llegar al limite y empezar los problemas. los AI no son para eso, hay otras formas y el error viene que a los AI le quieren dar atributos que no le competen.

saludos

Antonio Meza

[Antonio Meza]

Negativo!!! totalmente negativo!! de nuevo no tienen claro el uso de los AI, te explico!!

Para empezar el campo IDID lo llamo así por simple nomenclatura personal, NO es la suma de dos AI, es un solo AI que se genera y pertenece a la tabla clientes del servidor central por lo tanto es una foránea para la tabla clientes de la sucursal, pero NUNCA es la suma de ambas, ejemplo con números para que se entienda mejor

Clientes (servidor)

id    Cliente

2    Pedro

5    Juan

10  Jose

Clientes (sucursal)

id     idid cliente

10    2    Pedro

41    5    Juan

50    0    Luis

Como puedes ver el ID 10 de la sucursal le corresponde el ID 2 de la central, nunca hay una suma de valor, el id 50 de la sucursal fue generado en la sucursal y al replicarse el servidor central obtendrá su propio ID que luego reemplazara al campo IDID de la sucursal, el ID 10 de la central no esta en la sucursal, y no estará hasta que lo solicite la sucursal en un alta, es decir en replicacion no pasara de la central a la sucursal, ya que es otro error de diseño jajajaja (otro tema) en fin como puedes ver cada quien usa y genera su propio ID.

ahora la tabla de facturas esta así en la sucursal

Facturas

id   idcliente fecha ....

En el servidor central

id  idcliente fecha.....

Para mandar al servidor central las facturas obtengo un Select asi en la sucursal

Select 

facturas.id, 

[Antonio Meza]

se fue el mensaje jajaja

Select 

          facturas.id

          facturas.fecha

          clientes.idid

         from facturas

        inner join clientes

          on facturas.idcliente = clientes.id

Y listo se van a replicar, ya decirte como se replican facturas en el servidor central de cada sucursal cuesta un billete jajajajajajajajaj

saludos

Antonio Meza

            

[Víctor Hugo Espínola Domínguez]

Debo suponer entonces que las tablas de facturas en las sucursales tienen diferentes ID que las replicadas en la central!

En cuanto a la limitación usando el truco expuesto anteriormente, en SqlServer usando tipo de dato BigInt para la PK la máxima cantidad de claves diferentes para 1000 locales es el insignificante número: 9.223.372.036.854.775, que a 1.000.000 registros por día en 25.269.512 de años tu tabla se rompe :-(

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

No es mi tabla ni mi modelo, como te dije es otro que he visto y es un mal diseño!!!

El hecho de crear dependencia ya es un mal diseño así de sencillo jajajaja ejemplo de dependencia

Usar una clave natural para PK, eso es crear dependencia, porque dependes totalmente de que esa clave natural no la vayan a cambiar, algo que comento Miguel, que a veces es necesario usar, sin embargo no es cierto, no es necesario usar una clave natural como PK, porque creas la dependencia, imagina que el código postal que es de 5 dígitos se vuelva de 6 que va a pasar con todos esos sistemas que tienen registrado el código postal con 5 dígitos como llave primaria?? y lo peor, lo mas tonto es que lo guardan como numérico jajaja cuando es algo que no vas a realizar operaciones matemáticas, pero para que sea un PK natural numérico si jajajaj y para hacer mas emocionante el ejemplo que el 6to. dígito sea una letra, es decir A12345, si usan PK natural seria esta la estructura 

tabla Códigos_Postales

idCP int(5)   Localidad varchar(100)

12345          Te jeringo el chico

Tabla clientes

id  idcodigo_potal   Cliente

10  12345               Telomeo Primero

Pero no solo tienes clientes, tienes proveedores, trabajadores, bancos, sucursales, ufff imagina el coas, todas las tablas que guardan el código posta??? que harías??? y las interfaces, los reportes no, no, no que hueva!!!! jajajaj

En cambio con una simple y simpática PK AI o cualquier clave subrogada lo arreglas de volon pimpom jajajaj es decir solo le agregas un campo mas, luego en el Select concatenas (para esto si sirve concatenar) los dos campos y ya tienes la presentación solicitada para mostrar en los formularios y reportes sin tocarles nada.

tabla Códigos_Postales (antes del derrumbe)

id   Codigo Char(5)   Localidad

1    12345                  Te jeringo el chico

tabla Códigos_Postales (aplausos porque fuiste la única empresa que sobrevivió)  jajaja

id   Serie Char(1)  Codigo Char(5)    Cliente

1    A                     12345                   Te jeringo el chico

Tabla clientes (sin cambios)

id      idcodigo_postal   Cliente

10     1                         Telomeo Primero

Bueno si usas buenas practicas en programación solo modificas la capa de datos para agregar y concatenar el campo y estas peinado patras jajaja 

Con cualquier tipo de clave subrogada no hay dependencia de nada, porque no son nada, son basura que sirve para obtener datos sin importar si son duplicados, alterados, violados, secuestrados etc, son solo para obtener conjuros de datos que luego LOGICAMENTE vas a darle la seguridad y manejo que se requiere.

En lo personal veo siempre conjuntos de datos, posiblemente de ahí parte como es que entiendo a los AI y los demás no pueden ver la diferencia, porque ven un TODO, yo solo veo conjuntos, todo en partes que puedo unir o desunir sin que afecte y la mayoría no!!!

saludos

Antonio Meza

[mpulla]

Hola Victor.

A Antonio nadie te va a quitar de la cabeza que los AutoIncrementales no son una panasea jaja, el metodo que tiene para la replicación es bueno.

Hay algo muy parecido a lo que explicas con postgresql (no las uso todavia) lo que se llama Global Sequences

Saludos.
Mauricio

[mapner]

http://bocabit.com/videojuegos/como-saber-si-eres-un-fanboy

[Carlos Miguel FARIAS]

Muy bueno mapner.

Y tienes razón, no voy a seguir discutiendo el tema, porque ya parece religioso y como estoy en contra de las religiones y este foro (atinadamente) no permite esos temas, solo responderé a consultas que me hagan de este tema (y si mis limitados conocimientos permiten dar al menos una idea)

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, se viene Skynet

[Antonio Meza]

jajajaja muy buena Mauricio jajajajajja

No es que crea, solo es que lo es y lo demostré con ejemplos, si alguien me puede decir otro método diferente que sea igual de sencillo pues lo acepto y lo usaría, porque siempre trato de mejorar no cerrarme, pero nadie me ha demostrado algo mejor, bueno si, los UUID pero de momento no los necesito, y se que en un proyecto mas grande si, así que puedo cambiar a cosas mejores pero cuando las haya!!!

fin del tema entonces Miguel jajajaj

saludos

Antonio Meza

[Antonio Meza]

Miguel, discutiendo??? en lo personal estaba debatiendo o razonando y analizando lo propuesto, en fin cuando alguien dice que se esta discutiendo es porque ya no tiene argumentos jajajaja y es una forma elegante de salir del debate jajajaja

saludos

Antonio Meza

[mapner]

Antonio Meza,

Te invitó a ver la definición del término "discusión" en la RAE o en cualquier diccionario o enciclopedia que encuentres, salvo que tu mismo hayas redefinido su significado. A su vez te sugiero leer el link publicado en este hilo, sobre que es un fanboy...sobre cuando menciona que se ponen agresivos y descalificantes con quienes no piensan como ellos.

Saludos

[Antonio Meza]

Gracias los reviso e investigo!!!

saludos

Antonio Meza

[Antonio Meza]

Miguel!! MIL SINCERAS DISCULPAS!!!

Acá el termino discutir se interpreta como pelear, ya revisado el significado correcto, te pido nuevamente disculpas!!!

NOTA: Como lo he dicho antes, si alguien me dice que estoy mal y en que lo estoy (caso Mapner), lo reviso, lo analizo y acepto con gusto, no me molesta, por el contrario me evita seguir cometido el error en el futuro!!!

Como le digo a mis amigos hay que ser congruentes en todo!!!!

P.D.

Gracias Mapner por decirme que estaba equivocado en cuando al termino "discusión", en cuanto a lo otro tengo muy claro lo que es un Fanboy y si realmente lo fuera no aceptara que me corrijan, y no hubiera pedido disculpas a Miguel, como lo he dicho si tu o alguien mas me demuestras otra forma mas sencilla para sustituir los AI sin hacer cosas raras jajaja con gusto los cambio, pero no me lo han demostrado pues no los puedo cambiar jejeje y no quiere decir que sea de cabeza cerrada.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Nosotros teníamos un gobierno con buenas propuestas, algunas soluciones interesantes, algunas cosas bien hechas pero cerrado a que se les mostraran alternativas o errores y lo que no les gustaban lo "modelaban" a gusto, para que pareciera que todo estaba bien.

Así nos fue.

En todos lados hay personas así.

Por suerte en este foro no hay corrupción.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe.

[d.sue]

Estimados,

En mis sistemas uso esta manera. (es un ejemplo)

id     c_articulo     n_articulo

1     00001          arroz

2     00002          coca cola

4     00003          manzana

5     00004          vino

8     00005          agua

el campo id, es AI (autoincrementable) y lo uso para identificar cada registro, en las otra tablas ( ventas, compras, kardex, etc.) uso este identificador para relacionar mis articulo.

al usuario siempre le muestro el campo c_articulo que es unico y no se puede repetir, para que pueda codifcar sus articulos, lo que me permitio posteriormente modificarlos.

id     c_articulo     n_articulo

1     A0001          arroz

2     B0001          coca cola

4     A0002          manzana

5     B0002          vino

8     B0003         agua

esa es mi manera y la veo mas segura.

saludos.

[d.sue]

Se de un caso donde usaron el DNI como PK natural para identificar a los trabajadores, y con este campo se relacionaban con las demas tablas, (boletas de pago, entradas y salidas del centro laboral, etc.)

y al final de mes se dieron cuenta que estaba errado un numero de su DNI, 

tuvieron que crearle otro registro y anular el primero.

y despues de unos años ingreso otra trabajador con el numero de DNI que estaba anulado años atras.

saludos.

[Carlos Miguel FARIAS]

Para d.sue:

Si tienes un código de artículo único c_articulo, ya tienes seguridad de que no se va a repetir.

(pk natural), que seguridad adicional te da tener una pk autoincremental?, estas forzando al sistema a tener dos indices unique (el AI y el código).

El usuario está entrando por el código (según indicas), que se gana en seguridad?, Porque en velocidad, pierdes, estás manteniendo dos índices UNIQUE.

Salvo que el c_articulo fuera muy grande, no ahorras tanto espacio en disco, y tiene que ser una bd muy grande como para que pueda impactar seriamente.

En el segundo caso, si cargaron el DNI mal, simplemente lo cambian, una pk natural puede cambiar el valor, un AI no. Y la integridad referencial, si está bien configurada, automaticamente te propaga el cambio de la pk natural a todos los puntos "foráneos" dentro de la bd.

Además, creo que tu mensaje se truncó, porque no me queda claro que paso con el otro empleado que usaba el mismo documento.

Y si no armaste integridad referencial, corres simples scripts para corregir los datos en las tablas relacionadas.

UPDATE tabla_relacionada SET nDocumento = <nuevo valor> WHERE nDocumento = <viejo valor>

El error de carga de datos, es responsabilidad del usuario entrenado, si no entrenaste al usuario, es responsabilidad del jefe del empleado que no lo hizo capacitar.

La AI puede ser una simplificación (que incluye no tener instrumentada la integridad referencial dentro de la BD, pero si usas un SGBD, y no aprovechas su potencial, es como clavar clavitos de marcos de cuadro con un martillo neumático.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza les acompañe.

[mpulla]

Hola d.sue

Lo que comenta Miguel, en cuanto a mantener 2 indices como identificadores de registro, es el precio a pagar por usar llaves artificiales, la velocidad se pierde al insertar, ya que se tiene que mantener un indice adicional.

El tamaño de los indices depende, un entero es muy mucho mas pequeño que un campo donde tienes codigos EAN 13, al tener indices más pequeños más paginas en memoria.

El pero del asunto es que el SGDB tiene que hacer más lecturas, una sobre carga que en lo personal pesa menos que los beneficios de usar llaves artificiales.

En todo caso cada uno debe evaluar los pros y contras.

Saludos.
Mauricio

[mapner]

Miguel,

Si el DNI es PK y luego de un tiempo se detecta que se debe corregir, no solo habrá que cambiarlo en su tabla maestra de (ej. Empleados) sino también en todas las otras tablas donde sea esa clave sea FK.

O sea, el impacto de tener que modificar el valor de una PK es altamente expansivo a varias otras tablas de la BD.

Ese es uno de los principales riesgos de PKs que no pueden asegurar invariabilidad en todo el ciclo de vida del dato.

La ventaja de AI en ese caso es que una vez creada, no tiene porque cambiarse. Es invariable en todo su ciclo de vida. End of Story.

La única cuestión criticable que vi en este hilo a las PK AI, son bases de datos multi nodo (ej. sucursales cada una con una BD independiente que luego se integran a una BD central por importación de datos)

Ahí hay que forzar un prefijo que asegure unicidad cuando se consoliden la totalidad de los nodos.

Saludos

[Antonio Meza]

Efectivamente como comentas Mauricio, es mas el beneficio usando claves subrogadas (artificiales) que claves naturales como PK, el problema en rendimiento solo se va a presentar al insertar registros, pero para ser honestos es de risa manejar 2 indices o mas para un servidor a estas alturas,

Ahora bien, donde si se necesita buen rendimiento es en las Consultas en los JOIN, y es ahí donde los PK numéricos las harán volar que usar claves naturales.

La ventaja de un PK Natural es que sirve para evitar duplicados de información, para mostrarle los datos al usuario, para que el usuario pueda buscar información con datos que el conoce, por ejemplo en una pantalla de búsqueda le solicitas ingrese el DNI, 

Select (Campos) from Personas where dni = ?_dni

Ya lo tienes localizado, el programador ya sabe que ID es y el usuario lo modifica el registro, entonces para actualizar ese Registro tan simple como

Update Personas Set campos = ?_campos Where Id = ?_id

En cambio si usa claves naturales y el indice esta compuesto por 2 o mas campos seria algo así

Update Personas Set campos = ?_campos where Dni = ?_Dni and sucursal = ?_sucursal

Cual Update creen que sera mas rápido!!!.

En cuanto a integridad referencial realizar una cascada para cambiar un PK natural en todas las tablas involucradas de entrada me suena a locura, algo esta mal pensado, en cambio usando Claves Subrogadas, solo se cambia el valor en la tabla origen donde esta almacenada esa clave natural en un solo registro y una sola vez, que solicitarle al servidor realice una actualización en cascada, usando claves subrogadas (artificiales) NUNCA sera necesario, mantener las relaciones desde luego entre los ID, pero no realizar tal situación.

Comentar con ejemplos es mejor que con ideas, porque muchos tienen la idea de que los AI en replicacion no funciona, yo los uso de años y sin ningun problema, expongan los ejemplos donde realmente no funcionan los AI para entonces analizarlos y ver si es correcto el uso de los mismos y el diseño de la base de datos, es como decir que VFP esta obsoleto, ok esta descontinuado, pero obsoleto en que o como para que?, decir es muy fácil, demostrar es lo bueno.

saludos

Antonio Meza

[Antonio Meza]

Miguel!!! los AI también tienes integridad referencial!!! si no como crees que se eliminarian los registros de facturas por ejemplo?

Facturas

id   Factura   fecha

1   50            01/01/2016

3   51            05/01/2016

Facturas_detalles   FK (idfactura = facturas.id)

id  idfactura  Cantidad  Importe

2   1              1              100

3   1              2              200

 

Delete for facturas where id = 1

Y listo elimino todos los registros hijos!!!! donde dices que no se puede?

Usando la factura como PK natural en la tabla de detalles necesitas un campo adicional Si o Si para identificar el registro, si no al aplicar un update se actualizarian todos los registros hijos con el mismo valor del ultimo actualizado es decir 

facturas_detalles

pkfactura   renglon   cantidad   importe

1                1             1               100

1                2             2               200

Al final usar PK AI y usar PK Natural en una tabla detalle tendras si o si 2 campos unique, pero si agregas sucursales en las facturas, con PK Ai continuas usando solo dos indices uniques, y con PK Natural ahora van hacer TRES!!!! si nos ponemos exigentes en cuanto a rendimiento de insertar registros, cual creen que sera mejor el que usara siempre 2 indices sin importar los campos naturales, o el que usa 3 o mas dependiendo los campos naturales!!!

Si gustan decirme Fanboy de los AI pues ni modo jajajaj, pero díganme donde esta la ventaja de no usarlos? pero con ejemplos no nada mas decir por decir.

saludos

Antonio Meza

[d.sue]

Ventajas que encontre de usar AI:

- Respuesta en las consultas mas rapida.

- Hacer dificil las relaciones en la lectura de las tablas al ojo ajeno.

- Aconstumbrarme siempre a hacer los select y joins, te agiliza para resolver consultas mas dificiles.

y para mi... la mas importante, ya que lo he necesitado en mas de una vez. 

ya sea para orden de codificación, ampliación de codigo o simples errores.

- Poder actualizar si se lo requiere Codigo Naturales y asi evitar para mi lo riesgoso de cambiar un codigo PK natural y hacer expansivo a las demas tablas.

ahh y para el caso de consolidación de varios locales independientes, 

se prevee con un prefijo, como dijeron... esa fue la solución.

Pero las buenas practicas son eso solo buenas practicas, 

al final si uno esta acomstumbrado a las suyas seran suficientes, 

hasta que necesite lo contrario.

Ojala me pueda haber dejado entender.

Saludos

[Carlos Miguel FARIAS]

d.sue, a partir de que dices:

"- Respuesta en las consultas mas rapida.

- Hacer dificil las relaciones en la lectura de las tablas al ojo ajeno.

- Aconstumbrarme siempre a hacer los select y joins, te agiliza para resolver consultas mas dificiles."

Pregunto:

a) Verificaste que la consulta es más rápida? que SGBD usaste? Cuantos Registros?

b) Ocultar las relaciones al ojo ajeno me parece algo raro, trabajas para la NSA? Lo aconsejable es que el sistema se autodocumente, con un SGBA apropiado, puedes ocultar la estructura de la misma de miradas ajenas.

c) Si la pk natural está bien definida, no debería ser mucho más difícil hacer un join (hay herramientas que te escriben los joins) o clausulas como USING, y la documentación?

En e caso de pasaje de claves de una natural a otras tablas, lo hace el SGBD.

En el caso de consolidación, el uso de un prefijo que indicas, ya está implicando tener una clave compuesta, y la facilidad de la AI, se fue al garete.

Cuando se empezó a programar (lenguaje máquina), se usaban (use) direcciones de memoria, todo eran índices, no existían las variables, cada dato que se manipulaba estaba asociado a un puntero de memoria. 

Luego, con assembler, en muchos casos se reemplazaron las direcciones de memoria con "tags" o "labels", que reemplazaron los punteros de memoria (absolutos e inamovibles), luego, los lenguajes de 3° generación, eliminaron prácticamente el uso de punteros de memoria, excepciones de C y algunas versiones de Pascal (entre los más conocidos), pero es lo que permite en C (y C++) servir como base para hacer S.O.

En los primeros archivos se accedía secuencial, luego acceso directo (punteros calculados), luego aparecieron los indices (ISAM. VSAM. arboles B y B+, etc.)

Y llegamos a las BD relacionales (jerárquicas y tipo red CODASYL usaban también punteros pero internos).

Y hasta casi fines de los '90 casi nadie armaba BD con AI. Luego, para ciertos tipos de sistemas (Objeto Relacional) o aquellos que no contaban con posibles claves naturales (hay muchos de esos sistemas, los únicos ejemplos que se dieron en el foro fueron los que aporté), son de aplicación los AI.

Las justificaciones que veo son simplicidad de programación, análisis de requerimientos limitado, no uso de la potencia de los SGBD completo.

Tanto que indican que son necesarios los joins, en muchos casos, cuando consulto una entidad débil, lo único que necesito de la principal es el valor de su valor unique, si uso AI, debo indefectiblemente hacer el JOIN, si uso natural, ya la tengo en la débil.

Y no hablemos de los procesos de documentación.

En fin. Para PK tenemos varias recetas, cocinar siempre con la misma, no es aburrido?

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, después de todo un AI es una clave calculada

[Antonio Meza]

Hay quienes programamos en 3 o mas capas, hay quienes programan en una capa, al final la aplicación funciona sea una capa o dos o tres, o cuatro o las que sean.

Pero el mantenimiento de una aplicación mediana - grande indudablemente que es mas sencillo si esta dividido en varias capas.

En las base de datos se puede aplicar el mismo concepto de dividir en capas los datos, es decir, por una lado tienes los PK subrogadas (AI, UUID, manuales) para el manejo de los registros y por otro lado tienes toda las restricciones y validaciones, permisos, seguridad, etc, etc, necesarios.

saludos

Antonio Meza

[Mario Escudero]

Hola con todos:

Acabo de leer todo el hilo y he visto de todo.

En conclusión: habría algún problema si sólo uso el Id autoincremental como Código para el usuario de un Producto, Cliente, etc?

Por último, en qué casos se tendría que usar tablas de correlativos?

Gracias

PD: acabo de empezar a incursionar en FoxyDB con MariaDB.

[Carlos Miguel FARIAS]

Mario: Si leíste todo el hilo de autoincrementales y no entendiste, que puedo decir, que sois un tipo totalmente normal. Porque entender algo de una IIA Ward como esa, implicaría que no necesitas hacer la pregunta que estas haciendo.

Si usas FoxyDB, deberás usar los índices que su autor indica como apropiado.

Usar otra cosa te impediría aprovechar las ventajas de usar dicha herramienta.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe

[Mario Escudero]

Hola Carlos.

Tengo claro que debo usar los ID Autoincrementales pero mi pregunta iba por el lado de si era obligatorio usar los correlativos....

Gracias

----

Mario Escudero

www.cheff2000.com

Mov 995-817087  Rpm #995817087 

[Mario Escudero]

Otra consulta era de que si es obligatorio usar correlativos, esto va para todas las tablas o sólo para algunas? Cuáles?

Gracias

----

Mario Escudero

www.cheff2000.com

Mov 995-817087  Rpm #995817087 

[Mario Escudero]

Hola d.sue:

Dices:

"al usuario siempre le muestro el campo c_articulo que es unico y no se puede repetir, para que pueda codifcar sus articulos, lo que me permitio posteriormente modificarlos..."

En caso que c_articulo lo uses como un simple correlativo que no tenga por qué modificarse, es necesario usarlo o sólo bastaría con el Id AI que también es único?

Gracias

[Mario Escudero]

En resumen, el FoxyDB obliga a usar correlativos o es opcional?

Gracias

----

Mario Escudero

www.cheff2000.com

Mov 995-817087  Rpm #995817087 

[mapner]

Miguel,

Este hilo de Campos Autoincrementales se termina de resolver en la corte internacional de La Haya...

Hoy es viernes?

[Antonio Meza]

Hola Mario!!

Los correlativos son opcionales, por ejemplo la tabla de Clientes, a muchos programadores les gusta generar un correlativo del numero de cliente, en mi caso no lo uso.

El correlativo del Cliente puede servir para facilitar la búsqueda, pero si hay 1000 clientes no creo que nadie se aprenda tal cantidad de numeros jajaja, en mi caso no lo uso y cuando el usuario necesita buscar solo le solicito busque por su nombre o apellido, o cualquier palabra contenida en el nombre del cliente.

En el caso de las facturas, tickets si se ocupa un correlativo por ejemplo!!

Conclusion, FoxyDb es opcional.

saludos

Antonio Meza

[Mario Escudero]

Hola mapner:
Sólo espero una respuesta sencilla como que si los correlativos son opcionales u obligatorios en FoxyDb.
Gracias

Mario Escudero
Rpm #995817087
www.cheff2000.com

Enviado desde mi móvil

[mapner]

Mario,

Disculpa la humorada, se que tu pregunta es sencilla pero el hilo de Autoincrementales se ha debatido más que un simposio de física nuclear.

No conozco ni uso FoxyDB pero entiendo que es una buena librería de abstracción de datos remotos de Antonio Mezza.

Sobre autoincrementales lo que te sugiero es lo siguiente. Simplemente define el tipo de campo AI en tu tabla y que el servidor se ocupe de administrarlo. Obviamente, luego de insertar un registro debes recuperar desde el cliente el ID generado y para eso hay varias técnicas. 

Saludos

[Mario Escudero]

Eso mismo es lo que hago. En conclusión, el código correlativo adicional sería un campo más opcional, correcto? Porque pienso que si no se va a modificar para nada entonces bastaría usar el Id AI también como el código del producto, cliente, etc...
Gracias

Mario Escudero
Rpm #995817087
www.cheff2000.com

Enviado desde mi móvil

[Antonio Meza]

Hola Mario!!!

Los campos ID autoincrementables son para uso interno, el usuario no debe ni necesita conocerlos ni saber porque y para que existen, para relacionar tus tablas usaras los campos ID, pero para mostrar al usuario necesitas los campos clave, código, etc, 

El código de producto o código de barras lo usas para el usuario, al igual que un correlativo pero NUNCA para relacionar con otras tablas pues pierdes beneficios de usar los ID IA.

saludos

Antonio Meza

[d.sue]

Mario,

Si lo que deseas es ahorrar una columna por que consideras que no es necesario, nadie te impide no hacerlo,

puedes usar el ID autoincremental como codificador para el usuario y para relacionar con otras tablas, 

el cual lo asigna el sistema y no se podrá cambiar (en teoria).

Pero tienes que tener en cuenta que el autoincremental nunca se va a repetir pero si se puede saltear, al ocurrir un error el contador se saltea de numero.

por lo que al insertar un registro y el AI te asigna 345 no significa con toda seguridad que tienes 345 items matriculados.

muchos podrán decirte que no es una buena practica, pero otros dirán lo contrario. 

(yo actualmente tengo los 2 métodos en diferentes módulos y de verdad los 2 no me generan problemas)

solo tu después de la experiencia podrás tomar posición.

saludos

[Antonio Meza]

Los Autoincrementables solo sirven para relacionar tablas, identificar un registra de forma inequívoca, actualizar y eliminar registros y buscar cuando se conoce el valor del ID.

Para lo que no se debe usar es para que el usuario final interactue con el, que sustituya un campo clave o código, eso Nunca se debe hacer, si se puede pero no se debe, es como el que dice que usar variables publicas si se puede, pero no se debe,

saludos

Antonio Meza

[Miguel Canchas]

Evítate problemas y crea un campo incremental por cada tabla y le asignas PK.

 

MK

[Mario Escudero]

Antonio, viéndolo así creo que es bueno contar con un correlativo ya que, como su nombre lo dice, mantendrá la secuencia o correlatividad real y visual de los registros (artículos, clientes, proveedores, etc).
Gracias nuevamente
Un abrazo

Mario Escudero
Rpm #995817087
www.cheff2000.com

Enviado desde mi móvil

[mapner]

Los campos AI son datos "NO SEMANTICOS" o sea no representan nada del modelo del mundo real, por lo que para el usuario no tienen ningún significado

Que el usuario vea la ficha de Clientes con su PK generada con AI no tiene nada de malo. Pero debes darle claves alternativas de búsqueda.

Para productos no es lo mismo PK que Código, por ejemplo en un libro el código puede ser el ISBN, más allá del PK / AI que tenga.

Saludos