Mensajes

En ningun sitio pueden decirte cual es la mejor opcion porque eso es algo ya personal    y para evitar disputas entre usuarios unos fanaticos de una cosa y otros de la otra... pues lo ideal es dar la caracteristica de cada asunto, y que el usuario particularmente seleccione cual le conviene.

Yo si fuese tu, elegiria cifrar las contrasenas con la funcion md5 dentro de MySQL en vez del codigo php. Mi razon? sencillamente si alguien te hace algun SQL injection o alguien obtiene o tiene acceso alguna vez a tu base de datos mysql podra ver en texto plano las contrasenas de los usuarios (sino estan encriptadas) que aunque cubras esto mediante codigo php sera exclusivamente solo para acceso web, pero si alguien obtiene cosas de la base de datos? aqui como impides que vea en texto no plano datos importantes?

Es solo mi humilde opinion, cada uno tendra la suya propia como te digo 

Supongo que preguntaras como hacer en el motor de base de datos lo que haces en php, puesto que en tu ejemplo mostrado con echo y usando los indices de cada variable debe funcionar perfectamente.

Ahora si preguntas como hacer lo mismo pero en el motor de DB. Tienes  2 opciones, o un procedimiento almacenado (mas comodo) o manualmente declarando variables temporales y usandolas dentro de tu consulta. Por ejemplo:

Imagina que tengo estas dos tablas:

Código (sql) [Seleccionar] Expandir


mysql> select * from tipo;
+----+--------------------+
| id | tipo               |
+----+--------------------+
|  1 | Comida Rapida      |
|  2 | Comida semi-rapida |
|  3 | Comida instantanea |
+----+--------------------+
3 rows in set (0.00 sec)

mysql> select * from locales;
+------------+------+-----------------+
| nombre     | tipo | direccion       |
+------------+------+-----------------+
| BurgerKing |    1 | Calle nadie #45 |
| MacDonalds |    2 | Calle nadie #33 |
| KFC        |    3 | Calle nadie #24 |
+------------+------+-----------------+
3 rows in set (0.00 sec)



Con un procedimiento almacenado (Esto es un ejemplo en MySQL);

Código (sql) [Seleccionar] Expandir


mysql> delimiter /
mysql> create procedure proceso(in numero integer)
    -> begin                                     
    -> set @nombre := 'El local de nombre : ';
    -> set @tipo := ' Es del tipo : ';
    -> set @direccion := ' Ubicado en : ';
    -> select concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) from locales inner join tipo where locales.tipo = numero and tipo.id = locales.tipo;                                                           
    -> end;
    -> /
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;
mysql> call proceso(1);
+--------------------------------------------------------------------------------+
| concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) |
+--------------------------------------------------------------------------------+
| El local de nombre : BurgerKing Ubicado en : Calle nadie #45 Es del tipo : 1   |
+--------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> call proceso(2);
+--------------------------------------------------------------------------------+
| concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) |
+--------------------------------------------------------------------------------+
| El local de nombre : MacDonalds Ubicado en : Calle nadie #33 Es del tipo : 2   |
+--------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)



Con variables temporales en una consulta SQL (Validas solo por sección de usuario):

Código (sql) [Seleccionar] Expandir



mysql> set @nombre := 'El local de nombre : '; set @tipo := ' Es del tipo : '; set @direccion := ' Ubicado en : ';
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> select concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) from locales inner join tipo where locales.tipo = 1 and tipo.id = locales.tipo;
+--------------------------------------------------------------------------------+
| concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) |
+--------------------------------------------------------------------------------+
| El local de nombre : BurgerKing Ubicado en : Calle nadie #45 Es del tipo : 1   |
+--------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> select concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) from locales inner join tipo where locales.tipo = 2 and tipo.id = locales.tipo;
+--------------------------------------------------------------------------------+
| concat(@nombre, locales.nombre, @direccion, locales.direccion, @tipo, tipo.id) |
+--------------------------------------------------------------------------------+
| El local de nombre : MacDonalds Ubicado en : Calle nadie #33 Es del tipo : 2   |
+--------------------------------------------------------------------------------+
1 row in set (0.00 sec)


Gracias por el cumplido Ari-Slash         los halagos digo.

No te imaginas cuantas personas (incluyendome) han pasado por ese mismo error que presentas al intentar reinstalar o actualizar MySQL bajo Windows (Esto es un bug antiguo de MySQL bajo sistema operativos Windows, viene desde MySQL 4.x y aun en la actualidad no lo han resuelto). Lamentablemente aunque me he topado con este problema anteriormente, nunca he conseguido hacerle funcionar bajo las mismas condiciones de solucion que me han servido a mi. Pero, te dire algunas de las cuales he probado y que me ha resuelto el lio haber si en tu caso aplica, dices que tenias MySQL 5.1 instalado y funcionando bien (Si la primera vez el se instala satisfactoriamente, el problema viene al reinstalar) y de repente sencillamente el servicio dejo de funcionar (Te aseguraste o te has asegurado que no tienes algun firewall activado que impida que el proceso inicie?). Como tu error en instalacion me ha pasado a mi y miles de personas en Windows, te presento cosas que me han funcionado (Espero que alguna te sirva aunque no lo aseguro):

Solucion 1:

1 - Iniciar Windows en modo prueba de fallos
2 - Eliminar todas las carpetas referentes a MySQL
3 - Limpiar registro toda entrada que diga algo de MySQL
4 - reiniciar PC y volver a proceder con la instalacion nuevamente.

Solucion 2 :

1 - Instalar MySQL normalmente aunque al final diga 'cannot create service for windows'
2 - Ejecutar mysql desde la linea de comandos (MS-DOS) como servicio independiente:

mysqld-nt --defaults-file="c:\Archivos de Programa\mysql\MySQL Server 5.0\my.ini"--standalone --console

si el comando anterior no aplica contigo, puedes optar por este:

mysqld --verbose --standalone --console

* Apareceran un sinumero de errores (En mi caso todos eran de InnoDB y permisos) lo que he hecho es detener entonces cualquier servicio MySQL que este ejecutandose del Task Manager, y volver a reintentar con:

mysqld --verbose --standalone --console

Ahi el como que repara la cuestion de InnoDB y carga el motor normalmente, permitiendome volverlo a detener y poder iniciarlo normal desde 'Services' en los servicios de Windows.

Solucion 3 :

* Durante la instalacion cuando lleges a la parte de colocar contraseña de root, vete a la barra "Inicio -> Ejecutar" y pon:

sc stop MySQL
sc delete MySQL

Luego:

1 - Vete a "Inicio" -> "Programas" -> "Mysql" -> "Mysql Server 5.1"
2 - Selecciona MySQL Server Instance Config Wizard.
3 - Elige "Reconfigure Instance"
4 - Llegaras a un punto donde dira algo de security options o algo asi, desmarca la casilla que dice "Modify Security Settings" y continua pulsando los botones de continuar.

Cuando todo termine, y el servicio de mysql sea cargado puedes colocar contraseña de root de mysql nuevamente ejecutando :

"MySQL Server Instance Config Wizard"

Si nada de lo anterior aplica para tu caso (que puede pasar) podrias entonces eliminar todo nuevamente, y antes de reinstalar buscar el archivo 'winmysqladmin' y abrirlo en un editor, buscar la linea exacta donde haga referencia al nombre del servicio de MySQL y cambiarlo por otro nombre, guardar cambios y durante la instalacion elegir otra Ruta (directorio) donde instalar MySQL en vez del tipico directorio que tenias antes (Que posiblemente era C:/Archivos de Programas').

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.

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.

De nada diego         

Desconocia como SQL Server manejaba los datos DATE, aparentemente si tambien hay que agregarle un formato como en Oracle.

Un saludis 

finalmente buscaste la logica de otra manera    segun esta logica realizada por ti, efectivamente confirmo que si.... parece que en PHP no hay manera de hacer un memlock dentro de un motor de base de datos mientras tengas una consulta en espera.

Pero me alegro que finalmente buscaras la vuelta, aunque no uses LOCK TABLES 

Claro los que han ido comentando aca:

http://foro.elhacker.net/bases_de_datos/iniciando_en_base_de_datos-t273232.0.html

Aunque claro, no son tan avanzados en explicacion como el de High Performance MySQL de O'Reilly pero este en Espanol no lo he visto. Pero tutos en Espanol hay muchos por Google.

Skeletron lol    si nunca se deja de aprender en esta vida Tecnologica encanto        

De hecho mi ultimo libro que estoy leyendo, muy muy bueno (Aunque esta en ingles) es :



Me ha sorprendido todas las cosas que he leido alli (aplicable mayormente a MySQL pero igual a otros motores como Oracle, Postgresql, SQL Server, etc).

Muy recomendable.

Lo encontre en taringa

[MOTORES DE ALMACENAMIENTO MYSQL]

MOTORES DE ALMACENAMIENTO MYSQL


* MyISAM, el motor por defecto, permite lo típico, pero no permite transacciones, toda las consultas se realizan con autocommit. Por lo demás no hay mucho que comentar, como curiosidad decir que los BLOB o TEXT pueden ser indices, e incluso un campo que sea indice puede tomar valor NULL. Usa Arboles B internamete para los indices (separado de los datos) y tiene herramientas para chequeo y reparación de tablas.


* BLACKHOLE: si tiene un nivel de inglés tan patetico como el mio (o superior) fijo que descubres que hace este motor (blackhole = agujero negro). Sería el equivalente a /dev/null mayormente. Y dirás, ¿y esto para que cojones lo quiero yo?, pues puede llegar a ser útil, pues cuando realizas una transacción con este motor, auque no se guardan los datos, ni te va a devolver nada, si que crea LOG de la sentencia SQL que se "ha ejecutado". El caso típico podría ser establecer un servidor esclavo para que de ese modo guardará el log de lo que pasa en el master.


* CSV, motor completamente trivial, que guarda cada tabla en un fichero y cada fila de datos es una linea con los datos separados por comas. Queda claro, no?. Para hacer la gracia decir que no soporta indices (imagina buscar en ficheros... coste secuencial! O(n) OMFG!). Este formato sería usado mas bien para crear archivos listos para ser importados por otros programas.


* ARCHIVE, el motor almacen almacen, solo soporta INSERT's y SELECT's, es decir un almacen!. Además, siempre que escribes datos se comprimen (con zlib), así que es el motor típico para una base de datos histórica o cuando vamos a tener una cantidad realmente enorme de datos (quizás sea la idonea para GIS?, habría que meditarlo...). Decir que si se realizan muchos SELECT a la vez que se realizan INSERT provocaría que el motor se hiciese la picha un lio, ¿por qué? Porque cuando se hace un INSERT los datos van a un buffer (para no tener que recomprimir, con zlib, para cada p**a linea que se inserta supongo...) y éstos datos serán flusheados cuando se realice el SELECT, ahora piensa cientos de INSERT y SELECT en paralelo. Da miedo, eh?


* EXAMPLE, este no sirve para nada, jaja. Es solo un ejemplo de motor, para poder mirar su código y crear motores hechos y derechos


* FEDERATED, motor nuevo que se incorporó en la versión 5 de MySQL, para poder crear bases de datos federadas, esto significa que estaremos consultando a una bases de datos remota, es decir en nuestro servidor creamos la tabla pero le decimos, oye que esta tabla esta en otro lado, si eso, le preguntas, que fijo que te responde. Este modelo tiene ciertas limitaciones, no permite ALTER's ni transacciones.


* MERGE, este es facil, si tienes dos tablas con motor MyISAM y con la misma estructura, al crear una tabla MERGE, juntarás los datos de ambas tablas. Un caso para el cual puede ser útil este motor, podría ser, por ejemplo, diferentes tablas de log en diferentes servidores y te creas en uno de ellos tablas FEDERATED de esas tablas (que serán MyISAM) y entonces creas una tabla de "log_principal" (usando MERGE) que tendrá el log de todos los servidores. arrr marinero.
   

* MEMORY, tablas que se guardan en memoria, es decir, cuando reinicies MySQL, adios datos. No le encuentro ninguna utilidad la verdad, si quieres un almacenamiento temporal, que sentido tiene entonces usar un SGBD? Pues ninguno!.
   

* Berkeley DB (BDB para los friends), una de las bases de datos openSource más famosa y utilizada. El motor es independiente de MySQL, con las ventajas e inconvenientes que esto pueda acarrear. Permite transacciones (COMMIT & ROLLBACK) y solo puede ejecutarse en sistemas operativos soportados (Linux x86 y Windows, si; Mac OS X feo y Linux AMD64/Alpha, no). Como curiosidad decir que su organización de ficheros se basa en solo dos, puesto que utiliza árboles B donde, en cada nodo, están tanto los datos como el índice primario (lo cual implica que será algo más lento a la hora de recorrerlo secuencialmente)


* InnoDB, es el motor más avanzado (junto con BDB) en cuanto a opciones y funcionalidad. Permite transacciones seguras (COMMIT y tal) y está orientado a manejar grandes cantidad de datos. Realiza el bloqueo usando como granualidad la fila (BDB lo hace a nivel de página, es decir mayor salvo casos raros de filas enormes) e incluso soporta lecturas consistentes tanto bloqueantes como no bloqueantes.

Como reflexión final decir que los únicos motores que soportar transacciones seguras son BDB.

Cada Motor de Almacenamiento tiene su propia funcionalidad de manipular la data recibida y guardada. Dependiendo las funcionalidades de cada cual esto implicara mayor rapidez o lentitud bajo ciertas condiciones. Se dice bastante que Myisam es mas rapido en lectura que InnoDB por ejemplo y lo cual es cierto. Pero esto dependera en gran parte a como la aplicacion que se conecta manejara las consultas si da preferencia a consultas donde utilize indices clustered en este lado InnoDB llevara la delantera frente a Myisam y rapidez, puesto que InnoDB soporta indices clustered mas MySQL no.

Que son indices clusteres y indices no clusteres:

http://207.46.16.252/es-es/magazine/2008.02.sqlqa.aspx