Ok
meagle, disculpas, había mal interpretado tu concepto de
generado de forma estática (SIC). Igual, ahora que entendí a que te referías, sigo discrepando. Pero tal vez sea una cuestión de gustos personales
Cita:
Iniciado por popobcn Estamos hablando de una base de datos MUY sencilla, que no requiere del desarrollo de consultas COMPLEJAS en ninguna plataforma, ya sea SQL o MySQL, ya que tan sólo se ha de efectuar una búsqueda con una declaración: por ID o por NOMBRE DE ARTISTA o por NOMBRE DE LA LETRA... (Complicandolo, por artista + letra => WHERE artista = 'The Doors' AND letra = 'Raiders on the storm' por ejemplo - y pienso que esto funciona con cualquier motor SQL xD)
...
...
Las consultas a realizar son muy simples, no para ti... sino para cualquier servidor. Por lo que la carga de la información será practicamente inmediata con cualquier motor SQL - en serio, no tienes tablas relacionas, ni necesidad de crear vistas ni efectuar sub-querys complejas que puedan ocupar 20 ó 40 líneas de código para mostrar una canción...
Jeje, es cierto. Lo mismo que en el caso que comenté antes: Lo que debería haber sido un simple join de dos tablas (secciones y noticias) derivó (por pereza... por reutilizar absurdamente un query más complejo que si necesitaba en el back-end) en ese mismo join más unos cuantos counts usando sub-querys y así obtener innecesariamente la cantidad (eso, sólo el número) de documentos adjuntos, etiquetas e imágenes de cada noticia. Totalmente al pedo, porque esa información no la estaba usando
(bueno, en realdiad si... sólo el número de imágenes para, si era mayor a cero, lanzar una query y obtenerlas. Luego de sacar el count de imágenes del query principal, consulto en absolutamente todas las noticias si tiene imágenes que mostrar.. en fin.. más accesos innecesarios a la base de datos pero problema de rendimiento resuelto)