Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - ^Tifa^

Páginas 1 ... 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
#871
PHP / Re: php,mysql y tablas
4 Marzo 2009, 05:40 AM
Código (php) [Seleccionar]


<html>
<head>
<title>Problema</title>
</head>
<body>

<?php
$conexion=mysql_connect("localhost","yoyo","yoyo") 
  or die("Problemas en la conexion");

mysql_select_db("mi_db",$conexion) or
  die("Problemas en la seleccion de la base de datos");


$consulta = mysql_query("SELECT * FROM ejemplo", $conexión) or
  die("Problemas en la seleccion de la base de datos");

echo "<table width='60%' border=1>";
echo "<tr><th><td>Nombres</td><td>Apellidos</td><td>Direccion</td></th></tr>";

while ($codigo = mysql_fetch_array($consulta)) {

echo "<tr><th><td>$codigo['nombres']</td><td>$codigo['apellidos']</td><td>$codigo['direccion']</td></th></tr>";

}

echo "</table>";

mysql_close($conexión);
?>

</body>
</html>



No he probado lo anterior ojo, pero mas o menos va a ir por una indole similar.

Oye buscar un poco no estaria mal... :¬¬
#872
Scripting / Re: Opinion sobre aplicaciones hechas con lenguajes scripting
22 Febrero 2009, 21:38 PM
Por eso especifique los lenguajes Scripting en aplicaciones de uso general...

Porque vamos, seamos sinceros con nosotros mismos cuanta gente o cuantas empresas se dedican a solicitar o buscar personal para desarrollar drivers, SO, y similar?????

Y cuantas se dedican a vender soluciones o aplicaciones de uso general que perfectamente pueden ser desarrolladas a gran escala en cualquier lenguaje Scripting.....

Entonces por eso digo todo es relativo. Si los lenguajes scripting son limitados segun porque no tienen capacidad para que hagas un SO con ellos... que pena, me temo que no existe mucha demanda la verdad en SO nuevos... mas si existe muchisima demanda en aplicaciones de uso general. Asi que como la ven  :P
#873
Scripting / Re: Opinion sobre aplicaciones hechas con lenguajes scripting
22 Febrero 2009, 18:46 PM
Lenguajes Scripting un poco Limitados???? En que sentido nene????  :huh:   :huh:

El problema es que mucha gente se confunde, pensando que si fulano programa en ASM hace unas tremendas mega aplicaciones potentisimas y si fulanito programa en JAVA por ejemplo, hace cosas pequeñas....

Mala teoria muy mala, ASM es lenguaje de bajo nivel, JAVA es de alto nivel lo cual lo hace sumamente entendible para el ojo humano a la hora de aprenderlo.

Los lenguajes Scripting no son limitados, cuando hablamos de aplicaciones de uso general. De hecho son hasta mejores que los de bajo nivel. Es bastante incomodo la verdad que realizes una aplicacion en C/GTK por colocar un ejemplo y realizes la mismita aplicacion en Perl/TK cual de las dos posee mas portabilidad sin modificaciones ni dolor de cabeza???? la de Perl/Tk.

Ya que la de C/GTK por la dichosa inclusion de la libreria GTK ya hay problemas... problemas porque si programaste tu aplicacion usando digamos GTK 2.x y sus funciones, y pasas los fuentes de tu aplicacion a otra PC donde tengo GTK 1.x que dolor de cabeza a modificar un sinumero de codigo y funciones inecesariamente porque sino jamas vas a poder compilarlo.. o a actualizar GTK 1.x a GTK 2.x esto sin contar el tremendo dolor de cabeza que implica actualizar las dependencias sin dañar el sistema.... Y ni te cuento si dicha aplicacion va para un SO Windows... a bajarse todas las dependencias nene, un compilador de C, la paqueteria GTK para Windows de la misma version del programa creado por ti ojo o sea GTK 2.x porque sino pasara el mismo rollo ya explicado...

Ahora hablemos de la misma aplicacion realizada en Perl/Tk y su portabilidad... lo puedes pasar de cualquier distribucion Linux a otra sin problema.. no importa que yo haga realizado mi aplicacion usando Perl 6.x y la otra PC tenga Perl 5.x el lenguaje sigue siendo estandar y el interprete de igual manera por ende la version no importa funcionara igual. Y el Tk??? que importa que yo tenga Tk 8 y la otra PC TK 6.... mi aplicacion no utiliza las librerias Tk , utiliza un modulo para Perl que implementa la mayoria de widgets de la libreria Tk pero es totalmente independiente de las librerias Tk y no necesita que las tengas siquiera instaladas para funcionar... Y como solo se creo un modulo Tk para Perl.. y mas nunca se ha actualizado ni se actualizara ni nada, mi aplicacion Perl/Tk sera 100% funcional tanto en Linux, Windows, Unix, Mac loquesea siempre y cuando el interprete Perl este instalado en el SO y el modulo Tk para Perl tambien... y eso se consigue en menos de 2 minutos con el manejador de paquetes de Perl.

Y que me dices cuando tu aplicacion implementa un odbc o trabaja directamente con binarios de base de datos? Aqui la tienes chungo si es en un hermoso y potente lenguaje compilado, si hablamos de C va perfecto con el Api C de MySQL pero y si lo quieres para Oracle? tendrias que bajarte el cliente de Oracle completo y portarlo a todas las PC´s donde tu aplicacion C trabajara con Oracle.. o si quieres puedes usar la libreria oci.h de Oracle para ahorrarte bajar el cliente Oracle en todas las PC´s pero trabajar con el oci.h de Oracle en C es bastante incomodo y solo va dirigido a gente con aspiracion de ser matematicos o desarrollar drivers...

Sin embargo, que comodo es trabajar con PHP en un entorno web, y conectar PHP a Oracle en el servidor y los clientes solo abrir su navegador poner la direccion del servidor y ya esta!!!

Todo es relativo la verdad, en cuanto a comodidad y portabilidad para mi percepcion los lenguajes scripting llevan la delantera. No son limitados para nada, son lenguajes de alto nivel bastante entendibles nada mas, pero no son limitados he inclusive existen mas modulos, y mas facilidades a la hora de embeberle una funcionalidad a estos que a uno de bajo nivel tipo C/C++, ASm y por ahi vamos.

No se duda la potencia de los lenguajes bajo nivel pero.. no voy de acuerdo con que los lenguajes Scripting son chiquititos y limitados.
#874
Bases de Datos / Re: MySQL, reporte "Registros duplicados" (Solucionado)
22 Febrero 2009, 02:51 AM
Anon que bueno que continues aprendiendo mas MySQL.

Ahora, obviamente esta consulta :

Código (sql) [Seleccionar]

SELECT * FROM tablaWHERE(id, grupo)IN(SELECT id, grupo FROM tablaGROUP BY id, grupoHAVING count(*)>1);


Tarda una vida entera en una tabla con una cantidad de registro enormes... hablamos de millones. Y la respuesta es mas que simple, en la consulta anterior no se esta filtrando por indices en ninguna parte, en el primer caso expuesto por ti, al ser 7000 registros pues la cosa no era complicada y no merecia filtrar la verdad sobretodo con la rapida respuesta de MySQL con las clausulas SELECT en tablas MyIsam.

Pero por experiencia personal, cuando debes hacer una consulta de registros masivos digamos millones de estos.. nosotr@s filtramos por indices. He visto tablas en Oracle donde inclusive el DBA creaba hasta 20 indices, y todo precisamente para que los analistas pudiesemos filtrar efectivamente y optimizar una consulta y no tardar 30 minutos esperando algo que puedo obtener en segundos con indices. Pero subsecuentemente te iras familiarizando mas y mas con cada necesidad de SQL el camino no es corto, pero vale la pena.

Tengo una anecdota muy peculiar, un programador profesional en PHP que conozco que hace gala de su certificaciones en Zend de PHP y de su diplomado universitario, y de que el sigue las reglas estructuradas de programacion y que el y que el... en fin, me intento discutir que era imposible realizar dentro de MySQL una consulta a 50 millones de registros donde esta no tardaze mas de 3 minutos. A lo cual le dije, yo puedo asegurarte dependiendo que consulta estas realizando que no la se, que no hay necesidad de que esto tarde tanto... y el insistia que si que si, que MySQL apestaba con devolver muchos registros, que era lento, etc...

Asi que hice algo similar a ti, pero no con C (El Api C de MySQL por cierto me encanta) cree una sencilla tabla en MySQL con 3 campos, id, nombre, apellido. Donde id era una llave primaria y nombre / apellido indices. Luego cree un Procedimiento Almacenado dentro de mi MySQL con un bucle que me lleno la tabla de registros hasta que alcanzo los 50 millones.... al finalizar.

Asi que procedi a hacer lo mismo que ignorantemente hacia mi amigo PHPlero al consultar 50 millones de registros (Mas para comprobarle a el, que el problema no era MySQL en si, sino el que no sabia generar una consulta SQL satisfactoria):

Código (sql) [Seleccionar]

SELECT * FROM tabla;


Eso me tardo obviamente unos 5 o 6 minutos en devolver... mas sin embargo utilize un poco de Tunning :) para exponer mi segunda consulta.

Código (sql) [Seleccionar]

EXPLAIN SELECT * FROM TABLA WHERE id IS NOT NULL and nombres IS NOT NULL and apellidos IS NOT NULL;


Luego de verificar el Tunning con Explain, vi que esa consulta estaba optimizada para el ejemplo que deseaba exponer a mi amigo, asi que la ejecute... y de 5 minutos.. esta bajo a 1 minuto, procedi a ejecutarla la tercera vez y de 1 minuto redujo finalmente a 0.70 segundos (Gracias a la Cache)

EN resumen, mi amigo no estaba utilizando indices, no tenia la Cache de MySQL activada tampoco.. y no utilizaba Tunning para evaluar que consulta SQL era la mas satisfactoria. Claro esto vas conociendolo en el camino repito.

Otra recomendacion que te puedo ofrecer Anon, si vas a guardar datos caracteres menores a 20 caracteres, procura utilizar CHAR en vez de VARCHAR.

CHAR consume muchisimo menos memoria Ram a la hora de lectura de datos en una consulta, y los datos tipo CHAR tienden a no corromperse facilmente cuando hay fallas por alguna razon en las transacciones. VARCHAR es mas vulnerable, y a no ser que sea extremadamente necesario ya sea que vayas a guardar una info un pelin larga yo suelo utilizar mas CHAR, es cierto que CHAR consume mas espacio de disco porque su tamano no es variante sino constante sin importar la cantidad de caracteres que ingreses, pero.. es mas estable a soportar fallas y es mas rapido en devolver a lecturas de consultas. En el caso de VARCHAR su tamano al ser variante pues se tarda unos segundos mas ya que la base de datos sea cual sea no solo aplica para MySQL, tiene que verificar el espacio consumido por un dato en el HD antes de seguir verificando hacia el otro dato y asi sucesivamente...

Despues de todo, me alegra sobremanera que estes animado a seguirle :)

Buena suerte en tu camino, son pocos los jovenes que dedican su tiempo en aprender cosas productivas como SQL en vez de ponerse a jugar con crack y troyanitos que a la larga no les servira de nada.



#875
PHP / Re: Busco: puesta en marcha de un sript a determinadas horas automaticamente
6 Febrero 2009, 21:36 PM
No todo el mundo sabe BATCH yo al menos no se BATCH de Windows....

Si tienes MySQL desde la version 5.1.x en adelante, create un evento dentro del mismo MySQL que funcionaria como una tarea programada.

Por ejemplo :

Código (sql) [Seleccionar]


mysql> CREATE EVENT EVENTO
ON SCHEDULE
EVERY 24 HOUR
DO

UPDATE TABLA1 SET REGISTRO1 = 'ALGO' WHERE REGISTRO1 = 'ALGUITO';



Con lo anterior si lo creas a las 8:00 pm de la noche se ejecutara cada 24 horas.. o sea todos los dias a las 8 de la noche siempre y cuando la PC este encendida.

Para crear un evento en MySQL requieres que el usuario tenga el privilegio SUPER o hacerlo con el usuario root de MySQL.
#876
PHP / Re: error consulta a BBDD en PHP
6 Febrero 2009, 15:25 PM
Tambien Agregate que cuando una tabla esta en un motor transaccional soporta 'llave foraneas' cosa que una tabla bajo un motor No transaccional solo soporta indices pero no soporta relacion padre-hijo 'llave foranea' con otra tabla  ;)

Recuerda las no transaccionales solo soportan indices, las transaccionales soportan indices y relacion padre-hijo o mejor dicho 'llaves foraneas'.
#877
PHP / Re: error consulta a BBDD en PHP
6 Febrero 2009, 01:36 AM
Hola respondiendo aqui .

Citar¿Como puedo saber si mi BBDD (MySQL) acepta transacciones?  ¿Y cómo quedaría la consulta completa finalmente?

Pues simple, las transacciones de registros en una tabla son definidas por el motor de almacenamiento en la cual esta fue creada. MySQL tiene distintos motores de almacenamientos disponibles, ahora por defecto al menos en Linux MySQL se instala utilizando el motor No transaccional MyIsam como motor asignado por defecto al crear una tabla, pero tengo constancia que MySQL para Windows suele instalar utilizando por defecto el motor Transaccional InnoDB.

Ahora que es un motor transaccional y que es un motor no transaccional. Un motor no transaccional (En este caso me referire a Myisam) es aquel en el cual cualquier cambio de los registros dentro de una tabla (Ya sea Insertar, borrar, actualizar datos) son automaticamente aplicados asap! sin permitirte regresar atras o recuperar alguna data sin querer perdida... todo es aplicado instantaneamente.

Un motor de almacenamiento Transaccional (En este caso usare de ejemplo InnoDB) es aquel en el cual cualquier cambio de los registros dentro de una tabla (Ya sea insertar, actualizar, borrar datos) no son instantaneamente aplicados a la tabla... sino que la consulta se ingresa a los registros de la tabla pero se queda en memoria en espera de una peticion de parte del usuario ya sea COMMIT (Aplicar cambios) o ROLLBACK (Retroceder a como estaba anteriormente) suponte que se guarda un backup del registro que tenias anteriormente, y sin querer eliminas 20 registros con la sentencia DELETE .... si tus tablas estan en un motor Transaccional tipo InnoDB puedes seguido del error que cometiste con DELETE.. realizar un ROLLBACK y la tabla regresara al ultimo registro existente antes de la consulta DELETE que realizaste. Esta ventaja NO existe en motores No transaccionales (Puedes probar).

Para habilitar y desabilitar las transacciones en MySQL no basta con que digas que tu tabla es InnoDB tienes que activar la variable encargada de ello tambien :

mysql> set autocommit = 0;

con el autocommit desabilitado, podras sacarle ventaja a Rollback y Commit en tus tablas Transaccionales. La ventajas de las transacciones es esa... que puedes o aplicar los cambios o retroceder al ultimo registro disponible... pero OJO. Si haces esto :

mysql> delete from tabla1 where nombres = 'pepe';
20 rows delete...

mysql> select * from tabla1;
bla bla bla....

mysql> rollback;

No volveras a obtener el registro 'pepe' ya que Rollback retrocede al ultimo registro aplicado antes de la consulta SQL realizada... no se si me explico.

Para tener desactivado el autocommit por defecto siempre, modifica tu archivo my.ini (Si es Windows) o my.cnf *Si es Linux*  y agrega en alguna parte :

autocommit = 0;

Sobre tu error de MySQL y PHP no me aclaro pero... te doy un consejo, comenta todas las consultas SQL que tienes ahi excepto la primera y ve probando una por una comentando y descomentando... para enterarte cual de todas es la que esta dando problemas con la consulta y asi poder ayudarte mejor.

Por cierto ON y WHERE es lo mismo en el caso que lo estas aplicando... puedes obviar el WHERE.
#878
PHP / Re: error consulta a BBDD en PHP
4 Febrero 2009, 15:52 PM
No aguanto la tentacion de ayudar  :D

Mira chico, yo te recomendaria que hagas una llave foranea padre-hijo entre las 2 tablas que tienes y elimines o no usas la tabla relacion N:M.

Puedes alterar las 2 tablas para esta accion, primero asegurate que ambas esten en un motor que soporte transacciones , ya que MyIsam que es No transaccional no soporta llave foraneas... necesitas un motor transaccional obligado para esto.

Código (sql) [Seleccionar]

ALTER TABLE JUGAD ENGINE = INNODB;
ALTER TABLE EQUIP ENGINE = INNODB;


Ya teniendo ambas tablas dentro de un motor transaccional (Esto no provocara ningun malestar a tus tablas calmado... lo unico que las tablas ocuparan un pelin mas de espacio en el disco pero no abusivo).

Ahora relacionamos ambas tablas usando sus indices.

Código (sql) [Seleccionar]

ALTER TABLE EQUIP ADD FOREIGN KEY(IDE_E) REFERENCES JUGAD(IDE_J) ON DELETE CASCADE;


Aca la tabla2 EQUIP es hija de la tabla1 JUGAD relacionadas ambas por sus indices.

Asi ya puedes hacer tus JOIN de 2 tablas relacionadas mediante una llave foranea, y te evitas la tarea que te mencione anteriormente mas el analisis de idear como no provocarte un producto cartesiano al utilizar 1 tabla tercera para relaciones  :xD

Un Saludo.
#879
PHP / Re: error consulta a BBDD en PHP
4 Febrero 2009, 15:02 PM
Corazon disculpame la imprudencia pero... sabes porque version de MySQL vamos ya??? por la 6.x alpha...

Y yo me pregunto, porque estas queriendo tu utilizar relacion de normalizacion muchos:muchos si ya existe metodos de relacion automatica con las llaves foreneas????
Y existen motores de almacenamientos transacionales para realizar este tipo de relaciones automaticas... tenemos a InnoDB, Falcon, SolidDB.... que realizan este tipo de relaciones mas controladas y automaticas.

Te digo esto porque, ese tipo de relacion que tu quieres utilizar, se utilizaba en Mysql 3.x y Mysql 4.x cuando era alpha... o sea cuando InnoDB aun era abstento a muchas fallas.... Pero ya desde MySQL 5.0 en adelante.. ha corrido mucha agua.

Mira lo que ocurre si insistes en hacer tu relacion de esa manera como quieres.

Tabla1
Tabla2
Tabla_Relacion.

Puedes hacer tus relaciones a manita, nadie te dice que no pero... ten muy pendiente que si lo realizas asi, tendras que tomar muy en cuenta la 'integridad referencial' o sea si deseas borrar un registro en cascada de la Tabla1 (que esté relacionado con la Tabla2) debes controlar tu mismo por médio de tu programación  o algun disipador que automaticamente los cambios se apliquen a la Tabla relacionada a la Tabla1. haciendo las consultas y validaciones necesarias "a manita".  Cuando puedes ahorrarte un monton de estas molestias relacionando tablas con llaves foraneas... que haran esto por ti automaticamente, actualizaran por ti automaticamente, evitaran a toda costa que se viole una llave foranea a la hora de querer eliminar un dato de una tabla Hijo.... Y como tu vas a controlar esa partecita del Eliminado 'accidental' a manita??? otro Disipador mas para que controle esto???

Hay no nino, la verdad no, yo te recomiendo de corazon, que hagas un ALTER a ambas tablas y las relaciones con una llave foranea en sus respectivos indices... Sino sabes como hacer esto, yo te ayudo. Pero deja de lado la normalizacion de referencia a manita, ya eso la verdad no aplica mucho actualmente.

#880
PHP / Re: error consulta a BBDD en PHP
3 Febrero 2009, 15:21 PM
Mi amor, mi vida, excusame si coloque un INNER JOIN poco entendible.... es que he quedado frustrada con el examen de Sun de MySQL... vienen unos Joines bien comoditos de 3 y 4 tablas relacionadas entre si parecidos a ese que te postee....

Mira esto :

Código (sql) [Seleccionar]
SELECT coln, tabla1.* FROM tabla1 INNER JOIN tabla2 ON  col1 = $_POST['dato1']

Es lo mismo que hicieras esto :

Código (sql) [Seleccionar]
SELECT b.coln, a.IDE, a.col1, a.col2, a.col3, a.col4, a.col5  FROM tabla1 a, tabla2 b WHERE  col1 = $_POST['dato1']

lo que pasa es, que si haces :

SELECT tabla1.*   

Estas diciendo en tu consulta, que selecciones todos los campos de la Tabla1 asi te evitas tener que haces uno a uno asi :

SELECT IDE, col1, col2, col3, col4, col5...

Entiendes????

Pero como todo es jerarquico, y es sabido que si vas a relacionar 2 tablas y algunos de sus registros no puedes hacer :

SELECT *

Porque incluiremos 2 tablas no 1, entonces le especificas a la consulta de que tabla quieres tomar todos los campos, en este caso Tabla1

SELECT tabla1.* 

Y hasta puedes indicarle en que base de datos esta tabla1...

SELECT   base_datos.tabla1.*

Y igual es valido  ;)

Ahora tu relacion es basada en 3 tablas??? porque dices que tabla1 y tabla_relacion contiene IDE1 y IDE2  y tabla2 contiene IDE2???? no entendi esa parte....

Pero para hacer tu relacion si fuesen 2 tablas ,  tabla1 y tabla2 seria algo asi:

SELECT tabla1.*, tabla2.coln, tabla2.IDE2  from  tabla1 INNER JOIN tabla2 ON tabla1.col1 = $_POST['dato1'];

O Asi lo mas comun:

SELECT  a.IDE1, a.col1, a.col2, a.col3, a.col4, a.col5, b.col2, b.IDE2 from  tabla1  a,  tabla2 b
WHERE a.col1 = $_POST['dato1'];

Tienes muchisimas formas de hacer tu JOIN.....

Espero haberme podido explicar bien :P
Páginas 1 ... 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96