1

これまでにいくつかのプロジェクトを見てきましたが、外部キーを使用しない (テーブルがリンクされていない) プロジェクトがある一方で、テーブルが実際にリンクされているプロジェクトがあることに気付きました。

iOSを使用するアプリケーションを開発していますがSQLITE3、アプリケーションを開発する際のベスト プラクティスはどれですか?

4

5 に答える 5

1

ベスト プラクティスは、外部キーを持つことです。個人的には、リレーショナル データベースに外部キーがないという考えは、私にはなじみがありません。（しゃれを許してください）外部キーは、参照整合性を強化するのに役立ちます。

于 2013-02-25T19:10:12.373 に答える
0

あなたは iOS 用のアプリを開発しているので、あなたの場合、オブジェクト モデルの設計とデータベース (テーブル) の設計はうまくいきます (データ プラミング コードは非常に簡単になります。それ以外の場合は、変更を加えるたびにデータ プラミング コードを微調整する必要があります)。あなたのアプリケーションで）。そうは言っても、オブジェクトに親子関係がある場合 (1 対 1 または 1 対多のマッピング) は、外部キー テーブル内に格納する必要があります。「親」オブジェクトはプライマリ テーブルに移動します。「子」オブジェクトは外部キー テーブルに入ります。

要件が非常に単純な場合は、情報を XML として保存することも検討できます。そうすれば、DB スキーマの設計について心配する必要はありません。あなたの検討のための1つの便利なリンク

http://www.informit.com/articles/article.aspx?p=1019623

于 2013-02-25T19:32:36.113 に答える
0

FK を持つことは、マネージ メモリを持つことに少し似ています。アプリケーションの実装でどれほど重大なエラーが発生したとしても、システム自体が「ダングリング ポインター」を作成することは決してありません。

外部キーは、データの整合性を維持するために不可欠です。彼らです：

  • 宣言型:これにより、アプリケーションの実装の深部に埋め込まれた命令型コードよりも「明白」になり、より自己文書化されます。
  • 堅牢:バグのあるアプリケーションが1つでもデータを破損する可能性があるため、アプリケーションによって回避できないデータの整合性を確保するための中央メカニズムを用意することが重要です。
  • スケーラブル:同時実行環境で FK を正しく実装するには、適切な同時実行制御 (ロックなど) が必要です。これは通常、アプリケーション レベルで可能になるよりも DBMS ではるかに効率的に実行できます。

正直なところ、SQLite などの組み込みデータベースでは、複数のクライアント アプリケーションが定期的に同じデータベースにアクセスする「大規模な」クライアント サーバー データベースほど重要ではありません。ただし、組み込み環境で FK を使用することにもマイナス面はないため、歴史的な理由による制限があまりない場合はいつでも使用する必要があります。

于 2013-02-25T21:51:09.060 に答える
0

遠い昔、アプリケーションは、データベースの一部として外部キーを持たない階層データベースまたはネットワーク データベース上に構築されていました。外部キーは、アプリケーションでコーディングする必要がありました。

これらのアプリケーションは、多くの非難と悲鳴を上げた後、最終的にリレーショナル データベースに移行されました。2011 年に IDMS から DB2 に移行されたアプリケーションの保守を手伝っています。

コードは変更されず、開発者はアプリケーションの一部として外部キーを維持し続けました。

于 2013-02-25T19:14:19.693 に答える
0

Railsフレームワークがデータベース上でもこれらの関係を作成していないように見えるのはなぜだろうか。彼は Active Record を使用してこれらの関係を作成します。

于 2013-03-24T03:47:21.863 に答える