¿Almacena cuerpos de publicaciones en bases de datos o archivos?

Question

Estoy aprendiendo programación centrada en la web escribiéndome un blog, usando PHP con un back-end de base de datos MySQL. Esto debería reemplazar mi blog actual (basado en Drupal).

He decidido que una post debe contener algunos datos: id, userID, title, content, time-posted. Eso hace un buen esquema para una tabla de base de datos. Sin embargo, tengo problemas para decidir cómo quiero organizar el almacenamiento de content.

Yo tampoco podía:

1. utilizar un sistema basado en archivos. La tabla de la base de datos content sería una URL para un archivo ubicado localmente, que luego leería, formataría y mostraría.
2. Almacenar todo el contenido de la publicación en content, es decir, ponerlo en la base de datos.

Si fui con (1), buscar los contenidos de las publicaciones sería un poco problemático - estaría limitado a la búsqueda de metadatos, o tendría que leer el contenido de cada archivo al buscar (aunque no sé cuánto de un problema que sería - grep -ir "string" . no es demasiado lento ...). Sin embargo, las imágenes (si las hay) serían referenciadas por una URL, por lo que hacer referencia a content sería al menos una metodología internamente consistente, y sería fácilmente capaz de reutilizar el contenido, ya que los archivos de texto son ridículamente fáciles de usar, en comparación con un archivo de base de datos SQL.

Sin embargo, yendo con (2), podría usar un longtext. El content necesitaría desinfectarse antes de intentar ponerlo en la tupla, y estoy limitado por el tamaño (aunque es poco probable que escriba una publicación de blog de 4 GB;). La búsqueda sería fácil.

No veo (actualmente) qué camino sería (a) más fácil de implementar, (b) más fácil de vivir.

¿Qué camino debo seguir/cómo se hace normalmente? Cualquier otro pros/contra para (1) o (2) sería apreciado.

Answer 1

Para la 'generación actual', implementar una base de datos es su apuesta más segura. Como mencionaste, es bastante estándar, y delineaste todas las cosas divertidas. La mayoría de las instancias SQL tienen una búsqueda FULLTEXT bastante poderosa (o equivalente). Probablemente tendrá la misma arquitectura para escribir entre las dos que ha descrito, especialmente si quiere que una tenga la paridad de características de la otra.

La tecnología prometedora es una tienda clave/valor, comúnmente conocida como NoSQL. Con esto, puede almacenar su contenido y metadatos en documentos individuales separados, pero de una manera estructurada que hace que la búsqueda y la recuperación sean bastante rápidas. Algunos motores NoSQL comunes son mongo, CouchDB y redis (entre otros).

En última instancia, esto se reduce a las preferencias personales, junto con algunas consideraciones de casos de uso. Realmente no describiste lo que es importante para ti en cuanto a las comodidades y tu aplicación. Cualquiera de estos sería perfecto para un blog personal o de desarrollo. Crear una plataforma completa con múltiples colaboradores es una conversación diferente.

Answer 2

Hace 13 años probé tu opción 1 (tener archivos externos para contenido de texto) - no con un blog, pero con un CMS.Y terminé metiéndolo todo de nuevo en la base de datos para un manejo más fácil. Es mucho más fácil tener reemplazos globales en la base de datos que en el nivel de archivo de texto. Con una gran cantidad de publicaciones, tiene problemas con los tamaños de directorios y la velocidad de acceso, o tiene que administrar esquemas de subdirectorios, etc., etc. Se adhieren a la base de datos única: . Hay algunas herramientas para facilitarle la vida con archivos de texto -en las funciones de mysql, pero con un cliente de línea de comandos como mysql y mysqldump puede extraer fácilmente cualquier texto al nivel del sistema de archivos, trabajar con herramientas estándar y volver a cargarlos en la base de datos. Lo que realmente le falta a mysql es el soporte integrado para la búsqueda/reemplazo de expresiones regulares, pero incluso para eso encontrará un parche si está dispuesto a recompilar mysql.