辞書のウェブサイトにMySQLを使用することが悪い考えであるのはなぜですか？
辞書のエントリ（通常は単一の単語）とその意味を別の言語で格納するデータベースを設計および設定する予定です。したがって、たとえば、テーブル用語集にはentryおよびdefinitionおよび各テーブルレコードには、Tagに格納されたレコードのidへの参照があります（各エントリにはタグまたはカテゴリ）。
私のデータは構造を持っているので、SQLデータベース（MySQLなど）を使用することは悪い考えではないと思いました。しかし、人々はMongoDBの方がパフォーマンスがはるかに優れていると言っています。
クライアント側では、アプリケーションは、バックエンドによって提供されるREST APIを使用するオートコンプリートを備えた検索ボックスを提供できる必要があります。このようなシナリオでMySQLを使用しても安全ですか？このために他のソリューションのMongoDBまたはElasticSearchを使用していますか？何十万ものレコードがこの方法で格納およびアクセスされると想定されています。
なぜそれが悪い考えなのかは言えません。リレーショナルデータベースが良いアイデアである理由はたくさんあります。
誰もが定義について辞書を調べるわけではないことを覚えておいてください。多くの場合、正しいスペルを見つけるために辞書が使用されます。これは、単に 干し草の山で針を見つける ではないことを意味します。干し草の山を検索して、ユーザーが説明した針に似た針を探します（私がイディオムを使用している場合）。
主キーの検索を行うだけではありません。キーワード検索を行います
単語は、意味またはスペルのいずれかで関連付けることができます（ read、read 、 red and reed ）
「関連する」という言葉を見るときはいつでも、「リレーショナルデータベース」を考える
速度が必要な場合は、壊れたリレーショナルデータモデルではなく、リレーショナルデータベースの上にキャッシュする必要があります。
正しく正規化されたデータベースは、単純にふるいにかけるビットが少ないため、主キーの検索と検索を高速化します。
正規化されたデータベースが遅いと言う人々は、これが真実であるケースの0.1％に言及しています。その他の99.9％のケースでは、実際に実際にを使用していないため、実際に正規化されたデータベースを使用してパフォーマンスを直接確認しているため、無視してください。私は正規化されたデータベースを使用してきました。大好きです。戻りたくない。そして、私はデータベースの男ではありません。私はC＃/ JavaScript/HTML/Rubyの人です。
言葉には起源があります。実際、同じ言語の多くの単語は同じ起源を持つことができます。これは、異なる言語の別の単語です。たとえば、履歴書（採用担当者のWebサイトにアップロードして、今後7年間電話や電子メールを絶え間なく受け取れるようにするもの）はフランス語です。
辞書は、それがどのような種類の単語であるかも定義します（名詞、動詞、形容詞など）。これは単なるテキストではありません。「名詞」も意味があります。さらに、リレーショナルデータベースを使用すると、「英語のすべての名詞をくれ」などと言うことができます。正規化されたデータベースは外部キーを利用し、外部キーにはインデックスがある（または持つ必要がある）ため、ルックアップは簡単です。
単語の発音を考えてみてください。特に英語では、多くの単語が同じ発音を持っています（上記のリードとリード、またはリードとレッドの例を参照）。
単語の発音は、それ自体が別の単語です。リレーショナルデータベースでは、発音に外部キーを使用できます。その情報はリレーショナルデータベースで複製されません。これは、非SQLデータベースでクレイジーに複製されます。
そして今、単語の複数形と単数形について話しましょう。 :)「ボート」と「ボート」を考えてください。または、言葉が「単数」または「複数」であるという事実。
ああ！そしてnow過去形、現在形、未来形、現在分詞について話しましょう（正直なところ、私はがらくた「現在分詞」が何であるかわかりません」です。英語で「ing」で終わる単語と関係があると思います）。
「run」を検索すると、他の時制が表示されます：実行、実行、実行
実際、「緊張」はそれ自体別の関係です。
英語はそれほど多くはありませんが、性別は単語を定義するもう1つの要素です。スペイン語のような言語には、名詞の主語が男性か女性かを定義するサフィックスがあります。文の空白を埋める必要がある場合、多くの言語では性別が非常に重要です。
性別を決定するために常に言語規則に依存することはできないため（スペイン語では、「o」で終わる単語は男性/男性ですが、すべての単語に当てはまるわけではありません）、識別値として男性または女性が必要です。これは、正規化されたデータベースが数百万のレコードでも正常に処理するもう1つの関係です。
すべてのねじれたルールと単語間の関係、さらには異なる言語であっても、このデータストアを、SQLなしのソリューションが提供するような「ドキュメントストア」として想像するのは困難です。単語とその構成要素の間には非常に多くの種類の関係があり、リレーショナルデータベースが唯一の賢明なソリューションです。
Key-Valueストア（これは、より貧弱なプログラミングモデルを提供します）を使用していて、さらに構造が必要な場合（たとえば、第3言語を追加する）、または結合を含むより複雑なクエリを実行する必要がある場合、キーを再編成したり、データを非正規化したり、すべてのデータをループしたりして、必要なものを見つけるのに多くの時間を費やします。
リレーショナルデータベースから始める場合は、アプリケーションの設計、コードを検討し、Key-Valueフォームに足を踏み入れるのではなく、アプリケーションの自然なデータモデルに集中して試すことができます。
アプリケーションが落ち着いたら、さまざまなオプションを測定して、パフォーマンスに取り組むことができます。テクノロジを切り替える必要がある前に、SQLで実行するパフォーマンストリックがかなりあります。アプリケーションについて多くのことを学んだので、リレーショナルが害を及ぼすかどうか、およびキー値がデータモデルで機能するかどうかを判断するのにはるかに有利な立場になります。
Key-Valueがアプリケーションに必要なものであることが判明した場合は、リレーショナルモデルへの多大な投資を無駄にせずに切り替えることができますが、逆に、Key-Valueモデルが次のようなことをすることに時間を浪費する可能性があります。関係モデルでは取るに足らない。
リレーショナルデータベースは、ドメインとユーザーについてさらに学ぶときに変化する要件に直面して、アプリケーションを設計、作成、実行するためのアクセラレータとして検討してください。
何百万人ものユーザーがいる場合は、最初にKey-Valueを選択した場合でも、とにかくデザインをリファクタリングする必要があります。
これほど小さいデータベースの場合、おそらくパフォーマンスに大きな違いはありません。標準のRDBMSはひどい考えではありません。おそらく、特定のエントリの書き込みよりも読み取りの方がはるかに多いはずです。パフォーマンスはこれの主な推進力ではないようです。アプリケーション層でのキャッシングもこのような懸念を軽減します。
もう1つの考慮事項は、レプリケーションと復元力です。リレーショナルデータベースは、単一のインスタンスを中心に設計される傾向があります。 CAP定理 をよく読み、最も重要なことを検討してください。
これらのNoSQLデータベースは、最初は常に良い考えのように聞こえますが、エッジのケース（たとえば、キーワードが値（またはその一部）で検索される必要がある場合など）の処理を開始すると、問題が発生することが保証されます。
最初はリレーショナルデータベースを使用し、後で非正規化する方が安全なオプションです。 MySQLはこの種の目的（テキストベースの検索を使用した単純なリレーショナルデータベース）に最適です。この種のデータに苦労するユースケースはそれほど多くありません。インデックスが正しく設定されていることを確認してください。インデックスがNoSQLデータベースに匹敵するレベル（またはテキスト検索を実行する場合）で実行され、アプリケーションロジックを変更せずに柔軟に変更できることがわかります。具体的なデータ構造にバインドされています。
データの最も一般的な使用法を見つけた場合（そして、パフォーマンスのニーズを満たしていない場合）、次に、ロード（および検索）できるセット形式に出力することにより、データを非正規化することができます。 NoSQLスキーマ。