Mensajes

SI existe relacion entre el ejemplo que coloque, fijate bien en el campo ID de ambas tablas y el resultado que este retorna en base a una consulta.

O lo desgloso para que sea mas entendible:

Código (sql) [Seleccionar] Expandir


mysql> SELECT * FROM usuarios;
+------+------------+----------------------------------+
| id   | nombre     | contraseña                       |
+------+------------+----------------------------------+
|    1 | ^Tifa^     | 202cb962ac59075b964b07152d234b70 |
|    2 | Winder     | 81dc9bdb52d04dc20036dbd8313ed055 |


Tomare de ejemplo yo y Winder.

ID ^Tifa^ = 1
ID Winder = 2

Ahora fijate la tabla relacion, que usuarios son amigos de ^Tifa^? los siguientes:

Código (sql) [Seleccionar] Expandir


mysql> SELECT a.nombre AS usuario,b.nombre AS relacion FROM usuarios a INNER JOIN relacion b USING(id) WHERE b.id = 1;
+---------+----------+
| usuario | relacion |
+---------+----------+
| ^Tifa^  | Winder   |
| ^Tifa^  | Napk     |



Segun la consulta dice que Winder y Napk ambos son amigos de ^Tifa^ ahora se confirma, en la tabla relacion correspondiente al ID = 1 que es ^Tifa^ que usuarios son amigos?

Código (sql) [Seleccionar] Expandir



mysql> SELECT * FROM relacion;
+------+--------+-----------+
| id   | codigo | nombre    |
+------+--------+-----------+
|    1 |      2 | Winder    |
|    1 |      3 | Napk      |



ID = 1 (Que es ^Tifa^) tiene dos amigos con nombre Winder y Napk

Pero posiblemente para que sea mas entendible, andas solicitando el modelo Entidad-Relacion:

Usuario -> ID -> Relacion

Esa es la relacion de estas 2 tablas.

Habran ocasiones que tendras que utilizar este tipo de modelado, por ejemplo un formulario WEB donde el usuario pueda elegir una o varias categorias de loquesea, digamos gustos particulares (Donde el usuario debe elegir que le gusta la informatica, la PC, la tecnologia, los procesadores, etc)... entonces vas a necesitar 2 indices en vez de 1 y uno de esos 2 tendra que repetirse para poder relacionar 1 usuario con varias categorias que este usuario eliga en su formulario...

Ahora preguntate como en InnoDB que es un motor transaccional, tu puedes implementar el tipo de relacion anterior y expuesto en mi ejemplo con tan solo usando 1 indice por tabla. Si vas a responderme diciendome que puedes usar un campo ENUM no es valido, ya que si tu tienes 10 categorias y en un futuro tienes que agregarle mas... que vas a hacer? tener una tabla del tamanio de un libro por el mero hecho de no disenarla desde un inicio con 2 indices en vez de 1?

Si estan las relaciones creadas    basadas en el modelo tradicional Entidad-Relacion. Recuerda que antes no existian motores de almacenamientos transaccionales (Me refiero cuando nacio Oracle alla por los inicios del ochenta) no existia una implementacion que manejase de forma automatica una relacion entre 2 o mas tablas, entonces utilizan este modelo que viste en mi ejemplo, y que mencionan con constancia otros usuarios que han respondido a este post, y el modelo continua hoy dia siendo bastante efectivo  y todavia se utiliza.

Cuando nacio InnoDB como motor de almacenamiento transaccional, este utiliza ese mismo modelo que has venido observando, la diferencia es... que este motor continue funcionalidades y mejoras internas que no posees si utilizas el modelo de relacion tradicional. Entre estas funcionalidades de InnoDB esta que no permite violacion de llaves foraneas, lockeo de filas en vez de toda la tabla, uso de indices clustered, entre otras cositas, que tu sabes que en el tipo de relacion tradicional no es aplicable entonces lo que se suele hacer es crear triggers para manejar este tipo de cosas que InnoDB internamente ya porta (el trigger es para evitar que se viole la llave foranea de la tabla padre) obviamente implica mas esfuerzo y mas cosas que realizar y que InnoDB implementa de forma automatica. Pero, por otro lado todo dependera de que te conviene por optimizacion sobretodo, y aun no me han dado Base de Datos en la Universidad pero estoy consciente que el modelo que exhigen es el modelo tradicional, no el moderno con InnoDB que hace todo por ti y el estudiante no se entera realmente porque eso funciona asi, como y debido a que.

Que lindos 

Feliz año a todos, recuerden no excederse con el alcohol, permanecer tranquilos en su casita que hoy las calles estan peligrosas esta noche con gente borracha y alocada.

Espero la pasen super bien y, sobretodo se propongan buenas metas para el 2010 y se cumplan todas las propuestas deseadas por tod@s ustedes.

Un abrazo enorme son todos unos encantos 

VARCHAR 0 a 255 hasta MySQL version 5.0.3 despues de esta version VARCHAR tiene capacidad de almacenamiento de 0 a 65,535 caracteres + 1 byte que corresponde a '0'

el tipo de dato TEXT me parece que tiene una longitud maxima similar a VARCHAR '65,535 caracteres' puede darse la situacion que estes intentando insertar mas caracteres que esa cantidad maxima o puede darse el caso que la variable 'max_allowed_packet' este modificada y le colocarian un limite demasiado pequeno (Lo cual es normal es un servidor compartido). Y como lamentablemente no puedes editar esta variable porque afectaria al resto de clientes (Encima dudo que te den permiso a editar my.cnf) puedes optar por utilizar (Si estas seguro que no sobrepases 65,000 caracteres) VARCHAR(65500) por ejemplo, o para optimizar un poco el asunto VARBINARY(65500). (Es mas rapido para el motor leer datos binarios que caracteres)

Ya que el tipo de datos LONGTEXT bueno..... tamanio variable, y un maximo aproximado de 4GB    yo lo pensaria....

Se que hay una mejor manera de estructurado  y no culpo al que quiera jalarme las orejas por ello... pero esto es un mero ejemplo 

Código (sql) [Seleccionar] Expandir



mysql> select * from relacion;
+------+--------+-----------+
| id   | codigo | nombre    |
+------+--------+-----------+
|    1 |      2 | Winder    |
|    1 |      3 | Napk      |
|    2 |      4 | Randomize |
|    3 |      1 | ^Tifa^    |
|    6 |      1 | ^Tifa^    |
|    6 |      2 | Winder    |
|    6 |      3 | Napk      |
+------+--------+-----------+
7 rows in set (0.00 sec)     

mysql> select * from usuarios;
+------+------------+----------------------------------+
| id   | nombre     | contrasena                       |
+------+------------+----------------------------------+
|    1 | ^Tifa^     | 202cb962ac59075b964b07152d234b70 |
|    2 | Winder     | 81dc9bdb52d04dc20036dbd8313ed055 |
|    3 | Napk       | 81dc9bdb52d04dc20036dbd8313ed055 |
|    4 | Randomize  | 698d51a19d8a121ce581499d7b701668 |
|    5 | Festor     | 81dc9bdb52d04dc20036dbd8313ed055 |
|    6 | seba123neo | 81dc9bdb52d04dc20036dbd8313ed055 |
|    7 | Tux        | c20ad4d76fe97759aa27a0c99bff6710 |
+------+------------+----------------------------------+
7 rows in set (0.00 sec)                           

mysql> select a.nombre as usuario,b.nombre as relacion from usuarios a inner join relacion b using(id) where b.id = 6;
+------------+----------+
| usuario    | relacion |
+------------+----------+
| seba123neo | ^Tifa^   |
| seba123neo | Winder   |
| seba123neo | Napk     |
+------------+----------+
3 rows in set (0.00 sec)

mysql> select a.nombre as usuario,b.nombre as relacion from usuarios a inner join relacion b using(id) where b.id = 1;
+---------+----------+
| usuario | relacion |
+---------+----------+
| ^Tifa^  | Winder   |
| ^Tifa^  | Napk     |
+---------+----------+
2 rows in set (0.00 sec)



[Servia]

Hola nuevamente.

Yo encantada con poder ayudar en lo poco que pueda, no soy programadora PHP ciertamente.

Servia

No te sorprendas de este hecho, no eres el unico... creeme de 10 programadores PHP si 2 saben de la existencia de estas funciones es mucho    lo que ocurre es que el programador generalmente no se lia con optimizacion de consultas o base de datos o del servidor en si, el solo quiere que su codigo sea funcional y entendible, lo cual es normal es un programador no un analista de optimizacion.

La razon por la cual existen 2 funciones (mysql_query & mysql_unbuffered_query) es que hay limitaciones y condiciones que te aportan mysql_query que mysql_unbuffered_query no, por eso dije indaguen via Google la funcionalidad y limitaciones de mysql_unbuffered_query, para que tengan una idea de cuando les conviene usarle y cuando no, aca pego una URL:

http://www.php-es.com/function.mysql-unbuffered-query.html

fede_cp

Lamentablemente poco te puedo ayudar con PHP, conozco un poco como funciona debido a que trabajo con PERL y MySQL y las API (los modulos) trabajan de manera similar sin importar el lenguaje en cuestion. No puedo en este subforo hacer una extension muy amplia de como funciona realmente MySQL en su parte interna, pero todo influye y si puedes ahorrarte un poco el consumo de memoria sea a traves del codigo, sea a traves del motor DB, hazlo. No todo es solamente 'No puedo cargar el motor DB' aveces cargamos cosas en la RAM y dicho cuello de botella viene por el codigo fuente y la libreria y no tanto del todo por el motor DB.

Hay una funcionalidad que utilizo mucho en PERL (aplicable en PHP y otros lenguajes) para medir y optimizar tu codigo en cuanto a consumo de CPU y memoria (Esto es indiferente al funcionamiento del motor DB) dicha tecnica se llama Benchmarking, para empezar te doy este link:

http://www.desarrolloweb.com/articulos/calcular-tempo-ejecucion-script.html

Pero a traves de Google encontraras muchos mas que te serviran de guia para medir la ejecuciones de tus aplicaciones en PHP    

Si quieres realizar lo mismo en el motor DB ya es otro asunto, pero te vale por el momento la respuesta de medir tu script.

Sobre el diseno de tu aplicacion, me gusta la pantalla de instalacion aunque a mi opinion personal se veria mas bonita si dicha pantalla ocupase el index completo (Lo mismo para las demas pantallas como Portafolio, despues de logeado, etc), y las ventanitas que piden la informacion estuviesen de manera alineadas (una bajo la otra). Es solo mi opinion que conste, si la consideras y decides ampliar la pantalla a modo completo, tambien deberias ampliar dichas ventanitas de solicitud de informacion para que no se vean pobres dentro de tanto espacio. Y ampliarlo no seria tan negativo  te permitiria colocar botoncitos de Ayuda al lado de cada Entry (Para los usuarios que no sepan que informacion colocar en los Entry).

[mysql_unbuffered _query()]

Ya que veo que la aplicacion es nueva, (poco codigo comparado a otros proyectos que uffff he visto) y hablan de optimizacion    les dare una orejita. Tomen de costumbre utilizar la funcion  mysql_unbuffered _query() en vez de mysql_query    la razon? bueno pueden investigar en Google, pero una resumida mas rapidita.

la libreria mysql que utiliza PHP para trabajar con el motor (Tambien aplica para las librerias mysql de Perl, python, etc) poseen un pequeno Buffer de almacenamiento, dicho Buffer existe para tomar todos, todos los registros sin excepcion y sean la cantidad que sean de una o mas tablas (Depende la consulta SQL que hayas definido en tu codigo) y guardarlos en el Buffer de la libreria mysql del lenguaje de programacion (No hablo del buffer del proceso o del motor de Mysql DB). Sino de la libreria (API) que estan usando para programar en PHP. Esta libreria tiene ese Buffer, y la cosa funciona mas o menos asi:

Supongamos que tienen una consulta en PHP tipo:

$consulta = SELECT * FROM tabla WHERE codigo = 1
mysql_query($consulta, $conexión)

Que hace realmente la linea anterior en el motor DB? pues nada si la tabla 'Ejemplo' tiene 5 mil registros en total, esos 5 mil registros primero bajan al motor y luego cargan al Buffer del (API) entonces una vez esos 5 mil registros existen en el Buffer del (API) entonces PHP procesa la consulta SQL en el Buffer de su (API)  no en el motor DB como tal, por ende esto es perdida de tiempo    (Cuando practiquen con optimizacion de codigo y base de datos 'Benchmark' y 'Profiling' se daran cuenta).

En vez de dar uso de la funcion mysql_query() y generar doble buffering como llamaria yo a este proceso (primero cargar todo al motor y luego pasarlo al buffer de la API... y no quiero imaginar si el motor tiene la Cache habilitada esto seria trillizos Buffering juas  ) utilizen la funcion mysql_unbuffered _query() asi obvian cargar en el buffer de la API todosssssss los registros y luego entonces procesar la consulta SQL sobre los datos existentes en ese buffer lol... es mejor trabajar directamente sobre el motor DB y obtener los resultados directamente desde el motor como tal 

Es solo mi humilde opinion.

Hola.

Efectivamente SKuLLKiD de acuerdo contigo    me parece que la longitud que el le definio al campo es menor que lo que soporta y lo esta cortando. Dale una longitud mayor, y no uses ese campo de indice!

Asi el tipo de dato no te cortara la palabra cifrada con MD5 

Lol seba123neo

Haber chico depende, suponte que quieres la informacion (nombres, apellidos, telefonos) de distintas personas. Procedes a crear 1 sola tabla con todos los datos asumiendo que es suficiente:

Código (sql) [Seleccionar] Expandir


SQL> create table data(
  2  nombres char(20),
  3  apellidos char(20),
  4  id integer,       
  5  primary key(id),       
  6  telefono nchar(20));

Table created.


Y vienes y quieres insertarle datos ahora:

SQL> insert into data values('Juan Manuel', 'Perez', 1, '555-2344');

1 row created.

SQL> insert into data values('Juan Manuel', 'Perez', 1, '666-3455');
insert into data values('Juan Manuel', 'Perez', 1, '666-3455')     
*                                                                   
ERROR at line 1:                                                   
ORA-00001: unique constraint (MARIAN.SYS_C005303) violated         

Te da error porque obviamente el campo ID que es primario no accepta valores repetidos, por ende o obvias tener el campo primario o le agregas otro valor distinto a 1 pero en este caso terminarias con algo tipo:

Código (sql) [Seleccionar] Expandir



SQL> select * from data;

NOMBRES              APELLIDOS                    ID TELEFONO
-------------------- -------------------- ---------- --------------------
Juan Manuel          Perez                         1 555-2344           
Juan Manuel          Perez                         2 555-2344
Juan Manuel          Perez                         3 555-2344



O quizas quieras resolver rapido, y en vez de declarar el campo ID como primary key lo declares como KEY o INDEX para repetir valores y terminarias con algo tipo:

Código (sql) [Seleccionar] Expandir


SQL> select * from data;

NOMBRES              APELLIDOS                    ID TELEFONO
-------------------- -------------------- ---------- --------------------
Juan Manuel          Perez                         1 555-2344           
Juan Manuel          Perez                         1 678-2344
Juan Manuel          Perez                         1 777-2234



Que a la hora de consultar la tabla seria mas rapido en retornarte el valor que si hicieras JOIN con otra, pero aunque esto a nivel de optimizacion es mas rapido, te dejaria valores repetidos y redundantes en la tabla como el ejemplo expuesto anteriormente... por ende en su lugar seria favorable eliminar el campo telefono de la tabla Data y crear otra tabla que haga referencia al telefono de cada usuario.

Código (sql) [Seleccionar] Expandir


SQL> create table copia(
  2  id integer,       
  3  telefono nchar(20));

Table created.

SQL> create index indice on copia(id);

Index created.




Le insertas datos:

Código (sql) [Seleccionar] Expandir


SQL> insert into copia values(1,'666-7655');

1 row created.

SQL> insert into copia values(1, '765-4599');

1 row created.

SQL> select * from copia;

        ID TELEFONO
---------- --------------------
         1 666-7655
         1 765-4599




Y ya tienes una tabla no desnormalizada donde puedes agregar todos los telefonos que quieras para un usuario en especifico, y consultar esos datos de retorno:

Código (sql) [Seleccionar] Expandir


SQL> select a.nombres, b.telefono from copia b, data a;

NOMBRES              TELEFONO
-------------------- --------------------
Juan Manuel          666-7655
Juan Manuel          765-4599





Ambos son indices. La mayor diferencia radica en que KEY accepta valores nulos y repetidos, sin embargo PRIMARY KEY no accepta valores nulos ni repetidos