4

テーブル構造について質問です。

質問を導入するための小さなシナリオを次に示します。クラス (let A) のオブジェクトをテーブルに格納するとします。

これを行うには、次の 2 つのテーブル構造が考えられます。

Structure A: "one field per row":
id (int),
name (text),
credit (int),
birthday (date).

Structure B: "all data in one row":
id (int),
data (bigtext).

次の点を考慮してください。

  • name/credit/birthday フィールドをフィルタリング/ソートするリクエストを実行することは決してありません
  • フィールドを編集する前に、オブジェクトをロードしたい
  • フィールド name/credit/birthday にはオプション/修飾子 (キー/一意/...) がありません

これらの2つのテーブル構造の違いは何ですか?

.

具体的には、ある時点でデータベースにオブジェクトを格納する必要がある PHP/SQLITE アプリを作成しています。毎回 db スキームを編集しなくても、db-stored-class を簡単に追加できるようにしたいと考えています。「構造B」を使用すると、そうすることができます。それは汚れているように見えるかもしれませんし、おそらく行を適切に入力する必要があることを教えられているでしょう..しかし、なぜですか?

「構造A」の主な利点は、選択フィルターと更新の有効性だけではありませんか?

4

4 に答える 4

2

リレーショナル データベースでは、すべてのデータが 1 つのフィールドにある例 2 を決して実行しないでください。それは非常に手間がかかり、柔軟性が大幅に低下します。

1 年後にデータベースにアクセスする別のプロジェクトを作成する場合は、検証、抽出などの多くの作業を複製する必要がありますが、すべてが別の列にある場合ははるかに簡単になります。

「名前/クレジット/誕生日のフィールドをフィルタリング/ソートするリクエストを決して実行しない」とあなたは言いました。ソフトウェア開発ですぐに学べることの 1 つは、「ああ、そんなことはあり得ない」というような発言は、必ず戻ってきて尻を噛むということです。

本当に b) のアプローチを使用したい場合は、少なくとも nosql を調べてください。私はそれについてあまり知りませんが、それがあなたが取りたいルートである場合、RDBMよりもあなたのプロジェクトに適しています

于 2012-09-08T16:43:24.370 に答える
1

あなたは、最近では完全に受け入れられるビジネス層/Web アプリですべてのデータの整合性を処理することについて話している.

テーブル構造をまったく使用するのではなく、JSON オブジェクトを格納するだけではどうですか? そうすれば、スキーマの変更を心配する必要がなくなり、フロント エンドで使用するためにオブジェクトをシリアル化/逆シリアル化することができます。

どんなデータベースでも実際には十分ですが、このようなものにキー/値ストア (NOSQL ソリューション) を使用することを検討してください。

あなたの質問に答えるために-違いは、フィールドに対してクエリを実行したり、データを検証したり、データの整合性を維持したりできることです.構造Bでは、アプリケーションのデータベース外でこれらすべてを処理しています.

オブジェクトに対してクエリを実行できないという認識された制限に関して、MapReduce を使用すると、JSON データに対して集計クエリを実行できます。

柔軟性が必要で、構造化データベースが提供する他の利点が必要ない場合はオプション B を選択してください。データベース内のデータを検証し、より簡単にクエリを実行したい場合はオプション A を選択してください。

構造 A の利点は、データに近いデータ整合性ルールと、さまざまな方法でデータを簡単にクエリできることです。

構造 B の利点は、拡張性とスケーラビリティです。アプリケーションでデータ構造を簡単に変更できます。また、スケーリングが必要な場合は、データを水平方向に簡単に分割できます。

于 2012-09-08T16:24:50.067 に答える
0

いいえ。たとえば、タイプ セーフはどうでしょうか。構造 B で、自分の誕生日を「ネバーの 12 日」、「赤」、または「3.1415」と宣言するのを妨げるものは何ですか?

于 2012-09-08T16:16:42.740 に答える