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   


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.

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.

Pues a largo plazo creo que si, es posible que el subforo de Base de Datos crezca bastante, no digo ahora o manana pero a largo plazo, el pulpo va creciendo y siendo mas necesario cada vez   

Se coloco creo como subforo de desarrollo web, por el hecho de que la peticion vino de usuarios que desarrollan web.

Si es cuestion de esperar que dicho subforo se haga popular para que deje de ser un subforo y sea un tema del foro, pues no hay problemas. Lo unico negativo es que la ubicacion donde esta ahora mismo esta un poco escondida, y hay usuarios que aveces no lo ven y preguntan cosas de Base de Datos en otros subforos y foros.

No entendi eso ultimo Napk... pero ya puestos en la sugerencia surgida, y puestos en que no suelo quedarme en silencio cuando tengo una duda o sugerencia    tenia que expresarme 

Y mirando que hay foros por ejemplo de C/C++ que es un lenguaje de programacion y nada mas, podria este perfectamente ir en Programacion General junto con el de Visual Basic, son lenguajes su objetivo es programar. Sin embargo estan independientes como foros.

Entonces algo tan expandido en distintas areas de tecnologia como son las Bases de Datos, como mi opinion y mi percepcion visual al menos yo no la encapsularia como subforo de ninguna categoria porque las bases de datos se usan en programacion, en sistemas operativos y en optimizacion de hardware.

Es solo mi humilde opinion    pero cualquiera puede ofrecer sus ideales.

Es un tema un poco complejo. Una porque las bases de datos no solo se usan para desarrollo web, pero tampoco solo son usadas para programacion general y otra parte tambien las bases de datos deben sacarle provecho al sistema operativo en el cual se instalan y al hardware en el cual se instalan.

Entonces si tomamos lo anterior tendriamos esta duda, el subforo de base de datos deberia ir en:

1 - Desarrollo Web
2 - GNU/Linux/Windows/BSD
3 - Programacion General
4 -Hardware

En cual de todos deberia dicho subforo formar parte????

Porque siempre habran dudas en torno a los distintos motores de BD existentes en cuanto a su funcionalidad en X sistema operativo, en cuanto a su desenvolvimiento con el hardware, en cuanto al estructurado de una consulta para X aplicacion o para un proyecto web....

Yo no encapsularia el subforo de Base de Datos dentro de ninguna categoria, no lo veo como un subforo deberia ser independiente porque dicha area es como un pulpo trabaja con todo no solo con lenguajes de programacion, no solo con webs, no solo con sistemas operativos y no solo con hardware.

Entonces aunque actualmente es un Subforo de Desarrollo Web, el tema como tal no deberia estar encapsulado dentro de ninguna categoria como un subforo porque abarca demasiado.

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.

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.

Hay mi nino pero si tienes que instalar primero Joomla como tal antes de ingresar al indice principal 

Lamentablemente no puedo indicarte como se instala Joomla porque hace un tiempo no lo hago, pero es vie web (lo cual es mas amigable y facil)

Muevo el tema a PHP alli estoy segura que te expondran de sobra con guias visuales a lo mejor, como va el asuntito.

 

Que no existe una tabla con los campos requeridos por la aplicacion para insertar los registros....

De antemano, instalaste Joomla primero (tu sabes instalar, crear el admin, crear la DB, todo) antes de ingresar al index???