¿Por qué es una mala idea usar MySQL para un sitio web de diccionarios?

No puedo decirte por qué es una mala idea. Puedo decirte un montón de razones por las que una base de datos relacional es una idea buena .

1. Recuerde que no todos consultan un diccionario para una definición. Más de las veces, se usa un diccionario para encontrar la ortografía correcta. Esto significa que no solo estás encontrando una aguja en un pajar , está buscando en el pajar para las agujas que son similares a la descrita por el usuario (si puedo usar un idioma).

   No solo estarás haciendo búsquedas de clave principal. Estarás haciendo búsquedas de palabras clave

2. Las palabras se pueden relacionar, ya sea en significado o ortografía ( leer, leer , red y reed )

   Cada vez que vea la palabra "relacionada" piense en "Base de datos relacional"

3. Si necesita velocidad, necesita un almacenamiento en caché en la parte superior de su base de datos relacional, no un modelo de datos relacionales roto

4. Una base de datos correctamente normalizada acelera las búsquedas y búsquedas de claves primarias, ya que simplemente hay menos bits para analizar.

5. Las personas que dicen que las bases de datos normalizadas son más lentas se refieren al 0.1% de los casos en que esto es cierto. En el otro 99.9% de los casos, no han en realidad trabajado con una base de datos realmente normalizada para ver el desempeño de primera mano, así que ignórelos. He trabajado con una base de datos normalizada. Quiéralo. No quiero volver. Y no soy un tipo de base de datos. Soy un chico de C # / JavaScript / HTML / Ruby.

6. Las palabras tienen un origen. De hecho, muchas palabras en el mismo idioma pueden tener el mismo origen, que es otra palabra en un idioma diferente. Por ejemplo, el curriculum vitae (lo que cargamos en los sitios web de los reclutadores para que podamos recibir incesantes llamadas telefónicas y correos electrónicos durante los próximos 7 años) es una palabra francesa.

7. Un diccionario también define qué tipo de palabra es (sustantivo, verbo, adjetivo, etc.). Esto no es solo una parte del texto: "nombre" también tiene un significado. Además, con una base de datos relacional puede decir cosas como "dame todos los nombres para el idioma inglés" y como una base de datos normalizada utilizará claves externas, y las claves externas tendrán (o deberían tener) índices, la búsqueda será muy fácil.

8. Piensa en cómo se pronuncian las palabras. Especialmente en inglés, muchas palabras tienen la misma pronunciación (vea mi ejemplo anterior con lectura y lectura, o lectura y rojo).

   La pronunciación de una palabra es, en sí misma, otra palabra. Una base de datos relacional le permitiría usar claves externas para cualquier pronunciación. Esa información no será duplicada en una base de datos relacional. Se duplica como un loco en una base de datos sin SQL.

9. Y ahora hablemos de versiones en plural y singular de las palabras. :) Piensa en "barco" y "barcos". O el hecho de que una palabra sea "singular" o "plural".

10. ¡Oh! Y ahora hablemos del tiempo pasado, del tiempo presente, del tiempo futuro y del participio presente (para ser sincero, no sé qué es el "participio presente"). Creo que tiene algo que ver con palabras que terminan en "ing" en inglés o algo así.

    Busque "ejecutar" y debería ver los otros tiempos: ejecutar, ejecutar, ejecutar

    De hecho, "tenso" es otra relación en sí misma.

11. El inglés no hace esto mucho, pero el género es otra cosa que define una palabra. Las lenguas como el español tienen sufijos que definen si el sujeto del sustantivo es masculino o femenino. Si necesita completar los espacios en blanco para una oración, el género es extremadamente importante en muchos idiomas.

    Como no siempre puede confiar en las convenciones del idioma para determinar el género (en español, las palabras que terminan en "o" son masculinas / masculinas, pero eso no es cierto para todas las palabras), necesita un valor de identificación: masculino o femenino. Esta es otra relación que una base de datos normalizada maneja con gracia incluso en millones de registros.

Con todas las reglas y relaciones torcidas entre palabras, e incluso diferentes idiomas, me resulta difícil imaginar este almacén de datos como un "almacén de documentos" como el que proporciona una solución sin SQL. Hay tantas y una gran variedad de relaciones entre las palabras y sus componentes que una base de datos relacional es la única solución razonable.

Si va con el almacén de valores clave (que le ofrece un modelo de programación más empobrecido) y resulta que necesita más estructura (en su caso, por ejemplo, agregar un tercer idioma), o necesita hacer más complejos En las consultas que involucran uniones, pasará un montón de tiempo reorganizando sus claves, desnormalizando sus datos y / o repasando todos los datos para encontrar lo que necesita.

Si comienza con una base de datos relacional, puede trabajar a través del diseño, el código y la prueba de su aplicación, concentrándose más en el modelo de datos naturales de su aplicación, en lugar de hacerlo en el formato clave-valor.

Una vez que la aplicación se establece, puede trabajar en el rendimiento, midiendo varias opciones. Hay bastantes trucos de rendimiento para realizar en SQL antes de tener que cambiar de tecnología. Habrás aprendido mucho sobre tu aplicación y estarás en una posición mucho mejor para decidir si la relación te está perjudicando y si el valor clave funcionará para tu modelo de datos.

Si resulta que el valor clave es exactamente lo que necesita su aplicación, puede cambiar sin haber perdido una inversión significativa en el modelo relacional, mientras que al revés posiblemente termine perdiendo el tiempo haciendo que el modelo valor-clave se haga realidad. Cosas que son triviales en el modelo relacional.

Considere la base de datos relacional como un acelerador para que su aplicación se diseñe, se escriba y se ponga en marcha, en función de los requisitos en constante cambio a medida que aprende más sobre su dominio y sus usuarios.

Cuando tengas millones de usuarios, es casi seguro que deberás refactorizar el diseño de todos modos, incluso para empezar con el valor clave.

Para una base de datos tan pequeña, es probable que no haga mucha diferencia en el rendimiento. Un RDBMS estándar no es una idea terrible aquí porque, presumiblemente, debería haber muchas más lecturas que escrituras de una entrada determinada. El rendimiento no parece ser un factor principal para esto. El almacenamiento en caché en la capa de aplicación también mitiga tales preocupaciones.

La otra consideración es la replicación y la resiliencia. Las bases de datos relacionales tienden a diseñarse en torno a una sola instancia. Debería leer el teorema de CAP y considerar qué es lo más importante para usted.

Estas bases de datos NoSQL siempre suenan como una buena idea desde el principio, pero tendrá la garantía de tener problemas cuando comience a lidiar con casos de borde (por ejemplo, cuando las palabras clave deben buscarse por su valor (o parte de)) instancia.

Sería una opción más segura ir con una base de datos relacional desde el principio y luego desnormalizarse más tarde. MySQL es increíble para este tipo de propósito (bases de datos relacionales simples con búsqueda basada en texto), no hay demasiados casos de uso en los que se encuentre luchando con este tipo de datos. Solo asegúrese de tener sus índices configurados correctamente y encontrará que funcionará a un nivel comparable (o mejor al hacer una búsqueda de texto) a una base de datos NoSQL, y le dará la flexibilidad para modificar la lógica de su aplicación sin estar unido a una estructura de datos concreta.

A medida que encuentre el uso más común de sus datos (y si alguna vez descubre que no cumple con sus necesidades de rendimiento), puede proceder a la normalización de los datos mediante la salida a un formato establecido que se puede cargar en (y recuperado de) un esquema NoSQL.