私のチームは、外部キー関係を持つリレーショナルデータベースエンティティが怖いので、理由がわかりません

私は比較的大学を卒業していないので、リレーショナルデータベースに関する私の知識のほとんどは、BCNFまたは3NFにないものはすべてわいせつである私のデータベースコースからのものです。確かにそれは極端なことの一端ですが、仕事中の私のチームは本当にそれを完全に反対側に持っているようです。

マイクロサービスdbスキーマでは、エンティティが複数のテーブルを持つことはめったにありません。通常、別のテーブルに正規化するものはすべてjson列に格納されます。このjsonのプロパティの1つをクエリする必要があることが後で発見された場合、新しい列が追加され、データは両方の場所（はい、同じテーブルの2つの異なる列）に保存されます。

多くの場合、これらのjson列には間違いなく利点があります。そのデータを照会する必要がなく、そのデータに一方的な変更を加える必要がない場合（これは明らかに予測できないことです）、それは悪い考えではありません。さらに、当社のサービスの多くは、サーバーを認識しないか、必要なディスク容量のわいせつなマシンでホストされているため、データの重複は大きな問題ではありません。（私が一般的に哲学から避けたいことですが）

現在、所有する一連の条件に基づいてルールに一致するサービスを構築し、ルールが真（たとえば、すべての条件が真）の場合にそれらのルールに関連付けられた一連のアクションを実行します。このサービスを最も迅速に構築している私のサブチームは、スキーマ内のルールから離れてアクションと条件を正規化することには大きなメリットがあると考えています。明らかに、これらのテーブルは、ルールIDとの外部キー関係を維持します。私たちの観点からは、条件でのデータの重複を避けることができ、一度だけ評価されることを保証できます。また、必要なときに必要な条件やルールを見つけやすく、すべてのルールを引き出してメモリ内で検索する必要がありません。

今日、私たちの主任技術者の一人と話して、彼は私をこのスキーマから遠ざけようとしました。私たちが実際にそれを必要としないとあらゆる方法で議論しようとすると、将来的にパフォーマンスの問題が発生し、所有する古いモノリスを参照します。彼は、私たちがやっていることを「古い方法」と呼び、jsonを含むフラットテーブルを「新しい方法」と呼びました。彼は、私が原子性を望む場所ではそれを必要とせず、クエリの代わりにメモリ内でより多くのことをすべきだと主張した。これは、現在当社のサービスの多くが従っている設計原則です。データの量が大幅に増加することは予想していませんが、これによりクエリを高速に保つことができます。予想されるのは、ルールの評価とアクションの実行に多くの時間を費やすことです。

非リレーショナルデータベースが近年人気を博していることは理解していますが、外部キー関係のパフォーマンスへの影響に関する情報を積極的に検索しても、彼の主張を裏付ける情報は多くありません。問題を引き起こす可能性のある大規模なトランザクションを導入する傾向があると思いますが、それは外部キー自体とは無関係の問題のようです。

これは私の素朴ですか？または、これは本当に私と私のサブチームに欠けているものがありますか？解決策を必ずしも探しているわけではないので、問題に関する詳細な情報を明示的に提供していません。それが私たちの大規模なチームで一般的な傾向であることを考えると、彼らがこれで何かに取り組んでいるかどうかは本当に興味があります。

チームの出身地を理解するためのキーワードは、「マイクロサービス」です。特に次の情報については、その概念を最初に読む価値があります。

• データはどのように保存する必要がありますか？
• 設計原則？
• どのようにスケーリングするように設計されていますか？

比較的新しい方法（およびソフトウェアアーキテクチャに関しては5〜10年は比較的新しい）と同様に、理想と現実は少し異なることがわかります。

理想の1つは、すべてのマイクロサービスに独自のデータストアを持たせることです。 注：データベースではなく、データストアと言いました。通常のデータベースではなく、単に検索エンジン、BLOBストレージ、または単純なキャッシュが必要な場合があります。誰と話すかに応じて、その理想は、マイクロサービスインスタンスごとにデータストアに行くことさえあります！

要するに、インターネット規模に移行することについて話しているとき、ACID（原子性、一貫性、分離、および耐久性）トランザクションの安全性と親しみやすさは、1つのデータベースに数百万人のユーザーがいる場合、スケーリングしません。NoSQLの出現により、パラダイムはBASE（基本的に利用可能、ソフト状態、最終的な整合性）に向かってよりシフトしています。（参考）

データの管理方法のPHを変更すると、次のような影響があります。

• データベースがあなたのために世話をするために使用したものは、今コードで管理する必要があります
• サーバーに「無限」のリソースを追加するよりも、問題に対してより多くのマイクロサービスインスタンスをスローすることにより、スケーリングが容易になります。
• 複雑さが増す代わりに信頼性が向上します

あなたのチームの詳細や、彼らがどの程度の規模でソリューションを取得するつもりなのかについてはお答えできませんが、通常は、すべてまたは何も解決する必要はありません。ここに座って、チームが正しい選択をしているかどうかを判断するつもりはありません。少なくともどこから来たのかを理解できるように、コンテキストを提供しています。

このプロジェクトの主任エンジニアではないので、このプロジェクトの彼の指示に従う必要があります。

トレードオフを理解できるように、システムの独自の設計を行い、システムをプロトタイプ化することをお勧めします。あなた自身の教育のためにこれを行い、あなたが実際の例を示すことができる場合にのみ、職場でそれを言及してください。

私の経験では、制約によりデータベースのパフォーマンスが低下するという主張がありました。はい、そうです、これらの制約を確認する必要があります。ただし、データベースに一貫性がない場合、これははるかに大きな問題であり、これによりSQLおよびより多くのコードを記述して補正するため、多くの場合、システムの複雑さが増し、速度が低下します。

3nfを適切に実行すると、保存される冗長データが少なくなるため、より多くのデータベースをキャッシュできるため、データベースが高速になります。ただし、現在のジョブでは、正規化されたデータベースと正規化されていないデータベースのパフォーマンスの違いを実際に確認するのに十分なデータセットがない場合があります。

彼らは、参照整合性そのものではなく、以前あった同じ「トラベシー」を再作成することを恐れていると思います。

彼は、私が原子性を望む場所ではそれを必要としないと主張した...

アトミック性が必要であるという堅実なケース（別名、非機能要件）を作成できる場合、それを提供することから抜け出すために、優れた堅実な反論が必要になります。

...クエリの代わりに、メモリ内でより多くのことを行う必要があります。これは設計原則です...データの量が大幅に増えるとは考えていません...

あなたが正しいことを望みましょう。パフォーマンスを維持するためにデータが「十分に小さい」ままであることを信頼することはリスクが高いことをお勧めします。

また、これらの規則の変更率はどのくらいですか？重複が多いほど、同じものを複数の場所で更新するのに無駄な時間（お金）がかかります。

RDBMSの背後にある重要な概念は、40年以上も前のものです。当時のストレージは非常に高価であり、あらゆる種類の冗長性が嫌われていました。RDBMSの背後にある概念はまだ健全ですが、（結合を減らすための）パフォーマンスの非正規化の考え方は、ここ数十年で一般的に受け入れられています。

したがって、特定のサイズのRDBMSの場合、通常、パフォーマンスのための論理設計（冗長性なし）と物理設計（冗長性あり）があります。

ストレージが安価で、プロセッサがかつてないほど高速になっている今日、これらの設計圧力のいくつかはそれほど重要ではありません。最終的には、冗長性と孤児の記録を気にするかどうかについての判断の呼び出しです。銀行などの一部の業界では、データの正確性が不可欠であるため、RDBMSからどのように移行するかを把握することは困難です。他の業界では、新しいプレーヤーが常に市場に参入しているため、選択肢は無数にあります。

RDBMSがもたらす制限にチームが不快であるかどうかについて-誰が知っていますか？確かに私が見るジュニア開発者には、前世代の開発者が行ったRDBMSの知識はありませんが、これはおそらく開発者の技術とデータベースプラットフォームの急増に関係しています。

開発者が学べる技術に終わりはなく、あなたのキャリアにふさわしいパントを作るのは難しいかもしれません。確かに、開発者がすべての取引のジャックであった時代は過ぎ去りました-学べることは多すぎます。

しかし-手元の質問に。自分の承認では、データ量の増加は期待できず、システムのパフォーマンスは良好です。あなたが知覚できる利益なしで物事をリエンジニアリングするというアイデアを売ることは、あなたにとってかなりのストレッチでしょう。おそらく、RDBMSアプローチがメリットを享受するという概念実証を行うことができれば、それは別の話になるでしょう。

使用しているデータベースによって異なります。

従来のRDBMSでは、その通りです。データの複製は憎悪です。列とそのjsonの等価性は、強制するものが何もないため、必然的に同期から外れます。外部キーのサポートはよく知られており、関係を説明し、実施するのに非常に役立ちます。そして、原子性は、データを使用してほとんど何でもするために不可欠です。

nosqlのようなセットアップでは、それほど明確ではありません。強固な関係はないため、関係の実施はそれほど重要ではなくなります。列インデックスを持つそのようなjsonコンテンツは、これらのシステムではより一般的です。なぜなら、リレーションシップがないため、同期が取れなくなる可能性が低いからです。そして、原子性は単一のテーブルに制限されます。それがnosqlの仕組みだからです。

どちらが良いかは、実際に何をしているか、実際に何が必要かによって異なります。

しかし、同僚が貨物カルトにいるように聞こえます。彼らは古い悪いものに噛まれたので、今は新しい光沢のあるものにする必要があります。数年のうちに、新しい光沢のあるものに噛まれると、SQLとnoSQLがトレードオフのセットであることに気付くでしょう。

しかし、彼らはしません。願わくば、あなたもそうするでしょう。