つまり、データへのアクセスと変更をどのように計画しているかに、実際にはもっと関係があります。ほとんどすべての場合に最初のものをお勧めしますが、2番目の方が優れているエッジケースが存在する可能性があることを否定しません。私はあなたがそのような場合だとは思わない。
1つ目は、人々が予約についてどのように考えるかについてのより合理的な概算を提供します(これは良いことです)-また、誰がどの部屋にどの日に滞在するかを微妙にエンコードし、予約情報のように考えてDBの残りの部分に関連付けます、ゲスト情報。これらは、収集しているデータから洞察を収集しようとしているときに、データの関係を再考する機能を提供します。例えば。10年後、CEOが「ねえ、その年の歴史的に最も人気のある日付は何でしたか?「予約」モデルを使用すると、プログラムによるクエリを簡単に記述して、それを見つけることができます。「日付」を使用するとどうしますか。 / Room Matrix'モデルでは、すべての列を手動でチェックする必要があります。
2番目のモデルは、変更を計画していないホテルには最適ですが、部屋をローテーションの内外に配置する必要がある場合はどうなりますか?どの部屋がどの日に一般に利用可能であるかについてのブール値を含む別の100列のテーブル?故障で占められている収縮?翼を追加するとどうなりますか?このテーブルなどにさらに25列を追加しますか?「どの部屋が利用可能かを正しく知っているか」という運用効率が得られる可能性があります。-しかし、「8月3日から6日まで利用できる部屋はどれですか?」というクエリをどのように構成しますか?
リレーショナルデータベースでは、列の値に基づいて特定の行のセットを選択しているため、行の値に基づいて列のセットを選択するのは非常に困難です。