これは基本的な初心者レベルの質問で、短くはありません。これはバックエンドレスに固有のものです。
私はいくつかの形で相互に関連しており、さまざまな方向から調査する必要があるテーブルの小さなセットを扱っているため、対処したいシナリオがいくつかあります。
基本的な例は、PersonTable や AddressTable などです。lastName、firstName などの人のリストを含む PersonTable。 住所と、streetName、houseNumber などのさまざまな属性を含む AddressTable。
ユーザーにメイン ナビゲーションで 2 つの異なるビューを提供し、さらにドリルダウンできるようにしたいとします。
View1: 「People」をクリックすると、PersonTable から人のリストが取得されます。このリストは、セカンダリ ナビゲーション ウィンドウに表示されます。個々の人をクリックすると、その人に関連付けられた住所が表示されます。
ただし、これを逆に実行できるようにしたい：
View2: 「住所」をクリックすると、AddressTable から住所の一覧が取得されます。このリストは、セカンダリ ナビゲーション ウィンドウに表示されます。個々のアドレスをクリックすると、そのアドレスに関連付けられた人物が表示されます。
したがって、一方向のアプローチからは、PeopleTable から AddressTable への関係が存在します。これは、ビュー 1 に最適です。1 つのクエリでセカンダリ ナビゲーション用のデータが提供され、そのクエリの結果には、ドリル ダウンに必要な関係データが含まれる場合があります。
ただし、ビュー 2 をサポートしたい場合は、関係の方向と開始点を考慮して、2 つのクエリを実行する必要があります。
これをより多くのテーブルとフィールドを含む大規模なデータ セットにスケーリングすると、私の懸念がより明確になる可能性があります。最初のセカンダリ ナビゲーション アイテムの作成で、リレーションシップの親から実際にいくつかのデータを提供したいからです。つまり、アイテムをリストするためのそのテーブルの最初のクエリと、最初のリストに表示されているデータを完成させるための個々のアイテムのクエリ (リレーションシップの親から必要なデータを取得するため) を意味します。(アイテムをクリックすると、さらに詳細が表示されます)。明らかに、この関係は逆転する可能性があり、親データではなく子データをプルしますが、反対方向 (他のビュー) からデータを取得したい場合、同じ状況に再び陥ります。
TL;DR: どのような場合でも、必要なクエリの数を最小限に抑えながら、ほぼすべての方向にテーブルをトラバースし、データにドリルインできるようにする必要があります。これは、多数の関係が保証されるケースですか?
質問の根源にたどり着く: 私の理解では、バックエンドレスはそれらをサポートしていますが、双方向の関係は一般的に (少なくとも SQL の世界では) 嫌われています。
では、実際には、ベスト プラクティスとは何でしょうか。それは単に「クエリを減らすのに役立つ場合は関係を作成する」という論理的なものですか?