Funcion de Campos ID

[Carton Jeston]

Veo que hay mucha confusion en los campos ID y para que sirven, sobre todo cuando se confunde ID de la base de datos con la clave principal de un registro. No es lo mismo el codigo de articulo de la base de datos que el indicador ID que es unico de ese registro. Cuento esto para que no salgan respuestas erroneas en este tema ;-)

En mi caso,Los campos ID de las bases de datos, en su dia los cree autoincremental en dbf porque me resultara mas facil para portar a otras db cuando integre foxydb. La utilidad que le doy es cuando filtro una base de datos con datos identicos me identifica inequivocamente el registro seleccionado:

en unas lineas de detalles de un albaran...

id(oculta)  codigo nombre         precio
15023       1         chocolate              1
15024       2         azucar                   3
15025       1         chocolate              1

Es un ejemplo burdo de unas situaciones que se dan mas complejas, si decido hacer algo con un campo concreto desde un cursor seleccionando una de esas lineas, si pulsas chocolate no hay forma de distinguir la primera y ultima linea y con el ID si. Esta es la ventaja que yo le veo pero ¿hay otras?

un saludo y perdon por el megaladrillo que acabo de poner :D  :D :D

[Carlos Miguel FARIAS]

Entramos otra vez en la eterna discusión de usar identificadores auto-incrementales o claves naturales.

Cuando tengas que portar a otra base de datos, vas a tener que tener mucho cuidado con las AI, porque en la BD destino va a intentar crearlas desde 1 e ir de 1 en 1.

Si en la tabla de origen tienes algunas filas borradas, se de-sincronizará la numeración y se destruirán las relaciones. Si tienes que recargar desde origen, más problemas, porque los AI siguen incrementandose en destino o lo vuelve a 1, pero si en destino cargaste algo, como queda? un bolonqui.

Si el sistema debe manejar datos de dos sucursales que no están permanentemente en línea, con AI, cuando tengas que sincronizar las tablas equivalentes vas a tener inconsistencias p.e. Suc. A cargaron XXX con AI 5 y YYY con AI 6 y en Suc. B cargaron YYY con AI 9 y XXX con AI 11, porque en AI 10 cargaron ZZZ.

Al juntar para consolidar tienes un gran problema.

Hice sistemas con AI pero luego me encontré con problemas al consolidar tablas cargadas por separado.

Prefiero usar claves calculadas cuando no dispongo de naturales.

Saludos: Miguel, La Pampa (RA)

Larga Vida para discutir

Que la Fuerza los acompañe, AI no empareja

[Antonio Meza]

Miguel!!! no es como dices, o no se que servidor de base de datos usas pero cámbialo de volada jajajaj

Entramos otra vez en la eterna discusión de usar identificadores auto-incrementales o claves naturales.

Cuando tengas que portar a otra base de datos, vas a tener que tener mucho cuidado con las AI, porque en la BD destino va a intentar crearlas desde 1 e ir de 1 en 1.

Para empezar en una replica los valores ID se obtienen en la base de datos origen y al replicarlos ya no se generar nuevos, se usan los que esta enviando la base de datos origen por eso no va a existir una inconsistencia como mencionas. Es decir un campo ID Autoincrementable cuando se inserta un registro tienes 2 opciones enviarle el valor o que el servidor genere uno, lo correcto es que en la base de datos origen se genere por el servidor y en la replica utilice el ID que ya fue generado, seria muy pero muy pero exageradamente muy TONTO que en la replica generar nuevos ID, que a caso replicar no es mas que la información que se genera en el Servidor A este exactamente igual en el servidor B??? si no fuera así que sentido tiene la replica si va a generar nuevos valores???

Si en la tabla de origen tienes algunas filas borradas, se de-sincronizará la numeración y se destruirán las relaciones. Si tienes que recargar desde origen, más problemas, porque los AI siguen incrementandose en destino o lo vuelve a 1, pero si en destino cargaste algo, como queda? un bolonqui.

No es correcto esto que mencionas, porque insisto la replica va a usar los valores de la base de datos origen, no puede ni debe generar nuevos ID, debe si o si usar los datos reales que están en la base de datos origen.

Si el sistema debe manejar datos de dos sucursales que no están permanentemente en línea, con AI, cuando tengas que sincronizar las tablas equivalentes vas a tener inconsistencias p.e. Suc. A cargaron XXX con AI 5 y YYY con AI 6 y en Suc. B cargaron YYY con AI 9 y XXX con AI 11, porque en AI 10 cargaron ZZZ.

Al juntar para consolidar tienes un gran problema.

Si y No!!!! es decir lo que comentas es cierto pero también no es cierto jajajajajaja, Una empresa que va a manejar sucursales y que en cada sucursal manejara sus movimientos y luego estos los quiere consolidar en un servidor, te comento que hay infinidad de soluciones, por lo tanto Si hay que tener cuidado porque puede presentarse el problema que comentas, pero se presenta porque no se planearon bien las cosas, No es un problema de los AI, es un mal planteamiento, y a demás también depende del servidor de base que uses, si usas MariaDb o Mysql se presenta el problema que dices al usar tablas InnoDb por que los AI se generan por un incremento de un solo campo, pero si usas MyIsam no tendrías problemas porque te permite generar campos ID combinados, por lo tanto cada sucursal tendrá su propio id aun cuando estén en servidores separados y se puede sincronizar sin problema alguno, si usas FireBird también puedes hacer lo mismo usar campos ID que se autoincrementen por uno o varios campos como Sucursal.

Como puedes ver no es problema de los AI, si no del desconocimiento del programador o del que planeo la base de datos y que servidor de base de datos usar. pero insisto hay infinidad de soluciones donde los AI siguen siendo una mejor alternativa.

Hice sistemas con AI pero luego me encontré con problemas al consolidar tablas cargadas por separado.

Prefiero usar claves calculadas cuando no dispongo de naturales.

Como mencione anteriormente todo depende de lo planeado y que servidor de base de datos estas usando, no puedes decir que los AI son malos solo porque te fue mal, o porque solo usas X servidor de base de  datos y no puede generar AI por combinación de otros campos, o porque al replicar no tiene la opción de usar los AI de la base de datos origen. 

El consolidar tablas depende de muchos factores y los AI no tienen nada que ver, uso MariaDb con Innodb donde no puedo obtener AI combinados con otros campos y usan mis sistemas en sucursales separados del servidor central y no tengo problemas con los AI y puedo consolidar información, por eso insisto todo depende como se platee el problema y que solución se le va a dar!!!

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Antonio: No hable de replicar una base de datos, hable de juntar datos de dos bases de datos, aún generadas por un mismo software. Caso típico de sucursales que luego deben consolidar datos entre si o contra un servidor central, pero que generan registros por separado.

Una solución correcta no parte de tal o cual motor de base de datos. Como bien dices parte de como planificas las cosas (o diseñas). Durante 25 años trabaje con autoincrementales pero en los primeros años sistemas mainframe no consolidábamos (era en realidad una sola máquina con TB), pero luego, con PCs inteligentes empezó la maroma cuando consolidas con diskettes (o por lo que sea no están en línea).

En fin. Si te cierras en tu solución, tienes mi permiso. No me cierro por lo que me fue bien o lo que me fue mal (solo comparto donde están las piedras para que otros no las pateen) y propongo soluciones para esquivar esas piedras, las tomas o las dejas.

Tengo mis principios fundamentales, pero unos mangos tengo otros, o algo asi

Para mañana (Groucho Marx) https://verne.elpais.com/verne/2015/10/02/articulo/1443795977_979550.html

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, vayan reservando, cada vez menos lugar en Ezeiza!!

[Antonio Meza]

No me estoy cerrando y siempre lo he dicho y lo repito si puedo aprende algo mejor de lo que ya se!!! pues cambio en ese momento, no me voy a quejar porque otra persona me enseñe a trabajar bien al contrario le voy a agradecer infinitamente!!!! así que no va por ahí el asunto!!! al menos yo no me cierro!!

Precisamente como hay mucha desinformación en Internet es bueno compartir buena información.

En tu experiencia tuviste problemas con los AI, en mi experiencia no los he tenido, así que es bueno que se conozcan ambas experiencias y que ya los demás decidan cual usar, al final de todo los AI no son malos solo hay que saber para que se deben usar y como se deben usar. 

Si realmente fuera como dices, porque SqlServer, FireBird, MariaDb / Mysql, en sus ejemplos siempre usan AI si fueran tan pero tan malos ni los mencionaran o los usaran no crees? realmente el problema esta en que no los saben usar, y al no saber usar algo se comente errores.

Porque el porcentaje de desinformación del uso de los AI es grave, los usan para que el usuario busque información o los imprimen o muestran en reportes o pantallas, y eso entre otras cosas demuestra claramente que no saben o no tienen la mas mínima idea de como usarlo y por eso surgen los problemas.

saludos

Antonio Meza

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

Estoy medio rubia, qué son los "campos ID combinados"?

Saludos,

Víctor.

Lambaré - Paraguay.

El 7 de diciembre de 2017, 19:19, Antonio Meza<solv...@gmail.com> escribió:

[Carton Jeston]

Veamos, tenemos claro en este punto que cuando hablamos de ID es un dato oculto accesible solo por el  programador y la base de datos. Algunos usan un numero autoincremental (AI) y otros una cadena natural identificativa. No confundir con un codigo de articulo, cliente o lo que sea que ocurre en muchos hilos. Vamos a ampliar el ejemplo anterior colocando los dos ID juntos a modo ilustrativo, aunque se que hay programadores que usan los dos metodos segun que cosas...

http://blogs.solidq.com/es/sql-server/claves-naturales-vs-artificiales

Veamos una factura con sus lineas de detalle, tenemos el campo id AI y el campo id NATURAL que se compone de dos OFICINA+SERIE+NUMERO_FACTURA (2+2+7)

CABECERA
id(AI)  id(NATURAL)     serie  numero     fecha             cliente
325    01AA0000254   AA      0000254   08/12/2017    512

LINEAS
id(AI)  id(NATURAL)        codigo nombre          precio
15023 01AA0000254      1         chocolate              1
15024 01AA0000254      2         azucar                   3
15025 01AA0000254      1         chocolate              1

Corregirme si me equivoco en que cada tabla tiene su propia numeracion id separada. Tener en cuenta que trabajo en dbf pero quiero saltar a bases de datos de la mano del foxydb posiblemente FB o PG. Y mira que he tocado mysql años manteniendo un foro y nunca me fije en ese detalle jajajaja

Con el numero natural hay una relacion inequivoca entre la cabecera y las lineas y de paso hemos añadido la oficina por si hay que unir tablas en el futuro.

Ahora bien, imagina que por un momento quiero filtrar en un grid las lineas que contienen chocolate y quiero eliminar una.
id(AI)  id(NATURAL)        codigo nombre          precio
15023 01AA0000254      1         chocolate              1
15025 01AA0000254      1         chocolate              1

Quiero borrar la segunda pero ambas son identicas excepto en el ID-AI. Al pasarle el ID-AI se sin error y sin necesidad de artificios que pertenece a la 15025 de la tabla principal y para mas seguridad si le paso ID-NATURAL puedo confirmar sin errores que pertenece a ese documento (no se si aqui exagero un poco).

Al pasar a otra base de datos el id-AI puede alterarse en algun momento pero la ID-NATURAL no y no importara mucho porque al consolidarse seguira trabajando como siempre.

No tengo ni idea de esto, solo es lo que supongo y evitar problemas como el de arriba y otros futuros que no conozco y estan comentando acertadamente. ¿que opinan?

[Carton Jeston]

Buena pregunta. Quizas unen ID1+ID2 como una ID unica y ahi si se altera algun valor puede montar un gran lio.

La otra interpretacion positiva en campos combinados es cuando tienes ID-AI por un lado para unas cosas y ID-NATURAL por el otro, combinar ambos valores segun que acciones requieras pero nunca unir ambos como si fueran una unica ID.

¿van por ahi los tiros?

[Carlos Miguel FARIAS]

Cuando era pequeño, en Argentina llamaban Combinados a equipos de audio que podían reproducir discos de vinilo y también podían reproducir radio (Amplitud Modulada!!!).

Pero coincido con Antonio debemos aprender:

Aqui algo para ver:

http://blogs.solidq.com/es/sql-server/claves-naturales-vs-artificiales 

Me gusta más este, donde demuestra cuando combiene una u otra: http://tubasededatos.blogspot.com.ar/2011/03/natural-vs-claves-suplentes-en-sql.html

He tenido que desarrollar sistemas donde la única solución era usar AI porque los datos al momento de comenzar la carga no tenían datos para componer claves naturales.

Si hoy tuviera que rediseñar el sistema, reemplazaría los AI por otro tipo de algoritmo para generar la clave artificial, porque el problema de carga sigue siendo igual.

He tenido sistemas con AI funcionando por 20 años algunos (en fox uno por 15) usando AI sin mayores problemas, pero sin necesidad de consolidar datos.

Desde el punto de vista de proceso físico un AI ocupa muy poco espacio y por ello es inherente-mente rápido.

La solución de que en myisam anda pero no en innodb es un palo en contra de la justificación de usar AI, myisam no soporta transacciones (VFP con dbf si lo soporta). myisam, para sistemas comerciales no es de fiar, que lo usen va por desconocimiento (Ojo, en sistemas que no manejan operaciones con dinero, simplemente acumulan registros, lo he usado sin problemas).

Las claves sustitutas o artificiales son necesarias, pero cuando son necesarias, no siempre, no para todo.

Ejemplo, tengo datos de clientes con AI, CUIT es identificador personal del cliente otorgado por el estado.

Cliente = {id, CUIT, apel, nombre, etc.}, donde PK, UNIQUE (negrita subraya es primaria, negrita solo es UNIQUE)

por regla de negocio, CUIT no puede repetirse, no puede faltar.

Esto implica tener dos indices, por id y por CUIT ya que es la única forma de evitar CUIT duplicado, el sistema la PK la resuelve sin problemas pero además debe validar el índice UNIQUE. Doble proceso.

En ese caso no es la mejor solución.

Tengo un sistema con datos que guarda noticias, las noticias no tienen datos que puedan crear una clave natural

Ahí, indefectiblemente tengo que usar una clave artificial. Lo mas simple usar AI

Si tengo que consolidar dos tablas de noticias, no hay problema si tengo que regenerar los AI, si hay datos en archivos vinculados se puede complicar un poco pero no es esencial

Por lo tanto, que usar depende del sistema, ninguna solución es única, alguna puede ser mejor que otra, alguna puede ser más problemática, pero cuando eliges una solución, debes estar abierto a usar la que corresponde.

Saludos: Miguel

 

[Carlos Miguel FARIAS]

Carton, tu modelo tiene errores de diseño, tanto si lo enfocas como modelo basado en AI como en claves naturales.

Veamos: PK y UNIQUE, foránea

Si usas un modelo AI

Factura = {idFac_AI, tipoFactura, nSucursal, nCorrelativo, <otros datos factura>}

Productos = {idPro_AI, codigoproducto, <otros datos producto>}

Detalle = {idFac_AI, nRenglon, idPro_AI, <otros datos detalles>} 

(si un producto no puede repetirse en detalle, nrenglon es reemplazado por idPro_AI

Detalle = {idFac_AI, idPro_AI, <otros datos detalles>} 

Si usas un modelo con naturales:

Factura = {tipoFactura, nSucursal, nCorrelativo, <otros datos factura>}

Productos = {codigoproducto, <otros datos producto>}

Detalle = {tipoFactura, nSucursal, nCorrelativo, nRenglon, idPro_AI, <otros datos detalles>} 

o, de no repetir productos

Detalle = {tipoFactura, nSucursal, nCorrelativo, idPro_AI, <otros datos detalles>} 

En lo que tu planteas, tu clave natural es en realidad una clave calculada, surge de una expresión. Un índice compuesto por mas de un campo en dbf te exige tener un índice compuesto como tu lo pones, pero no son parte de los datos, es la forma de crear el índice.

Como tu lo planteas, creas redundancia de datos.

Y lo que haría en mi caso es que tanto idFac_AI e idPro_AI, reemplazarlos por idFac_CC y idPro_CC, que es eso?, a eso va en otro post.

Saludos: Miguel

[Antonio Meza]

Te hace falta hacerte la operación jarocha jajajajaja para que ya seas Rubia completa!!! jajajajaja

https://firebird21.wordpress.com/2013/08/10/claves-primarias-simples-o-compuestas/

El termino no fue el adecuado pero para que quede asentado en el acta no era "Campos Id Combinados" era "Claves Primarias Simples o Compuestas" jajajajaajaja

Nota: Como pueden ver si me equivoco lo acepto y corrijo y no me molesta al contrario voy mejorando y otros simplemente no aceptan sus errores jajajajaja

P.D. Por cierto victor ya no contestaste el otro tema que me hiciste preguntas??? que paso??  jajajajajajaj

saludos

Antonio Meza

[Antonio Meza]

Miguel veo que no usas AI porque a veces es necesario usar campos Unique, como que es una regla tuya que si se va a usar 2 indices ya no usaras AI, realmente vale la pena sacrificar el rendimiento global de la base de datos por una simple tabla al eliminar un campo e indice?

por regla de negocio, CUIT no puede repetirse, no puede faltar.

Esto implica tener dos indices, por id y por CUIT ya que es la única forma de evitar CUIT duplicado, el sistema la PK la resuelve sin problemas pero además debe validar el índice UNIQUE. Doble proceso.

En ese caso no es la mejor solución.

Es claro y no hay dudas que un Indice de un campo AI es mucho menor a un campo clave natural en este caso CUIT, entonces en la tabla CLIENTES, como bien mencionas necesitas el PK para el campo ID y adicional el indice Unique para el campo CUIT, eliminemos el AI y nos quedamos así como indicas 

Tabla Clientes

Pk_Cuit    Nombre, etc

Como eres muy cuidadoso en los procesos, en el tamaño de los indices, en el tamaño de las tablas, no se porque estas pasando por alto las tablas donde usaras relaciones con la tabla clientes??

Es decir si usamos CUIT como PK en la tabla clientes y sabemos que ese indice es mas grande que un AI, entonces al usar FK con otras tablas serán tablas con mayor tamaño, ejemplo la tabla Facturas

Tabla: Facturas

idFactura  FK_Cuit   serie  folio, etc

Tabla Clientes_Domicilios

Fk_Cuit Direccion, codigo_postal, etc

No se si me logre explicar, prefieres sacrificar un indice y un campo AI y desde luego no usar el AI porque esa tabla hará 2 procesos, sabiendo que un catalogo de Clientes no tiene mucho movimiento, como si lo tienen las Facturas, entonces realmente ganas algo mejor al final?, analizando el diseño global de la base de datos desde mi punto de vista personal NO!!! porque tus tablas donde usaras FK al campo CUIT serán mas grandes!!!

saludos

Antonio Meza

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

Entonces deja de ser PK AI y la PK se convierte en compuesta de 2 columnas.

P.D. Acabo de contestar, no lo había hecho antes porque me dije "me doy..."

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Me falto comentar lo mas importante, un AI es un valor interno para uso exclusivo del programador y de la base de datos y nada mas!!! que otros seudo programadores quieran agregarle atributos que no le corresponden ya no es problema de los AI.

Por lo tanto un AI no se debe usar para una regla de negocios, si intentas usar un AI como una regla de negocios entonces no sabes usar los AI, si intentas mostrar en un formulario, reporte, archivo exportado, que el usuario busque por el valor de un AI, e insisto que lo uses para validar una regla de negocios, entonces definitivamente no saben usar los AI.

Repito si no sabes usar algo sea lo que sea al final tendrás problemas o errores porque no lo saben usar, y no es problema del AI, el problema esta en que no lo saben usar y eso es lo que en internet abunda muchos link de temas Naturas Vs AI pero claramente los que tratan de no quedar mal con uno ni con otro le atribuyen detalles a los AI que no le corresponden y nace el debate tonto por desconocimiento.

En conclusión, se requieren 2 indices para una tabla como Clientes? SI, porque? porque el AI no tiene nada que ver con la regla de negocios que indica que se puede o no duplicar un CUIT.

saludos

Antonio Meza

[Antonio Meza]

Sigue siendo un AI porque el servidor se encarga de generarlo, la diferencia es que tendrás un incremento según el valor del campo combinado. ejemplo

Facturas

id idsucursal serie folio

1  1

1  2

2  1

3  1

2  2

3  2

Por decirlo vagamente tendrás un valor ID por sucursal que el servidor se encarga de incrementar o generar, en el caso de MariaDb y Mysql solo lo puedes hacer usando tablas MyIsam, en InnoDb no es posible y desconozco el motivo técnico, pero me ha bastado y sobrado usarlo de forma simple.

saludos

Antonio Meza

[Antonio Meza]

Carton si la tabla que mencionas en tu ejemplo es de Detalle te hace falta un campo que permita identificar a la tabla principal de este detalle, es decir donde quedo la bolita? jajajaja

en unas lineas de detalles de un albaran...
id(oculta)  codigo nombre         precio
15023       1         chocolate              1
15024       2         azucar                   3
15025       1         chocolate              1

Debe ser así

id(oculta)  idAlbaran codigo nombre         precio

15023       3               1         chocolate              1
15024       3               2         azucar                   3
15025       3               1         chocolate              1

saludos

Antonio Meza

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

Sigue siendo AI, pero solo una parte de la PK, esta es compuesta por una columna Int y otra AI

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Tu ejemplo tiene detalles, la tabla Cabecera para empezar no esta normalizada, pues tienes un campo repetitivo, es decir id(NATURAL) es la suma de otros campos que ya tienes en la misma tabla por lo tanto no esta normalizada, mejor crea un Indice compuesto y úsalo como PK!!!

No le veo sentido usar un campo AI si ya te decidiste a usar campo Natural, que sentido tiene? o que sentido le vas a dar al AI hablando de la tabla cabecera a mi parecer lo veo de mas pues no lo usas en la tabla detalles.

En la tabla de detalle me parece bien usar el AI para identificar los registros y usar el ID Natural para relacionar con la tabla Cabecera, entendiendo que eliminas el AI de la tabla cabecera porque estaría de mas pues no lo usas para nada en la de detalle.

Hay que tener mucho cuidado al planear una base de datos, es algo que requiere mucho análisis y estudio, no es algo que se debe tomar a la ligera porque un mal diseño hará que tanto la programación, administración, consultas, reportes etc, sean complicados.

Tu temor es como poder tener un servidor por sucursal y luego unificar la información en la Matriz, hay muchas formas de solventar el problema, y va desde que servidor de base de datos vas a usar, el diseño de la base de datos y que información realmente vas a consolidar, es decir toda, parcial, concentrados, etc!!! hablar de unificar o consolidar información sin requerimientos es simplemente hablar en general y el abanico de opciones es infinito, en cambio si tienes claro que es lo que quieres pues las cosas se reducen y se puede dar o recomendar soluciones.

Un error que he visto y lo veo como error de forma personal, tienes Servidor Principal, Sucursal A y Sucursal B, es decir tienes 3 bases de datos donde se realizan operaciones todos los días, un error común es subir toda la información de las sucursales en la misma base de datos del servidor Principal, si se quiere consolidar es necesario tener una base de datos Consolidada que trabaje independiente de los otros 3, para que ensuciar (termino vulgar jajaj) la base de datos Principal con información que ya tienes en sucursales, al rato los respaldos de la principal serán enormes, por darte un ejemplo, en cambio si tienes un base de datos donde puedas consolidar la información de las 3 es mejor y mas beneficios, si se rompe o daña la puedes reconstruir a partir de las otras 3, de nuevo solo un ejemplo de los muchos que hay, a lo mejor los requerimientos solo piden globales por mes, y no llenas la base de datos con detalles.

En fin no te preocupes por como consolidar información, mejor ocúpate en que información quieres consolidar y a partir de ahí poder decidir si te apoyas en el servidor de base de datos, en generar procesos alternos, etc, etc.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Con Antonio no nos ponemos de acuerdo en las claves artificiales.

El las quiere AI yo las quiero ACA (Automatic Computed and Auditable)

En lo demás, palabra mas palabra menos, coincidimos, igual, prefiero las naturales (bah, si las siliconas no se notan, segual)

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe

[Antonio Meza]

Con DBF uso claves naturales pues los AI en dbf son mas problemas que beneficios, con servidores de bases de datos uso AI por los beneficios ya mas que expuestos jajajaja

P.D. Mi intensión no es tener la razón si no mas bien eliminar los mitos sobre los AI, es que son muchos y claramente están porque se desconoce el verdadero uso que hay que darles.

Por cierto aprendí con las naturales y ahora por mas natural que busques ya hay mucha artificial jajajajajajajajaj

saludos!!!
Antonio Meza

[Carlos Miguel FARIAS]

No me sorprende de que haya mas artificial que natural, todos quieren cantidad, no les importa la calidad.

[HernanCano]

Antonio:

Siempre he considerado que los campos con "consecutivo automático" son muy adecuadas en programación, y el hecho que los motores externos (y/o las DBFs) los tengan de forma "nativa" nos facilita las cosas.

Mucho de lo que has dicho aquí está muy chévere para un artículo bien organizado.

Me gustaría conocer más sobre lo que mencionas de "claves primarias compuestas".

¿Tienes algún doc al respecto? ¿tuyo o de alguien más?

Gracias.

[Carton Jeston]

Bueno, ahora me toca explicar de nuevo cual es la situacion y el porque del ejemplo. Si falta algo elemental era por no poner mas elementos que diesen lugar a la confusion. Actualmente este es el diseño de las dos tablas.

CABECERA
id(AI)    serie  numero     fecha             cliente
325      AA      0000254   08/12/2017    512

LINEAS
id(AI)     serie  numero     codigo nombre          precio
15023   AA      0000254   1         chocolate              1
15024   AA      0000254   2         azucar                   3
15025   AA      0000254   1         chocolate              1

Ambas se relacionan por la serie y el numero, la id-AI se genera independientemente en cada tabla. Mi duda era si era correcto asi con id-AI independientes en cada tabla y si en un motor de bases de datos trabaja del mismo modo.

¿porque uso la id? Hace un par de años hice una pruebas de aproximacion usando foxyDB y Firebird y me encontre que FoxyDB lo necesita para su magia interna y para convertir todas las tablas DBF en una DB Firebird el unico error que me daba era que no existia un campo ID, asi que lo incorpore a las tablas libres por adelantar trabajo futuro.

Esa id me viene bien en casos como el anterior, hago un cursor con sql (incluyendo la id) solo con las lineas de chocolate y si selecciono la segunda linea de chocolate se que corresponde a la ID 15025 de la tabla original. Era un burdo ejemplo pero lo mas sencillo que se me ocurrio. Si el id-IA lo estaba numerando mal, este uso tampoco era correcto y queria averiguarlo.... pero la cosa se fue de madre. :D :D :D

No tengo necesidad de numero de oficina pero me llama la atencion del problema que tuvo el compañero y en el futuro no quiero encontrarme con que podia haber evitarlo. Asi que aventure esto, la id se la dejo a la base de datos/foxydb y genero un numero natural, pero igual ahi esta mi error porque al no tener claro si deben ser id-natural con numeracion independiente en cada tabla o se puede usar de relacion entre cabecera y lineas.

CABECERA
id(AI)  id(NATURAL)     serie  numero     fecha             cliente
325    01AA0000254   AA      0000254   08/12/2017    512

LINEAS
id(AI)  id(NATURAL)        codigo nombre          precio
15023 01AA0000254      1         chocolate              1
15024 01AA0000254      2         azucar                   3
15025 01AA0000254      1         chocolate              1

Sin saber mucho mas del tema y estar un poco confundido por el exceso de informacion, al dia de hoy si tuviera que diferenciar oficinas sin usar numeros naturales haria esto:

CABECERA
id(AI)   oficina serie  numero     fecha             cliente
325      01      AA      0000254   08/12/2017    512

LINEAS
id(AI)     oficina serie  numero     codigo nombre          precio
15023   01       AA      0000254   1         chocolate              1
15024   01       AA      0000254   2         azucar                   3
15025   01       AA      0000254   1         chocolate              1

Y no se hasta que punto es optimo poner oficina en las lineas teniendo en cuenta lo que engordan las tablas de detalle, pero esta claro que es necesario a la hora de combinar bases de datos distintas.

En fin, tenia una duda sencilla, ahora tengo dos jajajaja

Aclaremos primero el uso que le estoy dando de la ID-IA de cara al futuro usar foxyDB y firebird o Postgre. Despues de eso podemos ver el mismo ejemplo pero con una ID-NATURAL y con esa proyeccion futura. Si os parece bien, porque sois tan apasionados que se os olvida porque empezamos a hablar :D :D :D

Yo tengo claro hasta ahora que segun que cosa, un sistema u otro puede ser el optimo, que no hay uno mejor que otro.

[Carlos Miguel FARIAS]

Una solución que propongo:

Facturas = {idFactura, cTipo, nSucursal, nCorrelativo, <otros datos factura>}

Detalles = {idDetalle, idFactura, nRenglon, idProducto, <otros datos detalle>}

Donde idFactura y idDetalle son Algoritmo de Calculo Auditable  (ACA) con algoritmo basado en idPC, idUsuario, Fecha y hora hasta milisengundo (un AI es una calculada con algoritmo correlativo)

Si usas autoincremental, hasta que el sistema no te retorno el id generado para una factura, no puedes insertar los detalles, en cambio con ACA, como la clave se genera independientemente del contenido de los respectivos autoincrementales, o sea a nivel CPU, se puede generar el Id de la Factura, generar todo el detalle y luego guardar en una misma transacción.

Cuando se tienen que consolidar sistemas, en principio no habría problemas, debería coincidir que en dos bd por separado en el mismo milisegundo dos usuarios con en el mismo nombre hayan generado un registro en PCs con igual nombre.

Saludos: Miguel

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

>dos usuarios con en el mismo nombre hayan generado un registro en PCs con igual nombre.

Si genera el hash incluyendo sucursal y sys(0) es imposible que se genere la misma clave.

Saludos,

Víctor.

Lambaré - Paraguay.

[Carlos Miguel FARIAS]

La función que que propongo usa un hash sys(0), pero para meterlo en un monetario o en entero grande, se debe cortar un poco y aumenta la posibilidad de hashes idénticos (colisiones de clave que le dicen). Agregar el número de la sucursal puede cambiar las hashes, pero no reduce la posibilidad de colisión.

Por ese motivo, los identificadores universales son tan grandes (16 bytes).

También se podría usar la generación de nombres de archivos aleatorios que viene con Fox, lo pense en un primer momento pero no encontré el algoritmo para revertirlo y ver si puedo tener algo para auditoria ahi.

Saludos: Miguel

El 9 de diciembre de 2017, 17:07, Víctor Hugo Espínola Domínguez <vich...@gmail.com> escribió:

>dos usuarios con en el mismo nombre hayan generado un registro en PCs con igual nombre.

Si genera el hash incluyendo sucursal y sys(0) es imposible que se genere la misma clave.

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Carton, estas mezclando agua con aceite para preparar quien sabe que cosa que no tienes bien definido jajajajaj, primero define que quieres hacer, como y para que, después diseñas la base de datos, pero no supongas, se concluyente en que necesitas.

Si tienes miedo de que pasado el tiempo tengas que consolidar información entonces si o si usa sucursales y punto.

Para ayudarte con tus fobias te paso la estructura para FireBird que te permita consolidar información y usando AI solamente.

CABECERA
id(AI)   oficina serie  numero     fecha             cliente
325      01      AA      0000254   08/12/2017    512

Debes usar un Generador de Firebird sobre el campo Oficina + ID, para que de esta forma se vaya incrementando el ID por oficina, si o si requieres un indice compuesto por Oficina + Serie + Numero para tus reglas de negocios.

LINEAS
id(AI)     oficina idcabecera codigo nombre          precio
15023   01       325             1         chocolate              1
15024   01       325             2         azúcar                   3
15025   01       325             1         chocolate              1

Y listo sin hacer tanta cosa rara ahí tienes tus tablas listas para ser consolidadas o combinadas en otro servidor y sabrás que registro es de quien.

P.D. Hay que saber que se necesita para buscar la solución mas adecuada.

saludos

Antonio Meza

[Antonio Meza]

Miguel!!

Si usas autoincremental, hasta que el sistema no te retorno el id generado para una factura, no puedes insertar los detalles, en cambio con ACA, como la clave se genera independientemente del contenido de los respectivos autoincrementales, o sea a nivel CPU, se puede generar el Id de la Factura, generar todo el detalle y luego guardar en una misma transacción.

Al usar AI lo haces sobre una misma transacción también!!! Ahora bien en FireBird al insertar el registro de la cabecera gracias a Retuning obtienes el ultimo ID por lo que no necesitas enviar una consulta nueva al servidor. por lo que te ahorras la rutina personalizada, y como ya comente usando AI + Sucursal pues ya tienes resuelto el problema de combinar bases de datos.

Cuando se tienen que consolidar sistemas, en principio no habría problemas, debería coincidir que en dos bd por separado en el mismo milisegundo dos usuarios con en el mismo nombre hayan generado un registro en PCs con igual nombre.

De igual forma con AI usando Firebird no tendría problemas alguno y mucho menos por el tiempo y no importa si esta usando el mismo usuario en todas las PC o en la misma maquina.

La ventaja de elegir un servidor de base de datos es conocer sus bondades y aprovecharlas, no solo se debe elegir por estar de moda o porque es el que usa Higo, Pedro o Luis jajajajaj

saludos

Antonio Meza

[Carlos Miguel FARIAS]

A vos te gusta AI, a mi me gusta ACA, entiendo perfectamente la solución con AI, porque la he usado.

Yo no digo que AI no sirve, solo digo que ACA me da otras posibilidades.

Mi solución es independiente del motor. No me caso con ninguna (sería bígamo!).

Saludos: Miguel

[Antonio Meza]

Lo bueno de nuestros gustos es que los compañeros tiene mas cartas sobre la manga, imagina el que solo ha usado claves Naturales, al ver mis comentarios ahora conoce los AI, o imagina los que solo conocen AI y ahora ven tus comentarios sobre los naturales!!!

En conclusión nuestros gustos enriquecen el conocimientos de los compañeros, y como dije desde un principio mi intensión es acabar con los mitos erróneos de los AI, solo eso!!! y si sueno como Famboy pues tachenme de famboy jajajajajajaja pero OJO!!!!! MUCHO OJO!!! es mi experiencia con los AI, porque al rato no quiero que piensen que es una verdad absoluta mis comentarios, no quiero caer en ese error 2 o 3 o no se cuantas lleve ya que piensen que lo digo como verdad, NO!!!! solo es mi experiencia y puedo estar equivocado por eso siempre pido que si alguien sabe que estoy en un error me diga y me enseñe!!! jejejeje

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Antonio: Lee bien mis post AI y ACA son las dos claves artificiales. Y además están las naturales. Y coincido que hay conocer los pro y contras de cada una para aplicarlas cuando corresponde. Y no está mal usar combinadas en un mismo diseño de SGBD.

Lo que no te mata, te engorda.

Recuerdo cuando se discutía entre el acceso directo contra el acceso indexado.

Saludos: Miguel

[Antonio Meza]

Hola Hernan!!!

Puedes ver el articulo de Walter es para FireBird, en el caso de MariaDb y MySql lamentablemente en tablas InnoDb que son las que usan transacciones no se puede hacer eso de forma automática, si lo puedes hacer en tablas del tipo MyIsam pero ahí no tienes transacciones.

https://firebird21.wordpress.com/2013/08/10/claves-primarias-simples-o-compuestas/

saludos

Antonio Meza