Foro de elhacker.net

hola a todos, resulta que quiero saber para que fucking demonios sirve el maldito NOT NULL?? como su nombre lo dice "no nulo" se supone que no deberia aceptar campos vacio.. pero lo hace, se puede agregar campos vacios a una tabla, o mejor dicho, no agregar nada a ese campo, pero si a los demas sin problemas, alguien que me explique entonces para que sirve?? porque de adorno no luce bien  :xD


y tambien decirles que a veces (miento!! esto lo hago siempre!!  :xD) yo suelo insertar datos en formato de fecha, numericos o string a determinados campos de una tabla, y por defecto a TODO lo llamo varchar no uso date, int (int solo uso para el id) u otros atributos porque hasta ahora todo trabaja bien sin problemas  :xD, pero mi pregunta es... hay alguna diferencia o punto en contra con la forma que estoy trabajando?? se que voy contra las reglas pero quiero oir criticas constructivas.. o mejor aun.. que me quiten la venda de los ojos  :D
saludos y no sean tan severos conmigo  :laugh:

supongo que es mysql o sqlserver.

NOT NULL, como su nombre lo dice, que el campo no admite valores nulos, no los campos vacios en un ejemplo:

INSERT INTO (id,nombre) tablita
VALUES (1,NULL)

Dara error, mientras que

INSERT INTO(id,nombre) tablita
VALUES(1,'')

Sera aceptado ya que son valores diferentes.

Sobre los tipos de datos, es mejor trabajar con los tipos de datos para cada cosa para eso estan, en performance hacer una busqueda por un campo de tipo numerico es mas rapido que uno tipo varchar, y para fechas te evitaras las odiosas conversiones trabajando con el tipo de datos date.

atte.
Miguel Angel

Para no acceptar valores desconocidos o nulos, el Ansi SQL trabaja con la teoria de logica ternaria en los motores de base de datos (verdadero, falso, desconocido)  ;)


Lo hace siempre y cuando tengas en dicho campo donde insertas el NULL un auto_increment o una secuencia (y das uso de esta secuencia en el INSERT) o similar, de lo contrario no te acceptara insertar NULL ni null en dicho campo donde exclusivamente especificaste NOT NULL.


Enserio? existe una diferencia, de acorde a la estructura de datos primitivos cuando creas una tabla con campos varchar estas reservando espacio en memoria para recibir datos caracteres (Que obviamente al hacer un INSERT "890888-999" el lo ve como un caracter esta entre comillas, lo mismo pasa con datos fechas) y aunque esto ocupe 1 byte en memoria por la reserva del dato varchar + los bytes que ocupen de espacio tus datos insertados en memoria cache, que me dices cuando te soliciten o peticionen condiciones donde debas sumar, sacar potencia, restar, dividir, etc... 2 campos (digamos de ejemplo sueldo) de 2 tablas? o que te soliciten buscar el ultimo dia del mes tal? no podras dar uso exclusivo de esas funciones especiales en los motores para obtener a gran rapidez lo que buscas (A no ser que empiezes encima a convertir pasandole un casting a cada campo) y oye... porque forzar la lectura del motor con:

* Verificar primero los permisos del usuario en las tablas
* convertir los campos encerrados en el Casting a la estructura de dato indicada por ti
* realizar la suma, resta, division, potenciacion, loquesea en dicho datos
* retornar dicho valor
* convertir dicho valor a varchar para finalmente mostrartelo....

No seria mas efectivo tener un campo digamos DECIMAL que no redondea cifras para el salario y hagas una suma de 2 salarios por ejemplo y tu motor solamente haga :

* Verificar primero los permisos del usuario en las tablas
* realizar la suma, resta, division loquesea de dicho datos
* retornar dicho valor

Vez la diferencia?

Esto sin agregarte, que el tipo de dato varchar no es muy efectivo, es un tipo de dato de reserva 'dinamica' en el motor. Al decir dinamica, me refiero a que puedes declarar un campo asi:

nombre varchar(30)

Y cada vez que insertes un registro a nombre, solamente ocupara en ram el espacio exacto del nombre insertado, si tu nombre solo tenia 10 caracteres pos nada... se inserta 10 caracteres se corta el espacio para los 20 sobrantes, si insertas en un segundo intento otro dato de 18 caracteres nada se llenan 18 bytes y se cortan los restantes... y asi sucesivamente, y esto a la larga causa fallas en transacciones masivas (Varchar es muy dispuesto a corromperse no tiene mucha atomicidad) por ser precisamente dinamico y no tener una constante fija de tipos de datos en su reserva. Por eso siempre uso char en vez de varchar, aunque aveces opto demasiado por la rapidez y me voy por bynary.

No quiero alargar mucho el tema, solo te he expuesto una introducion basica porque el tema de tu pregunta puede tornarse extenso. No te recomiendo por normalizacion de base de datos que declares campos que accepten NULL, el motor reserva espacio para una tabla y varios campos con sus respectivos tipos de datos, insertar valores NULL en estos como NULL no pertenece a ningun tipo de dato real existente el motor en una consulta de lectura pierde unos milisegundos deteniendose en cada valor NULL encontrado porque el sabe que se ha reservado espacio para X tipo de datos y al no encontrar ese tipo de dato sino NULL el tiene que guardar esto en el Buffer antes de moverlo a la Cache de memoria. No uses campos NULL, declara los campos acorde a los valores a guardar no le indiques al motor que todo es un caracter, aveces hay tipos de datos que ocupan mas espacio de disco pero que responden mas rapido a lectura que los caracteres (Recuerda que el CPU trabaja a nivel binario)

Suerte con eso.

Bajo que condiciones sucede eso?, me refiero al corromperse.

atte
Miguel Angel

Por ponerte ejemplos sencillos, asume que haces lo siguiente y por desgracia sufres un corte electrico a mitad del proceso o sencillamente pierdes conexión a la red o similar, falla de disco etc :

* Transacciones masivas entre un esclavo y un maestro (espejo)
* Transaciones en clusteres
* Transferencia de datos de una DB a otra
* Restaurancion de un backup de mas de 50GB

- Son solo ejemplos basicos, cosas que pueden hacer que un o mas tablas se corrompan de alguna u otra forma. Que aunque influye tambien en parte en esto el motor de almacenamiento (como los no transaccionales en MySQL) hago incapie en que no es la causa del todo. (He visto tablas corromperse en motores transaccionales como InnoDB a causa de un programador web que asigno como indice campos varchar) mientras mas consistentes sean los datos, por cuestion de rendimiento y optimizacion al menos yo, me inclino mas en campos caracteres por char aunque me ocupe mas espacio en disco, son mas improbables a corromperse incluso en tablas Myisam (Que suelen corromperse con frecuencia) .

Aunque sera cuestion de gustos, he conocido DBA Seniors en Oracle que les he preguntado cosas tan simples como, sabes la diferencia entra un char y un varchar2? y me han respondido cosas tipo: que no son acaso lo mismo.... y he tenido que exponerle que no y el porque.

Yo me he tornado un poco maniatica con la optimizacion de los motores de DB, no digo que varchar sea mediocre o malo, porque ejerce su funcion decentemente aunque tenga sus riesgos, las unicas veces que opto por varchar es si son campos de una tabla que no sean muy importantes o tenga que economizar espacio en el disco, o similar. De lo contrario, intento que todos los tipos de datos sean lo mas consistentes posibles, asi se evita la gente muchos problemas futuros.

Se que no es mi hilo, pero necesito que me aclares algo, tu mencionas que se corrompe toda la tabla(eso es lo probable y logico) debido a una falla determinada (corte de electricidad o caida de red en tu ejemplo )lo que no me parece logico es que sea mas probable que se corrompan determinados campos solo por tener el tipo de datos varchar lo cual me parece incorrecto, por que las unicas veces donde los campos de tipo caracter estan propensos a ser truncados(corruptos) es cuando haces migraciones de distintos motores(por los tipos de intercalacion que poseen los tablas o por caracteres validos en un motor y en el otro no) ejem. sybase a sqlserver o viceversa. pero esto es indistinto ya que es aplicable tanto para campos char y varchar.

Como nota adicional de suceder un error(sea cual sea la naturaleza)  para el tipo de transacciones del ejemplo se corrompen las tablas haciendolas inclusive inoperativas, en el caso de quedar operativa al ser error transaccional se trunca la insercion de registros ya que la ATOMICIDAD que mencionas se aplica a las transacciones mas no a un tipo de dato en particular, por lo cual la expresion "(Varchar es muy dispuesto a corromperse no tiene mucha atomicidad)" me queda bastante confusa hasta me aventuraria a decir incorrecta y quisiera saber a que hacer referencia; todos los dias se aprende algo nuevo dicen quizas me he perdido de algo...

atte.
Miguel Angel

No del todo, si hablamos de una tabla en un motor transaccional (InnoDB por ejemplo) los cambios aplicados no se escriben automaticamente a disco como ocurre en motores transaccionales. Al permanecer en buffer y cache hasta recibir la instruccion commit son menos propensos a errores que los motores no transaccionales. (Si solo hacemos referencia al tipo de motor, mas no al tipo de datos de los campos dentro de dicho motor) hay una falla de red con una transaccion en motores InnoDB? pos nada cuando se restaure seguira donde se detuvo.


No te imaginas las veces que he podido restaurar tablas Myisam (cuando repair table no funciona) solamente con hacer alter table y cambiar campos varchar corruptos a char.... y las veces que he visto tablas en InnoDB corromperse por tener indices varchar.

Referencia de MySQL:


Fuente:  http://dev.mysql.com/doc/refman/5.0/es/crashing.html

Esta bien que te guste Varchar, pero por rendimiento y consistencia y evitarte problemas futuros al menos yo optaria por Char (y casi siempre lo hago).


Esto es bastante logico, si migro data de un motor a otro distinto es mas que obvio lo expuesto anteriormente, por la referencia ya expuestas por ti. Pero hacia referencia yo a Varchar vs Char.


Aunque hacia referencia a los registros guardados bajo cierto tipo de datos (ya que no tiene mucha logica tener un campo con cierto tipo de dato definido y jamas insertarle datos) conclui diciendo que el tipo de dato varchar no era atomico (pero hacia referencia a su manera de manejar los registros guardados en el, mas no al tipo de dato en si porque el tipo de dato sin nada guardado no tiene mucha logica de critica) Siento mucho que por alguna u otra razon este punto se haya malinterpretado.

No es que me guste, yo las utilizo no por gustos sino por necesidad.

Gracias por la referencia aclaraste mi duda sobre la corrupcion por el tipo de campo(no menciona el motivo de la corrupcion una pena), aunque trabajo con sql server y sybase debo asumir que la referencia dada por mysql es aplicable tambien a estos motores o si en estos se presentan( hasta el momento no se me han presentado ni en desarrollo, ni en deployment ni en produccion) o no hasta que no encuentre referencia que la sustente o la refute, igual no me queda claro esto


atte.
Miguel Angel

Pegue la referencia de MySQL porque asumo que siempre sera mas creible el respaldo de lo que diga una empresa que desarrolle y produzca un motor de BD que lo que diga yo  :xD 


El motivo de la corrupcion (aunque esto es una percepcion personal propia) para mi, creo que ocurre por el hecho de que al tipo de dato varchar ser de longitud variable cuando por alguna razon no termina una transaccion realizada sobre este campo, y estamos trabajando en un motor no transaccional (por ejemplo) como todo se escribe a disco automaticamente (por el autocommit) si dicho campo de longitud variable no se completo la transaccion  y  como no esta definido en ninguna parte que se autocomplete con espacios a la derecha (como ocurriria con el tipo de datos CHAR) entonces nada... queda corrupto escrito en el datafile la informacion ya que ni completo su longitud establecida ni completo la informacion que se estaba introduciendo durante la transaccion, y eso pues corrompe la data de la tabla en cuestion.  (aunque repito esto es una referencia personal mia, no digo que sea real)



Aunque hacia referencia a los registros guardados bajo cierto tipo de datos (ya que no tiene mucha logica tener un campo con cierto tipo de dato definido y jamas insertarle datos) conclui diciendo que un campo con el tipo de dato varchar no era atomico (pero hacia referencia a su manera de manejar los registros guardados en el, mas no al tipo de dato en si porque el tipo de dato sin nada guardado no tiene mucha logica de critica) Siento mucho si por alguna u otra razon este punto se haya malinterpretado.

Generalmente tengo que creer cuando la documentacion es oficial  :xD, sino todo se basa en "experiencias" tanto la tuya como la mia.

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


Obvio ya que la expresion en el contexto es incorrecta.  ;)

atte.
Miguel Angel

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.

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.

wow, wow, wow  muy interesante :P esto era lo que queria leer  :D
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  :-*

Sobre lo de VARCHAR vs CHAR es relativo Pazador  :D  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.

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

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  :rolleyes:

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.

 :-*   :-*   :-*

Hola de nuevo, no te respondi por el tiempo que tengo muy limitado en el trabajo y solo dispongo de fines de semana, iniciamos.


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.


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.



En SqlServer el soporte es mayor.

http://msdn.microsoft.com/es-es/library/ms175055.aspx

atte.
Miguel Angel

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.

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.

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.