Discusion sobre ID autoincremental

Coordinator
Apr 20, 2010 at 5:50 PM

Tomando en cuenta la sugerencia de JCaraballo, el grupo de CxC quiere iniciar una discusion sobre los Id's autoincrementales de la BD.

El problema es el siguiente: debido a ciertas cosas que estan mal en la BD nuestro grupo realizo algunos cambios en la BD los cuales estan detallados en el segmento de Issue Tracker. 
Nuestro grupo puso el id_factura en la tabla facturaM int autoincremental porque estaba varchar, pensamos que son mas las desventajas que las ventajas que esto trae, pero para que se conozcan la escribire:

Ventajas:
El formato sera el deseado
El tamanio es ilimitado.

Desventajas:
El usuario debe ingresar el id, osea debe de llevar la constancia de los registros.
Puede haber errores como por ejemplo id repetidos.

Que cada quien de sus sugerencias para ver que hacemos....

Coordinator
Apr 20, 2010 at 5:53 PM

Estoy casi seguro que dije que el usuario no tiene que ingresar el id y que la aplicacion maneja eso. y si la aplicacion lo maneja no pueden haber ids repetidos....

alguna otra desventaja?

Coordinator
Apr 20, 2010 at 6:07 PM

No, si dicen que la aplicacion va ha controlar el id no hay problema, el unico problema es que hoy es martes y ustedes estan pensando en controlar un id en formato varchar, sabiendo que sql puede controlar eso lo unico es que solo lo podra hacer  dos mil millones de veces, yo y mi grupo no vemos ningun problema :S

Coordinator
Apr 20, 2010 at 6:09 PM

bien, si no hay ningun problema se queda varchar.

; )  hacer que la aplicacion genere el id no se toma mas de 15 minutos, asi que no se preocupen por eso.

Coordinator
Apr 20, 2010 at 6:32 PM

no, como te dije perfecto, solo haganlo, envienlo y listo ; ), aunke son 15 minutos menos de tiempo pero nada :), se quedara varchar. Sin importar que el limite de tamanio de la bd en sql server es de solo un par de GB que se llenaran mas rapido siendo varchar :D...........  pero vuelvo y lo repito sera varchar.

Coordinator
Apr 20, 2010 at 6:33 PM

amen amigo... amen.

Coordinator
Apr 20, 2010 at 6:55 PM

Solo para mostrar un ejemplo amigable...

 

Supongamos que tenemos 2 casos hipotéticos. uno es que se realizaron 2,147,483,647 facturas y otro es que con 40,000,000 llenamos los 4gb de la base de datos de express edition. Ahora veamos las soluciones para los 2 casos.

Caso 1: Darse un tiro o alterar la tabla y poner bigint, para luego darse un tiro cuando se llene porque ya no hay mas nada que hacer.

Caso 2: Usar sql server standard edition que tiene como limite la capacidad disponible del disco.

 

No se cual te dice la lógica que uses, pero a mi me dice que use varchar, y esa es la que se va a usar. =)

Coordinator
Apr 20, 2010 at 7:27 PM

como dices amen amigo.....amen

Pero para ponerte un ejemplo amigable, son 40,000,000 usando varchar en facturaM, pero tambien tendria que ser facturaD, compraM, compraD, suplidor,empleado, etc.,(haciendo que el 40,000,000 disminuya) tambien tomando en cuenta que los varchar son inmutables(memoria ram abrumada) , teniendo presente que tienes que pagar una licencia, entre otras cosas.

Viejo se va ha usar varchar jajajaja pero no te hagas a la idea de que es por mejoria, se va ha usar varchar porque me aburre discutir cosas sin sentido como esta ;) sin ganas de zaherir amigo........

Si estas feliz yo estoy feliz, y na como dijiste amen........

 

Coordinator
Apr 20, 2010 at 7:51 PM

wtf? no viejo. solo se usaria en las facturas porque se manejan muchas... seria una perdida de espacio y de tiempo hacerlo para empleados o suplidores.

Coordinator
Apr 20, 2010 at 8:14 PM

Lo que pasa viejo es que se veria mal usar un id personalizado en la factura y que en las compras por ejemplo se use un int , deberia de usarse el mismo esquema en todo el sistema, osea es lo que piensa el grupo ......... pero bueno loko calmemos las aguas si crees que es factible usar el varchar nada nos adecuamos a eso..... no vamos a llegar a ningun lado con este tira y jala, cualquier cosa nos avisas, y recuerda que estamos esperando su parte del sistema para seguir trabajando....