Dudas con atributos a los campos de una tabla

[^Tifa^]

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..

Efectivamente era una suposicion personal, no puedo darte una afirmacion concreta del porque esta afirmacion esta tan difundida (Sobre el poco soporte de corrupcion en tipo de datos varchar exclusivamente) no solo la gente de MySQL lo confirman, he visto referencia de lo mismo en el foro principal de la web de Oracle (Aunque ahora mismo no puedo buscarte y pegarte la referencia, pero anteriormente la he visto). Y ambos son lugares oficiales. Una razon bastante fuerte ellos han de tener para reafirmar que los registros dentro de tipo de datos varchar pueden corromperse por la poca resistencia ante fallos que posee el tipo de dato varchar como tal (esto es independiente del motor en cuestion del que hablamos).

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. Yo creo mas que depende como vayas a tratar los datos, 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. Es cierto que tienen mas soporte a fallas y corrupciones si son motores transaccionales, pero no son 100% garantizables, tambien influyen los tipos de datos y como estos funcionan para si mismos.

[^Tifa^]

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

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.

[Pazador]

wow, wow, wow  muy interesante esto era lo que queria leer 
ahora mismo me cambiare a char() y ordenare cada dato con su atributo correspondiente y luego profundizare mas sobre las bd
gracias por quitarme la venda de los ojos 

[^Tifa^]

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.

[Nakp]

nombres, apellidos y direcciones como CHAR?... yo solo lo uso para hash xD y alguno que otro caso especial, carnés, numeros de serie, etc...

[^Tifa^]

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.

      

[Toxico]

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.aspx

atte.
Miguel Angel

[^Tifa^]

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.

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.

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.

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.

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.

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.

[Toxico]

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.

Estimada Tifa, eso no es discutible ya que como te recalco no es cuestion de gustos la eleccion del tipo de dato para un campo, es asi como se hace la eleccion del tipo de dato, se elige el tipo de acuerdo al comportamiento que va a taner, si conoces la logitud exacta pues lo mas logico es usar char, si la logitud del campo es variable pues lo mas logico es usar varchar; pero esto es relativo..

El Manejo de Niveles de Aislamiento dan para otro ilo, que no tienen nada que ver con lo expuesto y desvirtuarlo mas de lo que esta.

[^Tifa^]

Estimada Tifa, eso no es discutible ya que como te recalco no es cuestion de gustos la eleccion del tipo de dato para un campo, es asi como se hace la eleccion del tipo de dato, se elige el tipo de acuerdo al comportamiento que va a taner, si conoces la logitud exacta pues lo mas logico es usar char, si la logitud del campo es variable pues lo mas logico es usar varchar; pero esto es relativo..

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.