Ahora que haces mencion de ello, me surge la duda. Hice dicha referencia ya que como VARCHAR es de longitud variable, no se termina de realizar una transaccion por alguna razon imprescindible, y supongamos que mi motor es transaccional pero tiene activado el autocommit  por ende se escribira en disco el cambio automaticamente sea o no correcto, pero como se escribira? sino se completo la informacion transferida, y tampoco se completa la longitud del dato con espacios como ocurriria en CHAR.... esto va a corromper de alguna u otra manera la info escrita en disco. Tendre que hacer un pequenio escenario de prueba personal para confirmar esta creencia.

Sobre lo de VARCHAR vs CHAR es relativo Pazador    no quiero insistir o obligar a siempre usar CHAR porque habran veces que necesitaras VARCHAR en vez de CHAR. 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).

Tanto CHAR como VARCHAR son casi lo mismo, su unica diferencia radica en como almacenan, retornan y la cantidad maxima de caracteres a guardar. Si estas seguro que siempre vas a insertar un registro de una longitud fija, procura usar CHAR (Por ejemplo Nombres, Apellidos, Direccion, etc) Pero si vas a almacenar registros donde desconoces la longitud que este tomara (Por ejemplo mensajes en un foro, mensajes en un libro de visitas, etc) La preferencia seria en este caso VARCHAR. Sobretodo porque VARCHAR como te decia tiene una longitud mucho mayor de almacenamiento de datos que CHAR, y sino sabes a ciencia cierta el tamaño exacto de caracteres que se insertara en cierto campo pues usas VARCHAR.

Todo depende para que requieras guardar datos, asi sabras que tipo de datos utilizar. Lo que no puedes hacer es asignarle VARCHAR a todo (fecha, numeros, caracteres, etc) procura que cada campo vaya acorde al tipo de dato real guardado para este en memoria.

Bueno para los gustos        

A la larga todo es relativo, si yo conozco mas o menos la extension exacta del dato a introducir en un campo y que este dato sea caracter (nombres, apellidos, direccion, etc) entonces suelo utilizar CHAR, si son datos de una longitud muy variable (como mensajes en un foro, libro de visitas, formularios, etc) pues ahi si me inclino por VARCHAR.

En caso de como dices carnes, numeros de serie que incluyan caracteres y numeros... depende del motor de DB del que estemos hablando, si es Oracle aprovecho NCHAR (maneja caracteres y numeros) pero si es MySQL como este tipo de dato no existe, pues BINARY 

Creo que es cuestion de gustos y de experiencias personales los que a la larga te hacen inclinarte por una cosa o la otra por variadas razones.

       

Hago referencia al tipo de dato de una tabla independientemente del motor tal cual. Como te decia, si todo fuera 100% perfecto no hubiera corrupcion jamas bajo ninguna indole. Pero suele ocurrir y muchas cosas podrian afectar recurrentemente o no recurrente, todo depende el modelo (motor) de una tabla, el tipo de dato y el nivel de isolacion definido (Asumo que conoces los 4 niveles de isolacion del ANSI SQL y como aplicarlos al motor de almacenamiento que esto es individual del motor de base de datos en si).

Atomicidad como tal, puede tener varias interpretaciones diferentes dependiendo bajo que contexto se apliquen. Por eso defini esa afirmacion que te llevo a esa deduccion. Pero, si te quieres basar en el estandar establecido de definicion de ACID y no salir de alli, entonces si... lo que dije yo no aplica, creo que me he ido a unas aguas muy profundas al querer expandir el funcionamiento interno de algo, se sale del orden establecido.


Muy bonito ejemplo, (aunque ya me sabia esa definicion) solo que recalco nuevamente mi exposicion del paso anterior, siempre dependera como manipules los datos y bajo que circunstancia. Pero si te refieres nuevamente al estandar establecido, entonces si tu metodo aplica.


Para mi elegir CHAR implica en parte al estructurado de una tabla y los datos que vaya a manipular y cuando. Como dije anteriormente si conozco la longitud, si sera un indice, si quiero recuperar o evitar corrupciones innecesarias que aveces suelen pasar por mala eleccion de cosas, pues CHAR pero si es para mensajes, libro de visitas , respuestas de foros, etc... VARCHAR.

Cuestion de gustos, ni mas ni menos, nadie te obliga a usar CHAR eres libre de seguir utilizando varchar en todas las referencias que desees. Lo que no puedes es discutir entre char vs varchar cuando te hago una referencia publica de una fuente muy respetada (existen mas) del porque es mejor usar CHAR aveces ante VARCHAR, despues de ahi si quieres obviar char para cualquier campo aun conociendo su longitud exacta, ya no puedo hacer nada yo.

Ojala se aplicase asi siempre, ya he recalcado bastante veces que yo lo hago de esa manera pero he visto muchisimas situaciones de DBA que no aplican esta teoria y sus razones tienen (aunque no me convencen) pero repito todo es relativo, y a nivel de gustos personales muchas veces.

Sobre el temita de varchar, podria ser un tema bastante extenso y con interpretaciones bastantes diferentes lamentablemente para llegar al punto donde queria yo llegar debo introducir la paqueteria completa (isolation level, motor de almacenamiento, tipo de datos, etc) y esto puede salirse del estandar establecido por ende, puedo de mi parte dar el tema por terminado. Y basarnos exclusivamente en un motor de DB sin modificaciones internas que desvien su comportamiento, para asi lo antes expuesto por mi no sea del todo aplicable para ciertas condiciones con el tipo de dato en cuestion.

Un saludo.