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.
-
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
-
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"
-
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
-
Um banco de dados corretamente normalizado acelera pesquisas e pesquisas de chave primária, pois há apenas menos bits para filtrar.
-
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.
-
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.
-
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.
-
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.
-
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".
-
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.
-
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.