Mensajes

Ten algo pendiente, MySQL no puede validar que usuario dentro de tu proyecto actualiza X campo de una tabla. Recuerda que dicho usuario que entre por web a tu pagina, se autentifica con tu web y unos datos guardados en alguna tabla de MySQL mas sin embargo se esta autentificando para ingresar a tu web con tu web, no se esta autentificando en MySQL... por ende MySQL no tiene en este caso absolutamente nada que ver con autentificacion de usuarios a traves de tu web, MySQL si tiene que ver con un usuario que ejecute mysql -u usuario porque ahi ese usuario se esta autentificando con el motor para entrar al motor, pero en el caso de tu web el usuario se autentifica con tu web para entrar a tu web   

Entonces no existe manera legal que MySQL conozca o manipule que usuario autentificado en tu web actualize algo en X tabla, ya que el acceso al motor de base de datos lo realiza 1 usuario, y a traves de ese usuario es que se hace todo dentro de las tablas. Pero ese unico usuario de mysql trabaja por todos los usuarios que se autentifiquen en tu proyecto.... (Espero que se entienda este tipo de explicacion). Ahora, como este es la situacion, al menos que crearas tu 1 usuario dentro de MySQL por cada usuario que se registre en tu web (Un crimen realmente  ) no hay manera que Current_user() te sirva.

Tendras que hacer como bien dices agregar un campo extra a la tabla que se va a modificar, y si necesitas alguna guia con el TRIGGER me comentas, y asi con ese campo 'extra' en la tabla que se va a modificar cada vez que se actualize pos se agregara que usuario (ayudandose en este caso de la variable en PHP de session) modifico esa data.

Ahhhh pos entonces el tamano ha reducido.     la segunda tabla ya tiene los indices incluidos??? (Los indices numericos de lo mas que te puede servir es optimizar la velocidad de respuesta a la hora que hagas una consulta)

Si sabes que no vas a eliminar ni actualizar campos en tu tabla, puedes considerar usar myisampack para comprimir la tabla y reducir un 60% su tamano en disco.

Lo siento.... con estas imagenes no entiendo nada 

No uso phpmyadmin y no entiendo nada de lo que veo aca, me parece escritura japonesa. QUe es eso de cardinalidad? porque si tu campo es Unique o Primary es imposible que accepte valores duplicados, eso de Cardinalidad es el tamano del dato en el campo??? 

No puedes usar una funcion de MySQL para esto, recuerda que dicho usuario se esta identificando en una pagina con registros guardados dentro de una tabla de MySQL. Tendrias por lo tanto que utilizar el valor guardado en la session de PHP y justo cuando ese usuario haga alguna actualizacion o algo que modifique una tabla, seria despues del UPDATE enviar otra SQL que diga algo como 'select usuario from tabla where usuario = session_id'...

No me catalogues de metiche    pero podria comprender un poco mas tu peticion, si me colocaras aunque fuesen tablas no reales de ejemplo de mas o menos como tienes estructurado estos dos puntos (la tabla usuario, la tabla que se modifica y tu trigger) para mas o menos asi ir aclarandome un poco las ideas y poder ampliar en ayudarte.

Todas las aplicaciones que se ejecutan en un sistema operativo son un programa, la diferencia es que cada programa se desarrolla para alguna funcionalidad, en este caso MySQL se desarrollo para ser un motor de base de datos con soporte relacional y con lo que esto conlleva (Apis y librerias para desarrollar en este, un cliente para conectarse a el, etc) Asi como las condiciones que conlleva ofrecer manejo de la informacion bajo relaciones.

Se usa MySQL en la web porque aca almacenas la informacion necesaria (como usuarios, mensajes, imagenes - aunque no es recomendable almacenar una imagen dentro del motor - etc) por ende MySQL al ser rapido en lectura y respuesta y ser GPL en parte se ha hecho muy popular entre la programacion web, de ahi que se use con PHP y otros lenguajes para el entorno web.

Yo no soy muy apta con PHP estoy segura que otros daran mejores links que yo, pero para empezar a manipular PHP con MySQL me gusta:

http://phpya.com.ar

Ahora, hay un problema gigante con dar por obvio el .com, ya que puede ser .com, .com.ar, y demas.. Por eso la idea de reemplazar por simbolos.

Exactamente, como este punto se desconoce (de igual manera si una URL tiene o no www o solo usa http) entonces como tus datos No son constantes... no puedes dar por hecho reemplazar cosas por simbolos. En esa parte ya se ha aclarado que lo unico mas probable que podrias sustituir son los www y los http. Como te decia puedes comprimir las tablas pero deberas conllevar el inconveniente que te expuse (no eliminar no actualizar).

Mi pregunta es:
Esos numeros que identificarán al link, que serán el indice PRIMARIO, no terminaran ocupando mas espacio que si tuviese como indice PRIMARIO al link?

Depende, el indice primario que usaras como link cuanto tiene de longitud y que informacion guarda??? porque por ejemplo, si ese indice primario guardase cosas como :

google
msn
yahoo

Perfecto.. no es necesario dar uso a un campo numerico y procura declarar el campo como CHAR en vez de VARCHAR, pero si ese link ocupara cosas como:

google.com/index.html/imagen?
yahoo.com/?pagina.php/imagenes.png

En ese caso No conviene usar indice primario algo asi... una porque el campo en cuestion seria de tipo VARCHAR y VARCHAR es un tipo de dato dinamico no constante, con dinamico implica que aunque tu le des una longitud por ejemplo de 50 bytes si tu informacion ocupa 20 bytes pos nada de esos 50 el ocupa 20 y lo otro lo trunca... y es favorable que para indices se utilizen datos constantes no variables ya que pueden corromperse bajo alguna condicion que no detallare aca porque seria extensa. Por ende si sabes que los links tendran datos de tamano distintos opta por declarar otro campo numerico como te decia.

Que me dices de las Coliciones con ese numero que identifica? Hay probabilidades de que haya 2 numeros iguales para 2 links diferentes?

No, no habran colisiones con ese numero generado por la funcion crc32 que es una funcion matematica, recuerda que dicho campo sera un indice PRIMARIO o UNICO por ende, jamas generara 2 datos iguales, mas bien unicos. (Eres libre de hacer una prueba) los datos son unicos bajo las condiciones que daras, la ventaja es que el campo al ser numerico y como tu sabes que bajo el sistema operativo solicitar informacion numerica es mucho mas rapido que obtener informacion en caracter y luego convertirlo a numerico para entonces interpretar lo que significa, con el campo siendo numerico te evitas ese pekeno pasito extra 

Ten en cuenta que tus datos de las URL no son constantes, por ende definir caracteres de algo para sustituir algunas palabras, no te funcionaria del todo, ya que esto podria provocar que se trunquen data de URL, asi como que 2 URL sean similares    si tus tablas estan guardadas en motor Myisam, puedes optar por usar la funcionalidad myisampack. Para comprimir tus tablas y asi reducir considerablemente el tamano, por ejemplo checa esta tabla que tengo:

Código (sql) [Seleccionar] Expandir



mysql> select * from ejemplo;
+------------+----------------------------------+
| indice     | direccion                        |
+------------+----------------------------------+
| 1587574693 | http://www.google.com            |
|  416577886 | http://www.yahoo.com             |
|  721517199 | http://www.msn.com               |
| 3177037030 | http://www.gogo.com              |
| 1722868955 | http://www.coco.com/imagenes.png |
|  650421202 | www.cucu.com                     |
| 1509117005 | www.foro.org                     |
+------------+----------------------------------+
7 rows in set (0.00 sec)




Y son poquitos datos, pero checa cuanto me ocupa en disco duro el archivo data y indice.

bash-3.1# du -sh *
4.0K    backup1.sql
4.0K    db.opt
94K     ejemplo.MYD
4.0K    ejemplo.MYI
12K     ejemplo.frm

94KB la data    un poco extenso para 7 miserables registros no... asi que uso la utilidad myisampack y comprimo:

bash-3.1# myisampack ejemplo.*

Ahora checa como redujo:

bash-3.1# du -sh *
4.0K    backup1.sql
4.0K    db.opt
4.0K    ejemplo.MYD
4.0K    ejemplo.MYI
12K     ejemplo.frm

de 94KB a 4.0KB y la data sigue intacta dentro de las tablas.

Ahora existe un incoveniente con myisampack (ya que no todo es religiosamente maravilloso) al comprimir la data, la tabla en cuestion solo tiene permiso de Lectura, por lo que te permite INSERTAR y SELECCIONAR datos, pero no te permite eliminar registros ni actualizar registros 

Otra manera opcional que podrias considerar es utilizar un procedimiento almacenado, para al menos la data que si estas seguro que es constante (como los www y los http) pos hacerlos asi:

Esta es mi tabla por ejemplo:

Código (sql) [Seleccionar] Expandir


mysql> select * from ejemplo;
+------------+-----------+   
| indice     | direccion |   
+------------+-----------+   
|  526628817 | google    |   
| 3748556277 | yahoo     |   
| 1257958042 | msn       |   
+------------+-----------+   
3 rows in set (0.00 sec)     



Y hago un procedimiento:

Código (sql) [Seleccionar] Expandir



mysql> create procedure copia(palabra char(20)) begin select concat('http://www.', direccion, '.com') from ejemplo where direccion = palabra; end;/
Query OK, 0 rows affected (0.00 sec)                                                                                                               

mysql> delimiter ;
mysql> call copia('google');
+------------------------------------------+
| concat('http://www.', direccion, '.com') |
+------------------------------------------+
| http://www.google.com                    |
+------------------------------------------+
1 row in set (0.01 sec)                     



No hay porque reducir palabras para ello... tienes registros en una tabla que son puras direcciones URLs pero sabes que usarlas de indice es un crimen para el optimizador interno del motor y esto sin contar la lentitud que provocaria    tengo un amigo programador en PHP que tenia un problema similar. El me decia como puedo crear un campo indice (ID) para cada Url si yo no voy a recordarme que ID le corresponde al registro 200 (por ejemplo). Entonces le di una solucion que espero tambien te pueda servir he de igual forma a otros webmasters porque se que esto es un dilema que ha de ocurrir bastante.

Tu me confirmas que tienes una tabla que solo guarda direcciones URLs en los campos. Asumo que es algo mas o menos asi:

Código (sql) [Seleccionar] Expandir



mysql> select * from ejemplo;
+-------------------------------------+
| direcciones                         |
+-------------------------------------+
| http://www.google.com               |
| http://www.yahoo.com/index.html     |
| http://www.amazon.com/index.php     |
| http://foro.elhacker.net/index.php  |
| http://www.unix.com/index.html?id=5 |
+-------------------------------------+
5 rows in set (0.00 sec)



Y tienes como index dicho campo (en mi caso direcciones) que es un VARCHAR de longitud variable le asigne 70 de longitud pero sabemos que es dinamica la reserva aca    eso es cruel y pesimo de usarlo como indice. Reducir o quitarle los 'http'  no es solucion. Asignarle un ID tampoco porque no vas a saberte el ID correspondiente a cada URL vamos (sobretodo si hablamos de cientos sino miles de URL como registros). Asi que tienes una opcion especial, asigna un campo extra de tipo DECIMAL el cual usaras como indice:

Código (sql) [Seleccionar] Expandir



mysql> alter table ejemplo add codigo decimal(10,0);
Query OK, 5 rows affected (0.07 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> create index indice on ejemplo(codigo);
Query OK, 5 rows affected (0.07 sec)
Records: 5  Duplicates: 0  Warnings: 0



En esta parte la tarea te costara, pero valdra la pena, ya que ahora insertaras los datos de esta manera a la DB:

Código (sql) [Seleccionar] Expandir



mysql> insert into ejemplo values('http://www.google.com',crc32('http://www.google.com')), ('http://www.yahoo.com',crc32('http://www.yahoo.com')), ('httpd://foro.elhacker.net',crc32('http://foro.elhacker.net'));
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from ejemplo;
+---------------------------+------------+
| direcciones               | codigo     |
+---------------------------+------------+
| http://www.google.com     | 1587574693 |
| http://www.yahoo.com      |  416577886 |
| httpd://foro.elhacker.net |  794697805 |
+---------------------------+------------+
3 rows in set (0.00 sec)


Ahora diras sino puedo recordarme de un ID sencillo de 1 o 2 cifras como voy a recordar esos numeros tan largos en el campo codigo    simple la busquedad de la data la haras asi:

Código (sql) [Seleccionar] Expandir



mysql> select * from ejemplo;
+---------------------------+------------+
| direcciones               | codigo     |
+---------------------------+------------+
| http://www.google.com     | 1587574693 |
| http://www.yahoo.com      |  416577886 |
| httpd://foro.elhacker.net |  794697805 |
+---------------------------+------------+
3 rows in set (0.00 sec)

mysql> select * from ejemplo where codigo = crc32('http://www.google.com');
+-----------------------+------------+
| direcciones           | codigo     |
+-----------------------+------------+
| http://www.google.com | 1587574693 |
+-----------------------+------------+
1 row in set (0.02 sec)

mysql> select * from ejemplo where codigo = crc32('http://www.yahoo.com');
+----------------------+-----------+
| direcciones          | codigo    |
+----------------------+-----------+
| http://www.yahoo.com | 416577886 |
+----------------------+-----------+
1 row in set (0.00 sec)





Vas captando algo muchacho? Ahora analizemos que dice el optimizador de MySQL sobre esta consulta:

Código (sql) [Seleccionar] Expandir



mysql> explain select * from ejemplo where codigo = crc32('http://www.yahoo.com');
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
| id | select_type | table   | type | possible_keys | key    | key_len | ref   | rows | Extra       |
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
|  1 | SIMPLE      | ejemplo | ref  | indice        | indice | 6       | const |    1 | Using where |
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
1 row in set (0.00 sec)



rows = 1
reference = const

  super....

Me alegro que te sirviera de ejemplo    lo unico negativo que veo en ello es que si independizas muchas ventanas pos seria una carga (aunque minima) extra en memoria. Pero creo que por etica y por comodidad es mas preferible dividir las cositas en modulos. Tambien hay opcion en el Api TK de ocultar la ventana principal cuando otra abre y cuando esa otra que abrio cierra volver a aparecer la ventana principal que estaba escondida (pero alojada en memoria) pero ciertamente se hacerlo en Perl/Tk mas no Python/tk aunque asumo el proceso debe ser similar.

Un saludo 

Bueno no es que sea yo experta en Python y Tk nisiquiera python 

Pero como conozco el API Tk ya que lo manejo con Perl, claro que puedes independizar un poco una aplicacion de otra... haciendola de tipo modular tu entiendes. Por ejemplo:

Esta es la Ventana Uno:

Código (python) [Seleccionar] Expandir



#!/usr/bin/python

from Tkinter import *
from modulo import *

ventana = Tk()
ventana.title("Proyecto")
boton = Button(ventana, text = "Pinchame", width = 15, relief = 'raised', command = (lambda: Ejemplo()))
boton.grid(row = 1, column = 2, padx = 5, pady = 5)

ventana.mainloop()


Esta es la ventana Dos (llamada modulo.py)

Código (python) [Seleccionar] Expandir



#!/usr/bin/python

from Tkinter import *

def Ejemplo():
  ventana1 = Tk()
  mensaje = Label(ventana1, text="Hola Mundo")
  mensaje.pack()
  ventana1.mainloop()



El unico inconveniente es la carga en memoria que esto genera