そのnoobの質問については申し訳ありませんが、データベース内のテーブルと1対1の関係を使用する必要があるのでしょうか。1つのテーブル内に必要なすべてのフィールドを実装できます。SELECTデータが非常に大きくなった場合でも、を使用する代わりに、ステートメントで必要な列名を列挙できますSELECT *。いつ本当にこの分離が必要ですか？
38684 次
14 に答える
133
1から0..1
スーパークラスとサブクラスの間の「1から0..1」は、継承を実装するための「個別のテーブル内のすべてのクラス」戦略の一部として使用されます。
「1から0..1」は、「0..1」の部分がNULL可能なフィールドで覆われている単一のテーブルで表すことができます。ただし、関係がほとんど「1から0」で、「1から1」の行が数行しかない場合は、「0..1」の部分を別のテーブルに分割すると、ストレージ（およびキャッシュのパフォーマンス）のメリットがいくらか節約される可能性があります。一部のデータベースは、他のデータベースよりもNULLの格納が効率的であるため、この戦略が実行可能になる「カットオフポイント」は大幅に異なる可能性があります。
1対1
実際の「1対1」はデータを垂直方向に分割します。これは、キャッシュに影響を与える可能性があります。データベースは通常、個々のフィールドのレベルではなく、ページレベルでキャッシュを実装するため、行から少数のフィールドのみを選択した場合でも、通常、行が属するページ全体がキャッシュされます。行が非常に広く、選択したフィールドが比較的狭い場合、実際には必要のない多くの情報をキャッシュすることになります。このような状況では、データを垂直方向に分割すると便利な場合があります。これにより、より狭く、より頻繁に使用される部分または行のみがキャッシュされ、より多くのデータがキャッシュに収まり、キャッシュが効果的に「大きく」なります。
垂直分割のもう1つの使用法は、ロック動作を変更することです。データベースは通常、個々のフィールドのレベルではロックできず、行全体のみをロックできます。行を分割することにより、その半分の1つだけでロックを実行できるようになります。
トリガーも通常、テーブル固有です。理論的にはテーブルを1つだけにして、トリガーに行の「間違った半分」を無視させることができますが、一部のデータベースでは、トリガーが実行できることと実行できないことに対して追加の制限を課す場合があり、これは実用的ではありません。たとえば、Oracleでは変更テーブルを変更できません。個別のテーブルを使用することで、1つだけが変更される可能性があるため、トリガーからもう1つを変更できます。
個別のテーブルにより、よりきめ細かいセキュリティが可能になる場合があります。
これらの考慮事項はほとんどの場合無関係であるため、ほとんどの場合、「1対1」のテーブルを単一のテーブルにマージすることを検討する必要があります。
于 2012-09-07T15:40:30.350 に答える
34
私の2セント。
私は私たち全員が大規模なアプリケーションで開発する場所で働いており、すべてがモジュールです。たとえば、usersテーブルがあり、ユーザーのFacebookの詳細を追加するモジュールと、ユーザーにTwitterの詳細を追加するモジュールがあります。これらのモジュールの1つを取り外して、そのすべての機能をアプリケーションから削除することを決定できます。この場合、すべてのモジュールは、次のように、1：1の関係を持つ独自のテーブルをグローバルusersテーブルに追加します。
create table users ( id int primary key, ...);
create table users_fbdata ( id int primary key, ..., constraint users foreighn key ...)
create table users_twdata ( id int primary key, ..., constraint users foreighn key ...)
于 2017-05-09T22:01:52.303 に答える
29
2つの1対1のテーブルを1つに配置すると、セマンティクスの問題が発生する可能性があります。たとえば、すべてのデバイスに1つのリモートコントローラーがある場合、デバイスとリモートコントローラーの特性を1つのテーブルに配置するのはあまり良いことではありません。特定の属性がデバイスに属しているのか、リモートコントローラーに属しているのかを判断するのに時間を費やす必要がある場合もあります。
列の半分が長い間空のままである場合や、入力されない場合があります。たとえば、車には、多数の特性を備えたトレーラーが1つある場合と、ない場合があります。したがって、未使用の属性がたくさんあります。
テーブルに20個の属性があり、そのうちの4つだけがたまに使用される場合は、パフォーマンスの問題のためにテーブルを2つのテーブルに分割するのが理にかなっています。
このような場合、すべてを1つのテーブルにまとめるのは良くありません。また、45列のテーブルを扱うのは簡単ではありません。
于 2012-09-07T13:20:55.050 に答える
25
一方のテーブルのデータがもう一方のテーブルによって記述されたエンティティに関連しているが、「属していない」場合、それはそれを分離しておくための候補です。
これにより、個別のデータを他のエンティティに関連付ける必要がある場合にも、将来的に利点が得られる可能性があります。
于 2012-09-07T13:20:17.140 に答える
16
これを使用する最も賢明な時期は、このようにしか関係しない2つの別個の概念がある場合です。たとえば、車には現在のドライバーが1人しかいませんが、ドライバーは一度に1台の車しか運転できません。したがって、カーとドライバーの概念の関係は1対1になります。これは、点。
もう1つの理由は、さまざまな方法でコンセプトを専門化したいということです。Personテーブルがあり、従業員、顧客、株主など、さまざまなタイプのPersonの概念を追加する場合は、それぞれに異なるデータセットが必要になります。それらの間で類似しているデータはPersonテーブルにあり、スペシャリスト情報はCustomer、Shareholder、Employeeの特定のテーブルにあります。
一部のデータベースエンジンは、非常に大きなテーブル（多くの行）に新しい列を効率的に追加するのに苦労しており、新しい列が元のテーブルに追加されるのではなく、拡張テーブルが新しい列を含むために使用されるのを見てきました。これは、追加のテーブルのより疑わしい使用法の1つです。
パフォーマンスや読みやすさの問題のために、単一の概念のデータを2つの異なるテーブルに分割することもできますが、これは、最初から始める場合はかなり特殊なケースです。これらの問題は後で明らかになります。
于 2012-09-07T13:29:27.423 に答える
7
あまり頻繁ではありません。
セキュリティを実装する必要がある場合は、いくつかの利点があります。そのため、一部のユーザーは一部の列（table1）を表示できますが、他の列（table2）は表示できません。
もちろん、一部のデータベース（Oracle）では、同じテーブルでこの種のセキュリティを実行できますが、そうでないデータベースもあります。
于 2012-09-07T13:19:07.953 に答える
7
データベースの正規化を参照しています。私が管理しているアプリケーションで考えられる1つの例は、Itemsです。このアプリケーションを使用すると、ユーザーはさまざまな種類のアイテム（InventoryItems、NonInventoryItems、ServiceItemsなど）を販売できます。すべてのアイテムに必要なすべてのフィールドを1つのItemsテーブルに格納できますが、すべてのアイテムに共通のフィールドを含むベースItemテーブルを作成し、アイテムタイプ（Inventory、NonInventory、など）そのアイテムタイプのみに固有のフィールドが含まれています。次に、アイテムテーブルには、それが表す特定のアイテムタイプへの外部キーがあります。特定のアイテムテーブルと基本アイテムテーブルの関係は1対1になります。
以下は、正規化に関する記事です。
于 2012-09-07T13:23:40.440 に答える
7
まず、別のエンティティを構成するものをモデル化して定義することが問題だと思います。あなたがcustomersたった1つのシングルを持っているとしましょうaddress。もちろん、すべてを1つのテーブルcustomerに実装することもできますが、将来、彼に2つ以上のアドレスを許可する場合は、それをリファクタリングする必要があります（問題ではありませんが、意識的に決定してください）。
他の回答では言及されていない、テーブルの分割が役立つ可能性がある興味深いケースについても考えることができます。
customers繰り返しになりますが、それぞれが1つであると想像してくださいaddress。ただし、今回はアドレスを持つことはオプションです。もちろん、これを。NULLなどの-able列の束として実装することもできますZIP,state,street。しかし、あなたが持っているaddressとすると、はオプションではありませんが、stateはオプションであると仮定しますZIP。それを単一のテーブルでモデル化する方法は？テーブルに制約を使用することもできますがcustomer、別のテーブルに分割して、foreign_keyをNULL可能にする方がはるかに簡単です。そうすれば、モデルは、エンティティ addressがオプションであり、それZIPがそのエンティティのオプションの属性であると言うことで、はるかに明確になります。
于 2016-08-21T22:58:34.403 に答える
5
すべての設計の質問と同様に、答えは「状況によって異なります」です。
いくつかの考慮事項があります。
テーブルはどのくらい大きくなりますか（フィールドと行の両方の観点から）？メンテナンスとプログラミングの両方の観点から、ユーザーの名前とパスワードを、あまり使用されない他のデータと一緒に格納するのは不便な場合があります。
制約のある結合テーブルのフィールドは、時間の経過とともに管理が面倒になる可能性があります。たとえば、特定のフィールドに対してトリガーを起動する必要がある場合、そのフィールドが影響を受けたかどうかに関係なく、テーブルが更新されるたびにトリガーが発生します。
関係が1：1になることをどの程度確信していますか？この質問が指摘しているように、物事はすぐに複雑になる可能性があります。
于 2012-09-07T13:25:44.987 に答える
4
別の使用例は次のとおりです。たとえば、本に関する情報など、あるソースからデータをインポートして毎日更新する場合があります。次に、いくつかの本に関するデータを自分で追加します。次に、インポートしたデータを自分のデータとは別のテーブルに配置するのが理にかなっています。
于 2013-05-22T18:37:30.953 に答える
4
私は通常、実際には2つの一般的な1：1の関係に遭遇します。
IS-A関係。スーパータイプ/サブタイプ関係とも呼ばれます。これは、ある種類のエンティティが実際には別のエンティティのタイプである場合です（EntityAはEntityBです）。例：
- 同じ会社内の会計士、エンジニア、営業担当者用の個別のエンティティを持つ個人エンティティ。
- Widget、RawMaterial、FinishedGoodなどの個別のエンティティを持つアイテムエンティティ。
- トラック、セダンなどの個別のエンティティを持つ自動車エンティティ。
これらすべての状況で、スーパータイプエンティティ（Person、Item、Carなど）はすべてのサブタイプに共通の属性を持ち、サブタイプエンティティは各サブタイプに固有の属性を持ちます。サブタイプの主キーは、スーパータイプの主キーと同じになります。
「上司」の関係。これは、個人が組織単位（部門、会社など）の一意のボスまたはマネージャーまたはスーパーバイザーである場合です。組織単位に許可される上司が1人だけの場合、上司を表す個人エンティティと組織単位エンティティの間に1：1の関係があります。
于 2015-01-05T03:58:30.877 に答える
0
私のプログラミングの時、私はこれに遭遇したのは1つの状況だけでした。これは、同じ2つのエンティティ（「エンティティA」と「エンティティB」）の間に1対多および1対1の関係がある場合です。
「エンティティA」に複数の「エンティティB」があり、「エンティティB」に「エンティティA」が1つだけあり、「エンティティA」に現在の「エンティティB」が1つだけあり、「エンティティB」に「エンティティA」が1つしかない場合。
たとえば、車には現在のドライバーが1人しかいませんが、ドライバーは一度に1台の車しか運転できません。したがって、カーとドライバーの概念の関係は1対1になります。この例は@SteveFentonの回答から借りました。
ドライバーが同時にではなく、複数の車を運転できる場所。したがって、CarandDriverエンティティは1対多または多対多です。ただし、現在のドライバーが誰であるかを知る必要がある場合は、1対1の関係も必要です。
于 2015-11-11T20:08:19.207 に答える
0
別の使用例は、データベーステーブルの列の最大数を超えた場合です。次に、OneToOneを使用して別のテーブルに参加できます
于 2019-01-31T10:22:22.893 に答える
0
1対1の関係を使用する主な時期は、継承が関係している場合です。
以下では、人はスタッフおよび/または顧客になることができます。スタッフと顧客は個人の属性を継承します。利点は、個人がスタッフであり顧客である場合、その詳細が一般的な個人テーブルに1回だけ保存されることです。子テーブルには、スタッフと顧客に固有の詳細があります。
于 2021-09-22T02:49:14.520 に答える