Perdoname.... te decia que los calculos y los numeros me vuelven un ocho .... es como que me hablasen chino o japones...

Pero si estas seguro que funcionara.. puedes concatenar mas de 2 valores usando  ||

Algo asi como:

INSERT INTO TABLA VALUES(CRC32=campo1||CRC32=campo2||CRC32=campo3||'123'||'456');

 

Honestamente... aunque se lea cruel, yo poco te puedo ayudar en esta logica presentada    la razon? soy extremadamente mala, mediocre, pesima cuando se me presenta algun tema donde me hablen de numeros y funciones matematicas.

No quiero decirte una tonteria, y a lo mejor este equivocada (que tengo mas fe que si) pero... si sacas el CRC32 de los 3 indices y lo concatenas esto en que diferenciaria en que saques 1 solo CRC32 de 1 indice??    o sea.. CRC32 su maximo seran 4 billones de entradas perfecto, que haras tu cuando concatenes 3 convertisiones CRC32 de 3 indices... si despues que pase de 4 billones habra colision???    si hubiese algun bucle o algo que diga que despues de 4 billones de entradas pos se le sume un numero extra al final ya es otro asunto que podria ser valido y evitar colisiones....

Pero hay otro dilema    si se hace lo del bucle.. como se usaria el indice CRC32 si cuando digas traeme el link donde el hash1 = 'www.google.com'  por ejemplo.... el retornaria nada porque el valor de la ultima cifra fue generada por un contador 

Repito puedo estar diciendo una tonteria.. los numeros efectivamente no se hicieron para mi 

datos constantes son datos fijos tu sabes, asi como puedo decir un campo de longitud constante es un campo que si defines su longitud 20 espacio ocupara esos 20 espacios aunque tu le insertes una informacion de 10 espacios 

SI suponia que podia implementar todo eso del reemplazo en el codigo PHP, solo que yo te lo sugeri como procedimiento almacenado dentro del Motor MySQL, pero eso mismo que expones para PHP fue lo mismo que sugeria pero para un procedimiento almacenado    creo que es mas comodo de esta forma que crear varias tablas ciertamente.

Sobre eso de palabras repetidas y como se llaman, no hay un nombre... la longitud del campo que guarda este dato puede ser constante (CHAR por ejemplo) sin embargo quien condiciona si el dato se repite o no es si tu declaras este campo como una llave primaria o como un indice unique. Fuera de esto si declaras dicho campo como index o key seran indices pero podran repetirse.

Tienes 1 campo (indice) comun en todas las tablas que relaciones (sean 5 o 6) hay 1 campo comun en todas????

No me preocupa mucho que cada tabla tenga 30 campos por ejemplo, lo que se analizaria aqui serian 2 o 3 campos por cada tabla.

Las otras 5 o 6 tablas tienen o no un campo en comun con las que se relaciona?

SI jujub si ya se hablo de las posibles colisiones de CRC32  despues de 4 billones de entradas  de ahi surgio las recomendaciones de funciones externas y links que le referi para descargarselas. Pero creo que Skeletrum le busco la vuelta ya a este dilema.

Si yo fuese Skeletrum, usase procedimientos almacenados para reemplazar valores por cosas fijas como http y www.

A todo esto.... pareciera que volaste cuando te recomende la sustituciones de valores constantes con un procedimiento almacenado 

Porque no generas un procedimiento almacenado en Mysql que diga que cuando reciba no se la palabra 'google' le agregue 'http://www' y '.com'.... etc, etc, etc....

Te puse un ejemplo en la pagina anterior ... hubiera trabajado sobre ese procedimiento almacenado en vez de crear mas tablas y un algoritmo que analize las 3 tablas para obtener una solucion....

digo yo no 

Disculpa que no te este entendiendo muy bien en tus ultimos comentarios...


Eso solo te retornara todos los campos links donde el campo hash1 sea igual a 123 y eso lo sabias. Lo poco que he entendido (y explicame sino es asi) es que seguido obtengas el link correspondiente al hash1 = 123 digamos que ese link es 'wikipedia' estas diciendo que si luego tendrias que ir a una segunda tabla con otra consulta y ver que campos links corresponden a 'wikipedia' y despues de eso ejecutar el algoritmo este que reemplazara todos esos datos encontrados que concordaban??? si tu pregunta era esa... la respuesta es SI

Si lo haces de la forma como Vertex te sugirio si... por eso te decia que le proceso iba a ser un poco mas largo de esta manera, porque tienes que realizar muchas evaluaciones. Obviamente las 2 consultas se pueden colocar en 1 sola linea separadas por punto y coma cada una al final... pero me temo que el proceso aunque lo coloques en 1 sola linea, sera el mismito el resultado el motor debera realizar los 3 algoritmos para hacer eso que buscas....

Lo siento, yo no voy muy acorde a esa idea, entiendo que quieres ahorrar espacio.. pero yo me preocuparia mas porque las consultas sean rapidas ya que el espacio se puede reducir luego, pero una estructura inicial implementada en base a calculos de algoritmos y luego resultados... bueno eso con el tiempo (digase cuando tengas muchos datos mas de miles) comenzaran a alentarse y alentarse y alentarse... independientemente que uses hasta 64 indices constantes 

Por cierto cuando escribas hash te refieres al nombre del campo indice no al tipo de indice que este es verdad? porque hasta lo que se, Myisam no maneja ni soporta indices de tipo hash sino btree y rtree.

No es cierto Napk siempre entro al msn   quien eras   

disculpa he recreado un escenario como el tuyo;

mysql> DESCRIBE llegada;
+--------------+-------------+------+-----+---------+-------+
| FIELD        | TYPE        | NULL | KEY | DEFAULT | Extra |
+--------------+-------------+------+-----+---------+-------+
| cve_atencion | INT(11)     | NO   | PRI | 0       |       |
| nombres      | VARCHAR(20) | YES  |     | NULL    |       |
| fecha_recep  | DATE        | YES  |     | NULL    |       |
| cve_unidad   | tinyint(4)  | YES  | MUL | NULL    |       |
+--------------+-------------+------+-----+---------+-------+
4 ROWS IN SET (0.01 sec)
 
mysql> DESCRIBE cuaderno_anotaciones;
+-------------------+-------------+------+-----+---------+-------+
| FIELD             | TYPE        | NULL | KEY | DEFAULT | Extra |
+-------------------+-------------+------+-----+---------+-------+
| apellidos         | VARCHAR(20) | YES  |     | NULL    |       |
| cve_nota_atencion | INT(11)     | YES  | MUL | NULL    |       |
| cve_seccion       | INT(11)     | YES  | MUL | NULL    |       |
+-------------------+-------------+------+-----+---------+-------+
3 ROWS IN SET (0.01 sec)
 
 

Y ambas tienen miles de datos;

mysql> SELECT COUNT(*) FROM llegada;
+----------+
| COUNT(*) |
+----------+
|    40000 |
+----------+
1 ROW IN SET (0.04 sec)
 
mysql> SELECT COUNT(*) FROM cuaderno_anotaciones;
+----------+
| COUNT(*) |
+----------+
|    30000 |
+----------+
1 ROW IN SET (0.00 sec)
 
 

Una 40 mil otra 30 mil, he utilizado tu consulta y::::

mysql> SELECT COUNT(cve_atencion) FROM llegada a INNER JOIN cuaderno_anotaciones b ON a.cve_unidad = 1 AND a.cve_atencion = b.cve_nota_atencion AND b.cve_seccion = 3 AND MONTH(a.fecha_recep)=10 AND YEAR(a.fecha_recep)=2009;
+---------------------+
| COUNT(cve_atencion) |
+---------------------+
|               18000 |
+---------------------+
1 ROW IN SET (0.36 sec)
 
 

36 Segundos 18 mil registros concordaron (Y esto sin tener activado el buffer cache del motor que reduce luego de la primera consulta 260% del tiempo inicial  ) Y de acuerdo al optimizador interno de MySQL los indices estan correctos uno es constante y el otro se iguala con otro indice de la otra tabla.

No te molestaria indicarme cuantos valores te retornan a ti cuando haces esa consulta, y parte de los registros de tu tabla (aunque no sean reales) hazme un escenario de ejemplo aca de como son tus tablas y que valores tienen.

Bueno tienes un pequeno dilema.

CRC32 vs MD5 en cuestion de velocidad y desempeno es mejor porque al ser un convertidor mas pequeno, pues el calculo el motor lo interpreta mas rapido. Y como te expuse los valores en CRC32 son tratados como numeros enteros en cambio funciones como MD5, SHA1, etc. etc son tratados como datos caracteres alfanumericos hexadecimales    esto sin considerar que los calculos sobre numeros es mas rapido que los calculos sobre funciones criptograficas sin necesidad en tu caso que no vas a guardar una contraseña, ni una tarjeta de credito ni mucho menos para aplicar una funcion criptografica.


Vas a guardar imagenes dentro del motor???    recuerda que esto convertido en dato binario ocupa muchisimo espacio... lo cual alentaria sobremanera una busquedad que te retorne una imagen independientemente que utilizes hasta 20 indices primarios numericos.

Como te decia una funcion Matematica en tu caso es muchisimo mas recomendable que una funcion criptografica, no solo te ahorras velocidad sino tambien tamano en el disco. No existe lamentablemente hasta lo que me concierne una funcion matematica oficial en MySQL de 64bits. Pero, como siempre existen aplicaciones de terceros (Y a no ser que Vertex quisiera cooperar contigo y desarrollarte en C una funcion que funcione como un hash matematico de 64 y luego la implementas dentro de MySQL como una funcion UDF  ) De lo contrario, ya han habido usuarios que han creado funciones UDF para MySQL, como este amigo:

http://www.xaprb.com/blog/2008/03/09/a-very-fast-fnv-hash-function-for-mysql/

Compilar una funcion UDF dentro de un ya existente motor de MySQL no es complicado, si tanto te preocupa el desempeno y el tamano me temo que tendras que usar una funcion matematica de un tercero como la que te postee anteriormente, o usar CRC32 y sus limites o inclinarte por un hash criptografico pero de antemano conociendo sus inconvenientes para tu caso en especifico.