Por que usar o MySQL para um site de dicionário é uma má ideia?

Eu não posso te dizer porque é uma má ideia. Eu posso lhe dizer um monte de razões pelas quais um banco de dados relacional é uma boa ideia.

1. Lembre-se de que nem todos consultam um dicionário para uma definição. Mais vezes do que não, um dicionário é usado para encontrar a grafia correta. Isso significa que você não está apenas encontrando uma agulha em um palheiro , você está procurando no palheiro por agulhas similares à descrita pelo usuário (se eu puder usar uma expressão idiomática).

   Você não estará apenas fazendo pesquisas de chave primária. Você estará fazendo pesquisas de palavras-chave

2. As palavras podem ser relacionadas, seja em sentido ou ortografia ( ler, ler , red e reed )

   Sempre que você vir a palavra "relacionado", pense em "Banco de dados relacional"

3. Se você precisar de velocidade, precisará de armazenamento em cache no topo do seu banco de dados relacional, e não em um modelo de dados relacional quebrado

4. Um banco de dados corretamente normalizado acelera pesquisas e pesquisas de chave primária, pois há apenas menos bits para filtrar.

5. As pessoas que dizem que os bancos de dados normalizados são mais lentos referem-se a 0,1% dos casos em que isso é verdade. Nos outros 99,9% dos casos eles não trabalharam com um banco de dados realmente normalizado para ver o desempenho em primeira mão, então ignore-os. Eu trabalhei com um banco de dados normalizado. Adoro. Não quero voltar. E eu não sou um cara de banco de dados. Sou um cara de C # / JavaScript / HTML / Ruby.

6. As palavras têm origem. De fato, muitas palavras na mesma língua podem ter a mesma origem, que é outra palavra em um idioma diferente. Por exemplo, o currículo (a coisa que enviamos para sites de recrutadores para que possamos receber telefonemas e e-mails incessantes pelos próximos 7 anos) é uma palavra em francês.

7. Um dicionário também define que tipo de palavra é (substantivo, verbo, adjetivo ect). Este não é apenas um pedaço de texto: "substantivo" também tem significado. Além disso, com um banco de dados relacional, é possível dizer coisas como "forneça todos os substantivos para o idioma inglês" e, como um banco de dados normalizado utilizará chaves estrangeiras e chaves estrangeiras (ou deveria ter) índices, a pesquisa será instantânea.

8. Pense em como as palavras são pronunciadas. Em inglês, especialmente, muitas palavras têm a mesma pronúncia (veja meu exemplo acima com read e reed, ou read e red).

   A pronúncia de uma palavra é, em si, outra palavra. Um banco de dados relacional permitiria que você usasse chaves estrangeiras para quaisquer pronúncias. Essa informação não será duplicada em um banco de dados relacional. Ele é duplicado como um louco em um banco de dados não-SQL.

9. E agora vamos falar sobre as versões plural e singular das palavras. :) Pense em "barco" e "barcos". Ou o próprio fato de que uma palavra é "singular" ou "plural".

10. Oh! E agora vamos falar sobre o pretérito, o presente, o futuro e o presente particípio (para ser honesto, não sei qual é a porcaria do "particípio presente". Acho que tem algo a ver com palavras que terminam em "ing" em inglês ou algo assim.

    Procure "executar" e verá os outros tempos: executar, executar, executar

    Na verdade, "tenso" é outro relacionamento em si.

11. O inglês não faz muito isso, mas o gênero é outra coisa que define uma palavra. Línguas como espanhol têm sufixos para definir se o sujeito do substantivo é masculino ou feminino. Se você precisar preencher os espaços em branco para uma frase, o gênero é extremamente importante em muitos idiomas.

    Como nem sempre é possível confiar em convenções de linguagem para determinar o sexo (em espanhol, palavras que terminam em "o" são masculinas / masculinas, mas isso não é verdadeiro para todas as palavras), você precisa de um valor de identificação: Masculino ou Feminino. Esse é outro relacionamento que um banco de dados normalizado manipula normalmente até mesmo em milhões de registros.

Com todas as regras distorcidas e relações entre palavras e até idiomas diferentes, é difícil imaginar esse armazenamento de dados como uma "loja de documentos" como uma solução sem SQL fornece. Há tantas e tão variadas relações entre palavras e seus componentes que um banco de dados relacional é a única solução sensata.

Se você for com o armazenamento de valor-chave (que oferece um modelo de programação mais empobrecido) e você precisar de mais estrutura (no seu caso, digamos, adicionar um terceiro idioma), ou você precisa fazer mais consultas envolvendo junções, você passará um bom tempo reorganizando suas chaves, desnormalizando seus dados e / ou retornando todos os dados para localizar o que precisa.

Se você começar com um banco de dados relacional, poderá trabalhar com o código e o design do aplicativo, concentrando-se mais no modelo de dados natural do aplicativo, em vez de concentrá-lo no formulário de valor-chave.

Quando o aplicativo estiver pronto, você poderá trabalhar no desempenho, medindo várias opções. Existem alguns truques de desempenho para fazer no SQL antes de precisar alternar tecnologias. Você terá aprendido muito sobre seu aplicativo e estará em uma posição muito melhor para decidir se o relacionamento está prejudicando você e se o valor-chave funcionará para o seu modelo de dados.

Se esse valor-chave é exatamente o que seu aplicativo precisa, você pode alternar sem ter perdido investimentos significativos no modelo relacional, enquanto o inverso pode acabar perdendo tempo fazendo com que o modelo de valor-chave coisas que são triviais no modelo relacional.

Considere o banco de dados relacional como um acelerador para que seu aplicativo seja projetado, criado e esteja em execução, em face dos requisitos em constante mudança, à medida que você aprende mais sobre seu domínio e seus usuários.

Quando você tem milhões de usuários, é quase certo que você precisará refatorar o design, mesmo que você tenha escolhido o valor-chave para começar.

Para um banco de dados tão pequeno, provavelmente não fará muita diferença no desempenho. Um RDBMS padrão não é uma ideia terrível aqui porque, presumivelmente, deveria haver muito mais leituras do que gravações de uma determinada entrada. O desempenho não parece ser um driver primário para isso. O cache na camada de aplicativo também atenua essas preocupações.

A outra consideração é replicação e resiliência. Bancos de dados relacionais tendem a ser projetados em torno de uma única instância. Você deve ler o teorema CAP e considerar o que é mais importante para você.

Esses bancos de dados NoSQL sempre soam como uma boa ideia desde o início, mas você terá problemas quando começar a lidar com casos extremos (por exemplo, onde palavras-chave devem ser pesquisadas por seu valor (ou parte de) exemplo.

Seria uma opção mais segura ir com um banco de dados relacional no início e depois desnormalizar depois. O MySQL é incrível para esse tipo de propósito (bancos de dados relacionais simples com pesquisa baseada em texto), não há muitos casos de uso em que você encontrará dificuldades com esse tipo de dados. Apenas certifique-se de ter seus índices configurados corretamente e você perceberá que ele funcionará em um nível comparável (ou melhor ao fazer uma pesquisa de texto) a um banco de dados NoSQL e lhe dará a flexibilidade de modificar a lógica do seu aplicativo sem ser vinculado a uma estrutura de dados concreta.

À medida que você encontra o uso mais comum de seus dados (e se alguma vez descobrir que não está atendendo às suas necessidades de desempenho), pode proceder à desnormalização dos dados, enviando para um formato definido que possa ser carregado (e recuperado de) um esquema NoSQL.