タグ付けされた質問 「database-design」

概念スキーマおよび/または論理モデルおよび/またはデータベースの物理設定の開発。

2
推移的な外部キーを追加する必要がありますか?
簡単な例:顧客のテーブルがあります。 create table Customers ( id integer, constraint CustomersPK primary key (id) ) データベース内の他のすべてのデータはにリンクする必要があるCustomerため、たとえばOrders次のようになります。 create table Orders ( id integer, customer integer, constraint OrdersPK primary key (customer, id), constraint OrdersFKCustomers foreign key (customer) references Customers (id) ) 次のようにリンクするテーブルがあるとしますOrders。 create table Items ( id integer, customer integer, order integer, constraint ItemsPK …

1
時間的妥当性と主/外部キーの関係
時間的な有効性と時間の機能を示すオラクルのチュートリアルをいくつか読みました。ただし、私が読んだ例では、デモテーブルで使用されている主キーはありません。 http://docs.oracle.com/cd/E16655_01/appdev.121/e17620/adfns_design.htm#ADFNS1005 http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/ilm /temporal/temporal.html これらのテーブルに主キーを追加する必要がありますか?これらのテンポラルテーブルの1つが別のテーブルによってどのように参照されるのかについて疑問に思っているので、私は尋ねています。テンポラルテーブル間で外部キーを追加できますか? pk /外部キーの領域を追加してから、テーブルの参照先をpkで更新すると、fkのあるテーブルは、関係のなくなったレコードを指します。関係?もしそうなら、これはパフォーマンスにどのように影響しますか?通常の列を「外部キー」として使用し、クエリの参照期間に適切な列を選択するだけですか? 通常または疑似通常のpk / fkの使用法で時間データを表示する便利な例やチュートリアルを知っているか、持っている人はいますか? ありがとう

1
同じテーブルの2つの行を関連付ける方法
行を相互に関連付けることができるテーブルがあり、論理的には、その関係は2つの行の間で双方向(基本的に、方向がない)になります。(そして、もし疑問に思っているなら、はい、これは実際には1つのテーブルでなければなりません。これは、まったく同じ論理エンティティ/タイプの2つのものです。)これを表す方法はいくつか考えられます。 関係とその逆を保存する リレーションシップを1つの方法で保存し、データベースに逆方向の保存を制限し、FKの順序が逆の2つのインデックスを作成します(1つのインデックスはPKインデックスです)。 2つのインデックスを使用して関係を一方向に保存し、いずれにしても2番目のインデックスを挿入できるようにします(ややこしいですが、ちょっと、完全性) ある種のグループ化テーブルを作成し、元のテーブルにFKを適用します。(多くの質問が発生します。グループ化テーブルには数しかありません。なぜテーブルさえ持っているのですか?FKをNULL可能にするか、単一の行が関連付けられたグループがあるのですか?) これらの方法の主な長所と短所は何ですか?もちろん、私が考えていない方法はありますか? 以下は、使用するSQLFiddle です:http ://sqlfiddle.com/#!12/7ee1a/1/0 。(私が使用しているため、PostgreSQLであるように思われますが、この質問はPostgreSQLに固有のものではないと思います。)現在、例として、関係とその逆の両方を保存しています。

3
RESTful APIのSQLデータベース構造
RESTful APIを作成しています。リソースを中心にデータベーステーブルを設計する最良の方法を決定するのに苦労しています。 最初は、リソースごとのテーブルが適していますが、これにより、リソースチェーンをさらに下っていくと、テーブルが指数的に大きくなるのではないかと心配しています。 たとえば、ユーザー、クライアント、販売の3つのリソースがあるとします。ユーザーは私のAPIのサブスクライバーであり、クライアントはユーザーの顧客であり、販売は各クライアントがユーザーアカウントに対して行った購入です。 次のように販売リソースにアクセスします GET /users/{userID}/clients/{clientID}/sales/{salesID} したがって、10人のユーザーがあり、それぞれに10人の顧客がいて、それぞれの顧客について10件の売上がある場合、テーブルサイズは、リソースチェーンを下に行くほど大きくなります。 SQLが大きなテーブルに対応できるとは確信していますが、読み取りと書き込みがどのように遅くなるかはわかりません。上の例はそれを説明していないかもしれませんが、私のAPIは次第に多くの書き込みと読み取りを行って、リソースチェーンのさらに下に行きます。したがって、データベース内の最大のテーブルが、小さいテーブルよりも多くの回数読み書きされるシナリオがあります。 クエリを実行する前にテーブルを結合する必要もあります。その理由は、各ユーザーが同じ名前のクライアントを持つことを許可するためです。間違ったクライアントデータを取得しないように、usersテーブルとclientsテーブルは{userID}によって結合されます。これは販売にも当てはまります。大きなテーブルを結合して読み取りと書き込みを実行すると、処理がさらに遅くなりますか?

4
カテゴリ間で決定するスーパータイプ/サブタイプ:完全にばらばらまたは不完全な重なり
デスクトップコンピュータ、ラップトップ、スイッチ、ルーター、携帯電話などのITハードウェアを格納するインベントリデータベースを構築しています。すべてのデバイスが単一のテーブルに格納されているスーパータイプ/サブタイプパターンと特定の情報を使用しています。サブタイプのテーブルに入れられます。私のジレンマは、次の2つのデザインから選択しています。 上の図では、すべてのデバイスが共通のサブタイプを共有しています。たとえば、デスクトップコンピューターとラップトップは、次のテーブルのレコードを持ちます:デバイス、ネットワークデバイス。スイッチには、デバイス、ネットワークデバイスのレコードがあります。ルーターは、Device、NetworkDevice、WANDeviceにレコードを持っています。位置情報を追跡するデバイスには、位置情報の記録があります。このセットアップについて私が考えたいくつかの長所と短所: 長所:HostnameやLocationIDなどの共通フィールドに基づいてレコードを選択する方が簡単です。 プロ:nullフィールドはありません。 欠点:特定のデバイスのCRUD操作に含める必要があるテーブルは明確ではなく、将来のDBAを混乱させる可能性があります。 下の図では、すべてのデバイスに独自のサブタイプがあります(ここには表示されていないデバイスのクラスがさらにあります)。この状況では、どのテーブルレコードが挿入または選択されるかは明らかです。デスクトップコンピューターとラップトップはコンピューターなどに行きます。このセットアップについて私が考えたいくつかの長所と短所: メリット:サブタイプのCRUD操作に使用するテーブルはすぐにわかります。 メリット:CRUD操作には1つのテーブルのみを使用する必要があります。 欠点:共通のサブタイプフィールドに基づいてレコードをSELECTするには、すべてのテーブルを組み合わせる必要があります。たとえば、HostnameやLocationIDによる検索などです。 どちらの状況でも、ClassDiscriminatorフィールドは、CHECK制約で使用できるようにサブタイプテーブルに配置され、挿入できるタイプを制御します。 設計が優れている推奨事項はありますか、それとも完全に意見の問題であり、データベースの意図した目的に依存していますか? 編集:私が持っている特定の質問は、「NetworkDevice」テーブルの重複する性質についてです。このテーブルは、コンピュータ、スイッチ、ルーターなど、ホスト名やIPアドレスを持つデバイスのネットワーク情報を保持するためのものです。このテーブルの重複する性質は問題を引き起こす可能性があるものですか、それともこの方法で実装しても問題ありませんか? 提供された入力について、事前にありがとうございます。追加情報が必要かどうか尋ねてください。

1
請求書の生成と追跡
2週間ごとに、システムは会社の請求書を生成します。 会社は毎月1日と16日に請求書を受け取ります。(2週間ごとにCron Jobを介して実行されます。注文テーブルをスキャンし、「請求書」テーブルに追加します。別の方法はありますか?) 表には顧客の注文のリストがあり、ordersそれが所属する会社も示しています(orders.company_id) invoiceテーブルには、からの注文の総コスト計算orders表を。 私は、合理的な請求書追跡を設計する方法を理解しようとしています。会社によっては料金を送ってくれる場合もあれば、料金を送ってくれる場合もあります(invoice.amount) 次のもので請求書を追跡する必要があります。 会社が私に金額を送ったとき いつ会社に送金しましたか 会社から受け取った金額 会社にいくら送ったか 全額を受け取りましたか(受け取っていない場合、DBで何を更新する必要がありますか?) 請求書のステータス(送信済み、キャンセル済み、受領済み金額、送信済み金額) ここに私が思いついたデータベース設計があります: 会社のテーブル mysql> select * from company; +----+-----------+ | id | name | +----+-----------+ | 1 | Company A | | 2 | Company B | +----+-----------+ 顧客は私のウェブサイトから会社を選択できます。 注文表 mysql> select * from orders; +----+---------+------------+------------+---------------------+-----------+ | id …

2
Cassandraで多数(数千)の列ファミリーまたはキースペースを使用することのペナルティは何ですか?
現在、Cassandraのインストールに最適な設計を評価しています。 Cassandraが提供する最初の2つのアクセスレベル、つまりキースペースと列ファミリーの使用については、インターネットにはそれほど多くの情報はありません。 大量のキースペースまたは列ファミリー(> 10.000)を作成することを選択した場合、ペナルティはどのようなものになるのでしょうか。 どこか古いブログ投稿で、Cassandraが各列ファミリー用にメモリを予約することが示唆されました。この記事は0.6バージョンに関するもので、現在のバージョンは1.0です。これはまだ事実であり、本当の問題ですか? Cassandraで何千もの列ファミリーまたはキースペースを使用することのペナルティは何ですか?

2
個別のスキーマを使用すると、SQL Server 2008のパフォーマンスにどのような影響がありますか?
SQL Server 2008データベースで、目的の異なるオブジェクトに個別のスキーマを使用したい。今のところ、テーブルやストアドプロシージャの目的を示すためにかなり気の遠くなるような命名規則を使用しており、プレフィックスは、一意の名前の始まりを確認する前に5つまたは6つのxharacterをスキャンする必要があることを意味します。UIを駆動するためだけに使用されるテーブル(メニュー、ユーザー別の役割など)と、ディメンションテーブルとファクトテーブルなどのスキーマに別々のスキーマを使用したいと思います。 私の質問は、複数のスキーマ(スキーマ?)を使用することによるパフォーマンスへの影響はありますか?

3
魔法のコラム「名前」はどこから来たのですか?
私は偶然これを手に入れました: db=> select name from site; ERROR: column "name" does not exist LINE 1: select name from site; ^ db=> select site.name from site; name --------------- (1,mysitename) (1 row) 2番目のクエリは、行全体を含むタプルを返します。postgres 9.0.1を使用します。 編集:リクエストによるサイトの定義。私は本当に問題ではありません、この癖はどのテーブルでも機能します。 db=> \d site Table "public.site" Column | Type | Modifiers --------+---------+--------------------------------------------------- id | integer | not null default …

2
データベース/テーブルをスタックとして実装するにはどうすればよいですか
さまざまなユーザーのためにいくつかのファイル名をプッシュ/ポップする必要があるステートマシンがあります。私は伝統的にスタックをデータ構造の選択として使用していましたが、これはデータベースを使用して行う必要があります。これは、着信するWebリクエスト間でデータ構造を保持する方法がないためです。 データベースを使用してスタック機能を実装する良い方法は何でしょうか? 私はサポートする必要があります: push(fileName、user):ユーザーのfileNameをプッシュします pop(user):ユーザーの最上位のfileNameをポップします 編集: 私はアイデアのプロトタイピングをしているので、Pythonでsqlite3を使用しています。 ありがとう!

1
DynamoDBで複数のテーブルを使用する場合
DyanmoDBのベストプラクティスにより、次のことが明確になります。 DynamoDBアプリケーションでは、できるだけ少ないテーブルを維持する必要があります。ほとんどの適切に設計されたアプリケーションは、1つのテーブルのみを必要とします。 私がDyanmoDBを扱うのを見たほとんどすべてのチュートリアルがマルチテーブル設計を持っていることは、それから面白いと思います。 しかし、これは実際にはどういう意味ですか? ユーザー、プロジェクト、ドキュメントという3つの主要エンティティを持つ単純なアプリケーションを考えてみましょう。ユーザーは複数のプロジェクトを所有し、プロジェクトには複数のドキュメントを含めることができます。通常、ユーザーのプロジェクトとプロジェクトのドキュメントを照会する必要があります。読み取りは書き込みの数を大幅に上回ります。 素朴なチュートリアルのテーブルデザインでは、3つのテーブルを使用します。 Users Hash key user-id Projects Hash key Global Index project-id user-id Documents Hash key Global Index document-id project-id 簡単に折り畳んProjectでDocument1つのDocumentsテーブルにすることができます。 Documents Hash key Sort key Global Index project-id document-id user-id しかし、なぜそこで停止するのですか?1つのテーブルですべてを統治しないのはなぜですか?Userがすべての根であるため... Users Hash key Sort key user-id aspect --------- --------- foo user email: foo@bar.com ... …

6
個別の行としてではなく、1つの行の1つのフィールドに複数の値を格納することの利点
前回の毎週の会議中に、データベース管理のバックグラウンド経験がない人がこの質問を持ち出しました。 「データを複数行ではなくインライン(文字列)に保存することを正当化するシナリオはありますか?」 countryStates国の州を保存する場所と呼ばれるテーブルがあるとします。この例では米国を使用します。怠惰にするためにすべての国をリストすることはしません。 そこには2つの列があります。1つが呼び出さCountryれ、もう1つが呼び出されましたStates。ここで説明し、@ srutzkyの回答で提案されているように、これはISO 3166-1 alpha-3でPK定義されたコードになります。 テーブルは次のようになります。 +---------+-----------------------+-------------------------------------------------------+ | Country | States | StateName | +---------+-----------------------+-------------------------------------------------------+ | USA | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming | +---------+-----------------------+-------------------------------------------------------+ この同じ質問を友人の開発者に尋ねたところ、データトラフィックサイズの観点からは、これは役立つかもしれませんが、このデータを操作する必要がある場合はそうではないと述べました。この場合、リスト内のこの文字列を変換できるアプリケーションコードにインテリジェンスが必要です(このテーブルにアクセスできるソフトウェアがコンボボックスを作成する必要があるとしましょう)。 このモデルはあまり有用ではないと結論付けましたが、これを有効にする方法があるのではないかと疑いました。 私が聞きたいのは、実際に機能する方法で、このようなことをすでに見たり聞いたりしたりしていないかどうかです。

2
UUIDとIDを使用する必要がありますか
ロギングから遅延相関まで、さまざまな理由で、システムでUUIDをしばらく使用しています。私が使用したフォーマットは、次のように単純になったときに変化しました。 VARCHAR(255) VARCHAR(36) CHAR(36) BINARY(16) BINARY(16)パフォーマンスを基本的な自動インクリメント整数と比較し始めたのは、最後に到達したときです。テストとその結果を以下に示すが、あなただけの要約をしたい場合は、それがあることを示しているINT AUTOINCREMENTとBINARY(16) RANDOM(データベースが前の試験に事前に入力された)200000までの範囲のデータで同じ性能を有します。 私は当初、UUIDを主キーとして使用することに懐疑的でしたが、実際にはまだそうですが、両方を使用できる柔軟なデータベースを作成する可能性はここにあります。多くの人がどちらか一方の利点を強調しますが、両方のデータ型を使用することで相殺される欠点は何ですか? PRIMARY INT UNIQUE BINARY(16) このタイプの設定の使用例は、システム間の関係に一意の識別子が使用される、テーブル間の関係の従来の主キーです。 私が本質的に発見しようとしているのは、2つのアプローチの効率の違いです。追加のデータが追加された後はほとんど無視できる使用される4倍のディスク容量に加えて、それらは同じように見えます。 スキーマ: -- phpMyAdmin SQL Dump -- version 4.0.10deb1 -- http://www.phpmyadmin.net -- -- Host: localhost -- Generation Time: Sep 22, 2015 at 10:54 AM -- Server version: 5.5.44-0ubuntu0.14.04.1 -- PHP Version: 5.5.29-1+deb.sury.org~trusty+3 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; …

1
nullable列をテーブルに追加すると10分以上かかる
テーブルに新しい列を追加するのに問題があります。 数回実行しようとしましたが、10分以上実行した後、ロック時間のためクエリをキャンセルすることにしました。 ALTER TABLE mytable ADD mycolumn VARCHAR(50); 有用な情報: PostgreSQLバージョン:9.1 行数:〜250K 列の数:38 null許容列の数:32 制約の数:5(1 PK、3 FK、1 UNIQUE) インデックスの数:1 OSタイプ:Debian Squeeze 64 (HeapTupleHeaderを介して)PostgreSQLがnull許容列を管理する方法に関する興味深い情報を見つけました。 私の最初の推測は、このテーブルには既に8ビットの32個のnull許容列があるためMAXALIGN、HeapTupleHeaderは4バイトの長さです(検証されていません。その方法がわかりません)。 したがって、新しいnull可能列を追加するには、新しい8ビットを追加するために、すべての行でHeapTupleHeaderを更新する必要があり、MAXALIGNパフォーマンスの問題を引き起こす可能性があります。 そこで、null許容列の数を31に減らすために、null許容列の1つ(実際には実際にはnull許容ではありません)を変更して、私の推測が正しいかどうかを確認しようとしました。 ALTER TABLE mytable ALTER myothercolumn SET NOT NULL; 残念ながら、この変更には5分以上の非常に長い時間がかかるため、中止しました。 このパフォーマンスコストが発生する原因は何か考えていますか?


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.