Hola de nuevo, no te respondi por el tiempo que tengo muy limitado en el trabajo y solo dispongo de fines de semana, iniciamos.
Para la suposicion que mencionas de la corrupcion para el campo varchar no es dable, ya que la ATOMICIDAD de una transaccion garantiza que los datos se guarden de manera correcta o no se guarden y no por partes como seria lo que supones, en caso de suceder es un problema de la transaccion mas no del tipo de dato, si un motor de base de datos no puede manejar eso es un desastre transaccionalmente hablando..
Ahora, ya que haces una fuerte referencia sobre la garantia de atomicidad que debe ofrecerme un motor en cuestion por ser transacional, yo te pregunto en un valor declarado como VARCHAR (10) tu considera este valor atomico cuando se puede descomponer la cadena en caracteres individuales? Atomicidad de Valor de los datos (No del motor de almacenamiento que lo gestiona) por sí mismo no es un criterio objetivo y no tiene ningún significado absoluto.
Bajo el contexto que pones CHAR tambien no seria atomico ya que se puede subdividir en cadenas de caracteres individuales para lo cual seria el tratamiendo de la misma manera de un varchar.
la atomicidad puede tener muchas interpretaciones distintas, pero un motor no puede asegurarme 100% atomicidad cuando posee por ejemplo un tipo de dato varchar (con las caracteristicas antes mencionadas por mi) porque si fuesen 100% atomicos ninguna tabla se corrompiese jamas.
1ro. Confundes las cosas, una cosa es atomicidad de un campo de una tabla y otra muy distinta es la de una transaccion asumo que sabes que es ACID de una transaccion.
2do. El motor tiene que garantizarme la atomicidad de una transaccion al 100% ya que si no lo hace, ese motor de datos es una porqueria independientemente del motor de datos que sea, con un Ejemplo:
Si un motor me garantiza 99% de atomicidad transaccional refiriendonos a manipulacion de registros, quiere decir que de cada 100 registros afectados (INSERT, UPDATE, etc..) va a fallar 1, ese 1 lo cual es demasiado, sino exagerado,e inaceptable las unicas veces que he visto corrupcion de datos/tablas ilegibles y sus variantes fueron cuando los discos fallaron, por eso se me hizo raro que mencionaras corrupcion de tablas esto te lo podria aceptar cuando se usaban intensamente DBFs, en los tiempos de clipper o foxpro pues esos eran mas propensos a corrupcion de cualquier cosa.
3do. Mencionas la corrupcion de tablas como si fuera algo diario o algo muy ocurrente, no soy DBA, soy conultor y auditor de sistemas, si un DBA de alguna empresa a la cual auditamos y desarrollamos soluciones nos menciona casos de corrupcion de tablas muy recurrentemente, pues el problema es el DBA, y pues como con la mayoria de los problemas este se depura.
4to. Para Mi, el unico desencadenante para elegir el tipo de datos CHAR o VARCHAR es basicamente en como almacenan los datos, uno estaticamente y el otro dinamicamente, que uno es mas tolerante a la corrupcion talvez.., pero no me parece un motivo desencadenante y es irrelevante para esta tarea ya que la corrupcion debe ser minima.
Ya que al menos en los motores de base de datos que conozco, CHAR tiene un soporte menor de caracteres que VARCHAR (CHAR tiene un maximo de 255 caracteres).
En SqlServer el soporte es mayor.
http://msdn.microsoft.com/es-es/library/ms175055.aspxatte.
Miguel Angel
Mostrar Mensajes
