#77#61
0. No dudo de la potencia de la base de datos, es más me parece un logro Enhorabuena, pero no me refería a la base de datos
1. La comparación se realiza en PHP no en MySQL, no me he referido a MySQL en ningún momento ni al consumo total, me he referido al consumo de la evaluación de esa comparación.
2. MySQL no es PHP, por lo que es bueno en un sitio no tiene porqué serlo en el otro. Que venga bien utilizar un tipo de dato u otro para almacenar la información no implica que también venga bien en el lenguaje de programación. Una rápida búsqueda en Google me lanza algún resultado (ronaldbradford.com/blog/to-enum-or-not-to-enum-2006-01-22) por el que no es recomendable, por supuesto, seguro que encuentras los que lo recomiendan (y justifican la afirmación de que es el mejor en cuanto a eficiencia), pero dado que dicho tipo de dato no forma parte del SQL estándar, con eso me vale (fuera interoperabilidad); logicamente al ser propio... qué menos que sea eficiente y/o útil.
3. Escalar, en mi vocabulario (y en el de cualquiera que lo sepa) no es lo mismo que replicar Pero eso aquí no viene a cuento, porque la solución al consumo excesivo de CPU no está en meter más procesador y/o memoria a pesar de la mala costumbre, se puede llegar a un punto (que se lo pregunten a Google), en que el gasto es tal que hay que empezar a optimizar el código, algo que en ocasiones se puede hacer desde el principio.
4. (extra) Sigo afirmando lo dicho (que lo he hecho sin chulería alguna) mientras no se demuestre lo contrario, y mientras no se invente nada nuevo... no es lo mismo comparar un número que una cadena de caracteres (las razones que haya detrás de utilizar la cadena de texto me parecen estupendas, si viene bien usar ENUM, pues perfecto, pero yo no lo haría así por la razón esgrimida)
Por cierto, dado que se compara esa cadena de caracteres... no vendría mal usar una bonita constante, vamos, para el día en que se quiera cambiar el nombre utilizado por otro, y así no tener que hacer una búsqueda en todos los ficheros donde se pueda utilizar... (no, no he mirado más ficheros, se use en un único punto o varios, una clase, o en varias es recomendable seguir esta práctica de programación)
0. No dudo de la potencia de la base de datos, es más me parece un logro
1. La comparación se realiza en PHP no en MySQL, no me he referido a MySQL en ningún momento
2. MySQL no es PHP, por lo que es bueno en un sitio no tiene porqué serlo en el otro. Que venga bien utilizar un tipo de dato u otro para almacenar la información no implica que también venga bien en el lenguaje de programación. Una rápida búsqueda en Google me lanza algún resultado (ronaldbradford.com/blog/to-enum-or-not-to-enum-2006-01-22) por el que no es recomendable, por supuesto, seguro que encuentras los que lo recomiendan (y justifican la afirmación de que es el mejor en cuanto a eficiencia), pero dado que dicho tipo de dato no forma parte del SQL estándar, con eso me vale (fuera interoperabilidad); logicamente al ser propio... qué menos que sea eficiente y/o útil.
3. Escalar, en mi vocabulario (y en el de cualquiera que lo sepa) no es lo mismo que replicar
4. (extra) Sigo afirmando lo dicho (que lo he hecho sin chulería alguna) mientras no se demuestre lo contrario, y mientras no se invente nada nuevo... no es lo mismo comparar un número que una cadena de caracteres (las razones que haya detrás de utilizar la cadena de texto me parecen estupendas, si viene bien usar ENUM, pues perfecto, pero yo no lo haría así por la razón esgrimida)
Por cierto, dado que se compara esa cadena de caracteres... no vendría mal usar una bonita constante, vamos, para el día en que se quiera cambiar el nombre utilizado por otro, y así no tener que hacer una búsqueda en todos los ficheros donde se pueda utilizar... (no, no he mirado más ficheros, se use en un único punto o varios, una clase, o en varias es recomendable seguir esta práctica de programación)