Ricardo Galli explica porque motivos es mejor guardar las direcciones ip de un usuario como enteros en vez de como strings y pone ejemplos de lo que le sucedió a Menéame cuando aplicó esta optimización

Pero lo hago sobre un segundo servidor, donde replicamos la BBDD en tiempo real (con la replicación del mysql) porque en el principal bloquea los accesos webs en cuanto la consulta es algo compleja y requiere muchos accesos (como en la de los ejemplos). Ahora que el servidor tiene el doble de memoria y con esta reducción de los índices, volveré a probar (aunque el servidor donde está replicado es idéntico y toma unos 5-9 segundos).

Tampoco me debí expresar bien cuando te daba la enhorabuena y te decía lo sangrante del asunto. Ese cambio era evidente que llegaría. Es el como ha llegado despues de un artículo, y me repito, en inglés. Simplemente, es que estoy hartito de esa marca de cultura hispana donde lo de fuera es mejor y lo de dentro se menosprecia.

En cuanto a la complejidad del sql. Hombre un “_int” que añades a las apariciones a “vote_ip” y escribir reescribir el like con un BETWEEN … AND. Pues no me parece que añada una complejidad a la sentencia, más bien añade caracteres a esta pero no complejidad. No se trata del espacio, se trata de la eficacia y la eficiencia que aporta una solución con respecto a la otra.

No sé si has leído lo que he dicho o me expreso mal, dije “sentencia sql”, esas que ejecuto manualmente cuando quiera averiguar algo. Y manualmente significa que no se hace con PHP sino directamente en sql del mysql, que me queda así:

select distinct user_login, user_email, vote_ip_int from votes, users where user_id=vote_user_id and vote_type in (’links’,'comments’) and vote_date > date_sub(now(), interval 90 day) and vote_ip_int between inet_aton(’62.x.y.0′) and inet_aton(’62.x.y.0′) + 255;

o

select distinct user_login, user_email, vote_ip_int from votes, users where user_id=vote_user_id and vote_type in (’links’,'comments’) and vote_date > date_sub(now(), interval 90 day) and vote_ip_int between inet_aton(’62.x.y.0′) and inet_aton(’62.x.y.255′);

versus la más simple:

select distinct user_login, user_email, vote_ip from votes, users where user_id=vote_user_id and vote_type in (’links’,'comments’) and vote_date > date_sub(now(), interval 90 day) and vote_ip like ‘62.x.y.%’;

Pero no entiendo a qué viene tanta manía, sí, lo repito, tenían razón, se ahorra mucho espacio. Por otro lado, lo curioso es que el que modifica el código, lo prueba y publica los números a favor de las tesis contrarias a la mía he sido yo, no tú, que también podrías haberlo explicado, hecho antes, y hasta enviado parches si estabas tan interesado en demostrar mi error de apreciación ¿no?.

192.168.69.0 = 3232253184

192.168.69.255 = 3232253439

hombre no parece excesivamente complicado un $globals[’user_ip_int’] BETWEEN 3232253184 AND 3232253439

y para costes es evidente que lo costoso es la solución anterior.

Lo de “enésima” significa que varios me lo habían dicho, en diversos comentarios y correos, y la verdad, ni me acordaba ni de qué había sido la discusión con RBA (aunque sí recordaba una discusión, y no tengo porqué no citarlo, hasta tiene contratado publicidad en el menéame… algunos creen que me muevo por “odios”, cuando puede ser simple estupidez mía :-P, el hecho que un lector lo haya recordado y haya puesto el enlace lo confirma, los lectores siempre saben más que el que escribe, y estoy de acuerdo ).

Por otro lado, sigo con lo misma idea que antes-

Es una putada usar ahora los enteros, además de los sql que solía usar para detectar “clones” ahora se han complicado bastante comparado al simple like “x.y.z.%” que usaba antes, y me putea que cualquier cosa que quiera hacer desde el PHP deba hacerlo con mucho cuidado del problema de signos. Tiene su coste también, no ha salido gratis, aunque al menos en este momento los beneficios fueron bastantes “importantes” como para no asumir los “costes”.

Creo que ya escribí antes sobre este tema, “there is no silver bullet”.

Hombre, podías haber puesto algún enlace. Para dar a RBA el reconocimiento que merece.

De resto, enhorabuena por el cambio. Lo único realmente doliente, es que tuviera que ser después de un artículo en inglés que te plantearás tal cambio. Simplemente porque meses antes ya te lo habían dicho.

1) No te preocupes de utilizar ip2long ni sprintf al inicio del script.
2) En el momento de hacer la consulta (ya sea INSERT o SELECT), utiliza las funciones nativas de MySQL inet_aton() e inet_ntoa(), que agilizarán algo el trámite y la CPU lo notará menos que si lo haces desde PHP. En Saca La Basura lo hemos hecho y, aunque ni de lejos tiene la carga que Meneame, se aprecia. Código SQL de ejemplo:

mysql> select inet_aton(’127.0.0.1′);
+————————+
| inet_aton(’127.0.0.1′) |
+————————+
| 2130706433 |
+————————+
1 row in set (0.00 sec)

mysql> select inet_ntoa(’2130706433′);
+————————-+
| inet_ntoa(’2130706433′) |
+————————-+
| 127.0.0.1 |
+————————-+
1 row in set (0.00 sec)

3) En algunas tablas, quizá puedas hacer uso de INSERT ON .. DUPLICATE KEY UPDATE

Disclaimer;

No tengo nada que ver con ningún rollo ni paranoia conocida hasta el momento o por conocer.

“Aunque ya me lo habían dicho, no dí demasiada importancia ya que prefería la “claridad” antes que ahorrar un poco de espacio.”

Tampoco me cuesta tanto admitir cuando estaba equivocado, o cuando los demás proponen soluciones mejores (y lo que no era un problema entonces, podría serlo ahora).