Soluciones extrañas (I)
He creado un newsletter en mi página de gramática alemana. La idea es que los usuarios que prefieren un e-mail o que no están familiarizados con otros medios (RSS, Twitter, etc.) puedan suscribirse para recibir información en sus correos. La cuestión es ¿qué información?
No tardé en darme cuenta que el número de secciones podía ir creciendo con el tiempo. Cada nueva sección susceptible de enviar algún tipo de resumen de actividad por mail (noticias, novedades, comentarios, participaciones, …) requeriría un nuevo campo lógico en la tabla (que al final acaban siendo Enum o Integer, todo un desperdicio).
Puede parecer una tontería pero poner un nuevo campo me da mucha pereza, porque al tener el proyecto en un hosting compartido, crear un campo requiere hacer un php únicamente para que lance esa consulta (en el caso más rápido) o hacer login en el panel general, bucar la opción de bases de datos, lanzar el phpMyAdmin, localizar la tabla, pulsar en ‘añadir campo’, rellenar sus características y finalmente crearlo … en resumen ¡2 tediosos minutos! :o)
Total, que como últimamente (ya os contaré otra) me da por probar soluciones extrañas (ni originales, ni extremas, ni retros, ni nada más que extrañas, porque si no puedo experimentar en mis propios proyectos dónde lo hago) pues se me ocurrió hacer un único campo numérico de 32 bits (para no quedarme corto) donde cada bit significará si estás o no estás suscrito a una posible sección. A fin de cuentas, no en vano cuenta con operadores a nivel de bit. De acuerdo en que no es así con MySQL. El día que quiera hacer algo tipo «actualiza todos los que estén en la lista Noticias» (es decir, que su primer bit esté a 1) será la hostia porque los usuarios pueden estar suscritos solo a esa sección o en esa y en cualquiera de las otras, lo cual supone que habiendo 4 posibles listas, ya tenemos 7 posibilidades que tienen el bit de noticias activado y los demás en cualquier estado posible. Esto lo comento para no parecer un atolondrado inconsciente. Pero eso es porque lo imaginais como un «WHERE Suscrito IN (1, 3, 5, 7, 9, 11, 13)» y no como un bucle en PHP que recorre todos los registros y para aquellos que cumplen la condición «FieldValue && nlNoticias» se hace una acción.
Entonces ¿he cambiado la posibilidad de necesitar 30 segundos haciendo un php que corra un alter por cada campo que quiera añadir en el futuro, por la posibilidad de necesitar en varios minutos en hacer un php que haga un bucle y corra alguna consulta o comando cuando se cumle una condición? SI, pero es que me apetecía mucho.