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

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

4
文書化されていない大規模なデータベースに取り組む方法
私は最近、特定のX社の唯一のITガイとして雇われ、彼らのアプリケーションを修正する必要があります。私の意見では、データベースを理解することから始めるのが最善の方法です。 彼らの現在のデータベースは186のテーブルを持つMySQLデータベースです（いくつかのテーブルは神が理由を知っているので空であることに注意してください）。また、アプリケーションはMS Accessデータベースインターフェイスを介してデータベースと通信しています。（私はなぜ開発者もそれをしたのか自問します） 質問は、この文書化されていない大規模なデータベースへの取り組みをどのように開始するかです。はい、それは文書化されていません。アプリケーションの開発者は、私の生活を簡単にするために、ERDやデータディクショナリ、またはデータベースに関する情報を提供するつもりがないからです。かなり大規模なデータベースの隅々を理解するというこの危険な努力にどう取り組むべきでしょうか。 関連質問：醜いデータベースに飛び込む方法は？
1
列の長さを変更（縮小）するとどうなりますか？
タイプNUMBER（精度とスケールなし）との2つの列があるとしVARCHAR(300)ます。私はそれらを変更したいので、これらの列は私のデータに対して大きすぎる方法であることを見たNUMBER(11)とVARCHAR(10)。したがって、次のSQLステートメントを実行すると、 ALTER TABLE FOO MODIFY(BAR NUMBER(10)); 空でない列でそれを行うことはできますか？ もしそうなら、何よりも1つの値がある場合NUMBER(10)、オラクルはそれについて教えてくれますか？ 以前に定義されている場合、列のデフォルト値は変更されないままですか？ 列のNULL可能オプションは変更されませんか？ その列の主キー、外部キー、一意キーは変更されませんか？ その列を含む制約は変更されませんか？ その列のインデックスは変更されませんか？ 私の質問に答える公式文書はありますか？
3
在庫アイテムにさまざまな属性がある場合の在庫データベース構造
エンタープライズハードウェア情報を格納するためのインベントリデータベースを構築しています。データベースがワークステーション、ラップトップ、スイッチ、ルーター、携帯電話などからの範囲を追跡するデバイス。デバイスのシリアル番号を主キーとして使用しています。私が抱えている問題は、これらのデバイスの他の属性がさまざまであり、他のデバイスに関係のないフィールドをインベントリテーブルに含めたくないということです。以下は、データベースの一部のERDへのリンクです（一部のFK関係は表示されていません）。たとえば、ワークステーションデバイスタイプのデバイスを電話テーブルに配置できないように設定しようとしています。これには、デバイスタイプまたはクラスを検証するために多くのトリガーを使用する必要があり、異なる属性を持つ異なるデバイスが追跡されるときはいつでも新しいテーブルが使用されます。 シリアル番号にマップできる属性テーブルの設定を調べましたが、デバイスタイプに適用されない属性をデバイスに割り当てることができます。たとえば、必要に応じて誰かがワークステーションに電話番号属性を割り当てることができます。 。このサイトで次のような構造の説明を見つけました。 この構造は、属性がすべて私が保存しているアイテムに適用できる場合に最適です。たとえば、データベースに携帯電話のみが格納されている場合、属性は、タッチスクリーン、トラックパッド、キーボード、4G、3Gなどです。その場合、それらはすべて電話に適用されます。データベースには、hostname、circuitType、phoneNumberなどの属性があり、特定のタイプのデバイスにのみ適用されます。 特定のデバイスタイプに適用される属性のみがそのタイプのデバイスに割り当てられるように設定します。このデータベースのセットアップ方法に関する提案はありますか？これが1対1の関係の適切な使用であるかどうか、またはこれを行うより良い方法があるかどうかはわかりません。お時間を割いていただき、誠にありがとうございます。 ここに私が読んだ他のスレッドのいくつかがあります。彼らは私にいくつかの良い洞察を与えました、しかし私は彼らが本当に適用するとは思いません： /programming/9335548/how-to-structure-database-for-inventory-of-unlike-items /programming/1249632/database-structure-for-items-with-varying-attributes /programming/5559587/product-inventory-with-multiple-attributes /programming/6613802/question-about-setting-up-inventory-database /programming/514111/how-to-best-represent-items-with-variable-of-attributes-in-a-database
3
SQLで1対0または1の関係を実装する
1対0または1（1-0..1）の関係が存在するシナリオ用のデータベースを設計しているとしましょう。例えば： ユーザーのセットがあり、一部の ユーザーは顧客である場合もあります。 したがって、対応する2つのテーブル、usersおよびを作成しましたcustomersが、… …特定のSQLプラットフォームでこの状況を表現して実装する最良の方法は何ですか？私は2つの可能な解決策を検討しました： でusersテーブル、追加customerのFOREIGN KEY参照のいずれであってもよく、列customersまたはNULLマーク。 customersテーブルに、テーブルを指すuser列（UNIQUE制約付きで設定）を含めusersます。 すでにいくつかのフォーラムで同様の質問をしましたが、答えは基本的に「必要なものは何でも」「便利だと思うものは何でも」でした。このような答えは好きではありません。代わりに、DB理論の真面目な部分が必要です。1-0..1の関係についてどこで確認できますか？
5
ER図の重要性
私は学生で、学界の一部としていくつかのプロジェクトを開発しています。 あるプロジェクトのデータベースを開発しているときに、ERDが必要かどうかを考えている状況に遭遇しました。現在、私たち全員が最初にERDを開発し、次にそれからデータベースを開発することに同意しているわけではありません。 大多数の人は、紙で直接要求されるシステムに従って口頭でデータベースをオンザフライで開発することを好みます。 現在、私はデータベースの原則を厳守しています。データベースはERDのみから開発する必要があると思います。だから、私は次のことを知りたいだけです： 業界はこれらの原則に従っていますか？ ERDの開発に時間を浪費しているだけですか？ ERDを開発する利点は何ですか？
4
広範なPKを使用する場合と、個別の合成キーおよびUQを使用する場合のパフォーマンスに関する考慮事項は何ですか？
レコードがいくつかの広範なビジネス分野で一意に識別できるいくつかのテーブルがあります。過去に、これらのフィールドをPKとして使用しましたが、これらの利点を考慮しています。 シンプルさ。無関係なフィールドはなく、インデックスは1つだけです クラスタリングにより、高速マージ結合と範囲ベースのフィルターが可能になります ただし、合成IDENTITY INTPK を作成し、代わりに別のUNIQUE制約を使用してビジネスキーを強制するケースについて聞いたことがあります。利点は、PKが狭いため、セカンダリインデックスがはるかに小さくなることです。 テーブルにPK以外のインデックスがない場合、2番目のアプローチを採用する理由はありませんが、大きなテーブルでは、インデックスが将来必要になる可能性があると想定して、狭い合成PKを採用することをお勧めします。 。考慮事項が不足していますか？ ちなみに、私はデータウェアハウスで合成キーを使用することに反対しているのではなく、単一の広いPKを使用する場合と、狭いPKと広いUKを使用する場合にのみ関心があります。
2
このテーブルを無損失で分解できますか？
私は自分のリーグではないデータベース設計の問題に出くわしました。そして、私の頼りになるDBAの第一人者が消防訓練に出かけています。 本質的に、私は次の主キー（簡潔にするためにPK）を持つテーブルを持っています。 child_id integer parent_id integer date datetime child_idそして、parent_idエンティティテーブルへの外部キーです。「子」テーブル自体にも「親」テーブルへの外部キーが含まれています。loはそれぞれ、child_id常にparent_id上記のテーブルで想定されているものと同じものを参照します。実際、この2つを同期させるための追加のコードがあることがわかります。 これにより、この熱狂的な正規化の初心者は「代わりに冗長性を削除する必要があります！」と言います。 私は次のように分解します。 Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY そして、これらの人たちを自然な方法で結合すると、元のテーブルが回復します。この5NFを作ったのは私の理解です。 しかし、今ではビジネスルールが隠されていることに気づきました。 通常、特定child_idのに関連付けられている日付は、対応するに関連付けられている日付のサブセットである必要がありますparent_id。最初のテーブルがこのルールを適用していることがわかります。 日付が大きくなりすぎるまで自由に表1に追加できるため、私の分解ではルールを適用しません。 これは私をここに導き、次の質問があります： この分解は5NFですか？私はそれが挿入異常を許可すると言うだろうが、また次のそれ自体、Wikiの例に従うように見えるこのガイドを。「私が強調したもの」というフレーズは、「3つの別個のレコードタイプからなる正規化された形式からすべての真の事実を再構築できる」という特別な休止を与えますTable_1。 この分解が気に入らないとしましょう（気に入らない）。テーブルとコードをそのままにしておくことが実際的な解決策であることを私は自由に認めます。しかし、理論的には、最初のテーブルから離れてビジネスルールを保持するように制約を分解または追加する方法はありますか？
4
時間ディメンションテーブルのどこにインデックスを配置すればよいですか？
インデックスについてこのウェブサイトからの質疑応答を読んだ後、疑問が浮かびました。 もし、1日がより細かいレベルの時間ディメンションテーブルを使用しているとしたらどうでしょう。インデックスはどこに置くべきですか？ 質問のランディ・メルダー：RDBMSで「インデックス」とはどういう意味ですか？言った： インデックスを「目次」と考えてください...これは、ファイル内の位置へのポインタ、つまりオフセットの順序付きリストです 時間ディメンションの場合、ほとんどのデータ調査は特定の日、特定の週、特定の月、または特定の年のすべての日がタイムテーブルに保存されている場合は特定の四半期に対して行われる可能性があります。 私の質問は、これらすべてのフィールドにインデックスを設定する必要がありますか？ 日は一意であると想定されているため、この日についてはインデックスの使用を完全に理解しています。ただし、週IDには7回、月IDには30/31回、四半期IDには120回程度の発生があります。 それらのフィールドにインデックスを付ける必要がありますか？ それはまだ役に立ちますか？ 同じ質問で、David Spillettが言ったので、私はあなたに尋ねます： インデックスを追加することは、もちろん最適化の悪い結果になる可能性があります。インデックスを格納するために使用される余分なスペース（および、DBが多数の書き込み操作を確認した場合にインデックスを維持するためのIO負荷）は、わずかに最適化されていない読み取りクエリよりも悪い問題である可能性があるためです。 、無理しないでください。 それでは、時間ディメンションの場合の最良の考慮事項は何でしょうか？
5
テーブルの行サイズと最大行サイズを計算する
問題： テーブルの作成に使用されるバイト数を計算する方法はありますか？information_schema.tablesからいくつかの情報を取得できますが、その情報は十分に正確ではありません。 実際に必要なのは、innodbのみのテーブルの定義によるバイト数であり、照合はutf-8-general-ciと見なすこともできます。 たとえば、テーブルテストは次のようになります。 テーブルテストの作成 （ col1 varchar（25）、 col2 int、 col3 varchar（3）、 col4 char（15）、 col5 datetime ））; これで、テーブルの列のタイプに応じて1つの行に累積できる合計行サイズを知る必要があります。 MSSQLで同様のソリューションを見つけたが、MySQLバージョンが必要 任意のテーブルの行サイズを推定するスクリプト どんな助けでも大歓迎です。
2
フラグとテーブルの分割
私は（潜在的に）数千万のレコードを含むアイテムのテーブルを設計しています。一部のアイテムは、管理者によって「承認」されるまで使用できません。「使用」とは、そのような項目が「承認」されるまで他のテーブルで参照されないことを意味します。アイテムの最大50％は、いつでも「承認されない」可能性があります。レコードは「承認」される可能性がありますが、その逆はできません。 2つの設計オプションを検討します。 ビットフラグ 「未承認」アイテムの個別のテーブル-アイテムが承認されると、「通常」テーブルに移動されます（アイテムのIDの更新は問題ではありません） 2番目のオプションの方がはるかに良いと思います。ビットフラグは行ごとに1バイトしかとらないため、問題はありません。ただし、同じテーブルに100万件の承認済みレコードと100万件の未承認レコードがある場合、承認済みレコードを使用した操作のスキャン時間は増加します。 質問は、代わりに最初の（ビットフラグ）オプションを検討する必要がありますか？説明されている状況で何かメリットがありますか？
2
投稿への高評価または投票
ユーザーが投稿したりブログを書いたりする小さなプログラムを作っています。これらの投稿では、他のユーザーがFacebookのように投稿を高く評価したり、低く評価したり、Stackoverflowのように投稿に賛成または反対票を投じたりできます。一般的に使用されている適切なデータベース構造と、プログラムがその構造で効率的に機能することを知りたいのですが。2つのオプションがあります 最初 役職： id head message datepost likes dislikes 1 ab anchdg DATE 1,2,3 7,55,44,3 上記のようにid、postidです。「いい1,2,3ね！」列には、投稿またはブログを高く評価したか賛成したユーザーのIDを指定します。7,55,44,3投稿またはブログを低評価または反対票を投じたユーザーのIDです。 二番目 役職： id head message datepost 1 ab anchdg DATE いいね： id postid userid 1 1 1 2 2 2 嫌い： id postid userid 1 1 7 2 1 55 このように、私は投稿のいいねを取得するために、いいねと嫌いのために2つの個別のテーブルを作成する必要があります。このようにして、テーブル、つまりLikes＆Dislikesは非常にいっぱいになります。これにより、テーブルが重くなり、処理が遅くなる場合があります。 それで、私はこのタスクを達成するためのより良い標準的な方法がどれであるか知りたいですか？
1
「2つのテーブルから離れた」制約の適用
SQLで電気回路図をモデリングするときに問題が発生しました。キャプチャしたい構造は part ←────────── pin ↑ ↑ part_inst ←───── pin_inst ここで、「inst」は「instance」の略です。 例えば、私のように持っているかもしれないpartとのLM358オペアンプpinの1OUT、1IN-、1IN +、GND、2IN +、2IN-、2OUT、およびV CC。次に、このパーツを回路図に配置して、a part_instと8を 作成しpin_instます。 データフィールドを無視して、スキーマでの最初の試みは create table parts ( part_id bigserial primary key ); create table pins ( pin_id bigserial primary key, part_id bigint not null references parts ); create table part_insts ( part_inst_id bigserial primary key, part_id …
2
複数のユーザータイプとその連絡先情報のデータベース構造のモデリング
さまざまなタイプのユーザーを格納するデータベースを設計しています。主に（ただし、これに限定されません）、俳優、監督、作家になります。現在、関連するユーザータイプは4つだけです。この数は増加する可能性がありますが、確率は低く、そのような場合は非常に小さい数になる可能性があります。 計画は持っているusersサイトにログインするためにかなりの責任を負うテーブルを（name、emailおよびpasswordそれぞれのユーザタイプのそれぞれの列に加えて1つまたは複数のそのような彼らが承認されてきたかどうかなど、他の二つ、とupdated_atの）、および追加のテーブルごといます独自の列のセットがあります。たとえば、俳優だけが民族の列を持ち、ディレクターだけが経歴の列を持ち、ライターだけが場所を提供する必要があります。ただし、この複雑なデータベースを管理したことがないので、いくつかの側面を整理する方法を考えています。 第一に、ユーザーは上記のタイプのいずれか、または任意の組み合わせにすることができます。だから私は（例えば）と列を持つdirector_userテーブルのようなものが必要になることを理解しdirector_idていuser_idます。これで、ロールタイプなどですべてのユーザーをフィルタリングできるようになりますか？ 次に、ほとんどのユーザーはTwitterのプロフィールと電話番号のオプションを選択します。また、すべての俳優には、他のオンライン俳優プロファイルのURLを少なくとも1つ含める必要があります。現在、含めることができる3つがありますが、この数は増える可能性があります。可能なプロファイル/連絡方法ごとに個別のテーブルがデータを編成するための最適な方法であると私は思いますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.