リレーショナル データベースを使用して Node というエンティティの永続性と CRUD レイヤーとして機能するように DB スキーマを設計する場合、Node というテーブルと NodeInstance という別のテーブルを作成する状況はありますか?
この質問は、私が取り組んでいる iPad アプリのバックエンドのストレージ、永続性、および CRUD データ層として機能することを目的としたデータベース スキーマの設計中に、同僚がコストのかかる間違いを犯すのを思いとどまらせるために投稿されました。将来のメンテナンスの悪夢となるバグや問題の作成を避けるためです。私は NDA を締結しているため、プロジェクトの正確な性質に関する詳細を投稿することはできませんが、サーバー上に CRUD レイヤーを作成している主要なエンティティはノードと呼ばれます。したがって、バックエンドで作業している同僚に、Node オブジェクトを表す Node というクラスを作成し、Create 操作のためにリレーショナル DB の Node テーブルに行を挿入することをお勧めしました。
しかし、何らかの理由で、私の同僚は、Node オブジェクトを永続化するために 1 つのテーブルを持つことは間違ったアプローチであり、正しいアプローチは Node テーブルと NodeInstance テーブルを作成し、2 つのテーブルを並行して維持して永続性を管理することであると考えているようです。 Node エンティティはより効率的/パフォーマンス的です。私はちょっとした ORM オタクであり、DB スキーマのオタクでもあるので、既知の宇宙に 2 つのテーブルのアプローチを使用して 1 つのエンティティに対して永続化して CRUD を実行する惑星があるかどうかを調べようとしました。良いアイデアですが、すべてのシナリオで、これによりコードが複雑になるように思われます。言うまでもなく、不要な SQL 結合、データの整合性を維持するための複数のクエリ、アトミック トランザクションの問題、および同時実行の問題が必要になることは言うまでもありません。でも、私の同僚のアプローチが正気である理由を理解するのに役立つ誰かがstackoverflowにいる場合、私は心を開いて、私の同僚が正しいという考えを楽しませたいと思います. しかし、これを書いている時点では、私の同僚は ORM を完全には理解していないので、1 つのエンティティを永続化するために 2 つのテーブルを使用することを考えていると確信しています。私の尊敬するstackoverflowの仲間と専門家であるこの問題について、知恵を貸してください。