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

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


1
2つの可能な所有者/親タイプを持つエンティティのデータベーススキーマ?
私はSequelizeをORMとしてPostgreSQLを使用しています。 1つのタイプがありUserます。2番目のタイプはGroupで、GroupMembershipsテーブルを介して任意の数のユーザーを関連付けることができます。Userは、任意の数のを所有することもできGroupます。 3番目のタイプはPlaylist、UserORまたはaのいずれかに属することができgroupます。このタイプのスキーマを設計して、1つのタイプの所有者またはいずれかのタイプの所有者を持つことができる最善の方法は何ですか? 最初のパスでは両方の関連付けを作成しましたが、一度に1つだけ入力しました。これは機能する可能性がありますが、ハックに見え、クエリを困難にします。 追加情報 コメントを介してMDCCLによって投稿された説明要求に対する私の応答は次のとおりです。 (1)プレイリストが特定のグループによって所有されている場合、このプレイリストは、そのグループのメンバーである限り、1 対多のユーザーに関連していると言えますか? これは技術的には正しいと思いますが、この1対多の関連付けは明示的には存在しません。 (2)では、特定のプレイリストを1 対多のグループが同時に所有することは可能ですか? いいえ、をPlaylist1対多で所有することはできませんGroups。 (3)特定のプレイリストを1 対多のグループ、およびそのようなグループのメンバーではない1 対多のユーザーが所有することは可能ですか? いいえ。(2)のように、1対多のto が存在しPlaylistてGroupはならないためです。さらに、Playlistがによって所有されてGroupいる場合、は所有していませんUser。逆も同様です。一度に1人の所有者のみ。 (4)グループ、ユーザー、プレイリストを一意に識別するために使用されるプロパティは何ですか? それぞれに代理主キー(id)と自然キー(主ではない)があります。これらはslug、GroupおよびPlaylist、およびにusername対応していUserます。 (5)特定のプレイリストで所有者が変更される可能性はありますか? 私はこれが機能であることを計画していませんが(少なくとも最初は)、これは仮説的に発生する可能性があります。 (6)Group.SlugおよびPlaylist.Slug属性の意味は何ですか?それらの値は、主キーとして定義されるのに十分安定していますか、それとも頻繁に変更されますか?これら2つのプロパティの値は、User.Usernameとともに一意である必要がありますか? これらslugのは、固有の小文字のハイフン付きのバージョンであり、それぞれのエンティティのtitleです。たとえばgroup、title「テストグループ」を含むa は「テストグループ」を持ちslugます。重複には増分整数が追加されます。これは彼らのtitle変化がいつでも変わるでしょう。私はそれが彼らが素晴らしい主キーを作成しないことを意味すると思いますか?はい、slugsそしてusernames、それぞれのテーブルにユニークです。

2
テキストと画像からvarchar(max)とvarbinary(max)への移行
いくつかのimageおよびtext列を含むSQL Serverデータベースがあり、それらを非推奨でない対応するvarbinary(max)とに移行することから発生する可能性のある潜在的な問題を調査していますvarchar(max)。 アプリケーションコードの変更は別として、私の主な関心事は、これに関連する潜在的な「問題」です。たとえば、古いデータ型ではサポートされているが、新しいデータ型ではサポートされていない機能はありますか? 新しい型は少なくとも古い型と同じくらい大きいので、切り捨てによるデータの損失は少なくとも問題にはならないようです。

2
列数の多い単一のテーブルと列数の少ない複数のテーブル
ソーシャルネットワークのウェブサイトに適したデータベース設計は何でしょうか?列が多く行が少ない単一のテーブル、または列は少ないが行が多い複数のテーブル? 例:ユーザーは自分の壁またはグループに更新を投稿できます。 私が考えることができる2つのデータベース設計は次のとおりです。 デザイン1 UserPosts id ユーザーID 役職 日付時刻 UserGroupPost: id groupId ユーザーID 役職 日付時刻 潜在的な問題:結合が必要になる可能性があり、(将来的には)クエリが遅くなる可能性があります。 デザイン2 投稿: id ユーザーID groupId 役職 datetime(ユーザーが壁に投稿した場合、groupidはnullになります) 潜在的な問題:大きなデータセットをループすると、(長い)時間がかかる場合があります。 データが増加した場合、どのようにしてパフォーマンスを向上させることができますか?他に(より良い)方法はありますか?

2
基本設計、初回データベース設計に関するアドバイス
私はJava開発者になるためのコースを取っています。 コースにはデータベースの使用が含まれますが、残念ながら実際に設計することはありません。 ほとんどの場合、事前に作成されたデータベースを取得し、データを挿入、更新、読み取り、または削除するためのコードを実装する必要があります。 しかし、私の最終テストが来るとき、私はデータベースを含む何かを作ることになる可能性が高いので、良いデータベース設計は多くの違いを生むことに気付いたので、設計のこつを得るためにいくつかの小さいものを設計してみたいと思います使用するコードを記述します。 これらの種類の質問がここで許可されていて、広すぎないことを願っています。 これは私が何かのように簡単なために作られた小さなデザインであるclubsとmembersしてaddressesとphonenumbers。 複数のクラブがあります。 各クラブには複数のメンバーがいます(自明) 会員は複数のクラブに所属することはできません メンバーは複数の電話番号とメールアドレスを持つことができます メンバーは1つのアドレスしか持てません アドレスは異なるメンバー(カップルまたは兄弟)に属することができます 私の最大の混乱: Club所有者を説明する列を追加したい場合、誰がメンバーにもなりますが、同じメンバーを2回リストしない場合の最善の方法は何ですか? すべてのテーブルをIDの自動インクリメントに配置する必要がありますか、それとも悪い考えですか?(メリット/デメリット?) [外部キー]タブで外部キーを追加すると、これらは自動的に正しいテーブルに対応しますか、それとも列に追加する必要がありますか?(写真2を参照) そして、すべての私はおそらくnoobiest質問...ドゥ私はの外部キー置くphonenumberとemailPERSON_IDにリンクし、それぞれのテーブル内のか、私は人のテーブルににphoneNumberやメール同上のを置く必要がありますか? (写真の言語が英語ではないことをお詫びします。これがそれほど問題にならないことを願っています)

4
重複する候補キーとは正確には何ですか?
簡単に説明できる人がいoverlapping candidate keyますか?何でoverlapping名前が示すように? 以下の関係を検討してください R(L,M,N,O,P) { M -> O NO -> P P -> L L -> MN } 上記の機能の依存関係のどれが上記の関係で重複する候補キーをもたらしていますか? ディスカッションを依存関係に制限しましょう。現時点ではBCNFには興味がありません。

1
複数の親を持つ有向グラフを表す方法は?
http://dirtsimple.org/2010/11/simplest-way-to-do-tree-based-queries.htmlは、クロージャーテーブルの挿入と削除のアルゴリズムを提供します。 ノードに複数の親がある場合を除いて、同様のデータ構造をモデル化したいと思います。 与えられた: 削除する[B, C]と、次のようになると予想します。 ノードを削除すると、次のようになりますB。 ただし、リンクまたはノードを削除するために作成者のアルゴリズムを使用すると、[D, C, 1]削除のタグが付けられることに気付くでしょう。これは望ましくありません。 これまでに試したこと references2つのノード間を移動する方法がいくつあるかを示す列を追加することにより、元のデータ構造を適応させてみました。上記の例では、からAまでC、Bまたはを経由して移動できますD。B削除されると、AtoへのパスCが保持され、参照カウントが2から1に減少すると考えられていました。理論的には良かったのですが、実装を機能させる方法を理解できなかったので、それはまったく可能です(データ構造には、削除する行を特定するのに十分な情報が含まれていない可能性があります)。 私が求めていること 複数の親をサポートするために、クロージャテーブルをどのように調整しますか?どの代替データ構造をお勧めしますか?https://stackoverflow.com/q/4048151/14731には、そのようなデータ構造の説得力のあるリストが含まれていますが、複数の親をサポートしている(または最適な)構造は明確ではありません。

2
ファクトテーブルの粒度に関する私の理解は正しいですか?
私と私たちの会社の別のDBAは、ベンダーが開発したデータベース設計のレビューを担当しています。ベンダーは、設計の基礎としてキンボールを使用すると述べています。(注:私はキンボール対インモンなどの議論を探しているわけではありません)彼らは複数の事実と次元を持つマートを設計しました。 公平に言えば、当社は単一のマートを設計したことはありません。私たちは常にコンサルタントにやってもらいました。そして、私たちはクラスや何かに送られたことがありません。したがって、倉庫/マート/次元モデリングなどに関する私たちの知識は、私たちが持っているほとんどの経験、インターネットで見つけることができるもの、および自読に基づいています(私たちはInmonとKimballの本を持っており、それらを通り抜けようとしています) 。 ステージは私の知識レベルに設定されたので、デザインの課題に向かいます。 「請求損失統計」と呼ばれるファクトテーブルがあります(これは保険用です)。そして、彼らは請求の支払い(毎月のレベルまでロールアップ)と準備金(請求の銀行口座のようなもの)の両方をキャプチャしようとしています。彼らは、毎月の支払い額を確認したいと考えています(重要ではありません)。しかし、彼らは準備金の口座の現在の残高を見たいと思っています。 絵の例をあげます。 クレームの準備金として1000米ドルを設定したとしましょう。これは脇に置かれます(そのため、いくつかの点で銀行口座のように機能します) 2014年10月には、まだ何も支払いません。したがって、企業は10月末の支払いと準備残高を確認したいと考えています。 ----------------------------------------------- - MONTH_YEAR - PAYMENTS - RESERVE_BALANCE - ----------------------------------------------- - 102014 - 0.00 - 1000.00 - ----------------------------------------------- その後、11月がやってきます。100ドル、150ドル、75ドルの支払いを行います。彼らは、以下のように、それらの合計額と残高の準備金を確認したいと考えています。 ----------------------------------------------- - MONTH_YEAR - PAYMENTS - RESERVE_BALANCE - ----------------------------------------------- - 102014 - 0.00 - 1000.00 - ----------------------------------------------- - 112014 - 325.00 - 675.00 - …

3
同じ制約とインデックスで新しいテーブルを作成するにはどうすればよいですか?
主キー制約とそのテーブルに非クラスター化インデックスを含む新しいテーブルを作成しています。 キーとインデックスだけでなく、同じ構造と値を持つ別のテーブルを作成したいのですが。 create table Dummy (id integer ,name varchar(20),salary integer Constraint PK_Con_id primary key(id)) insert into Dummy values(11,'AAA',1000); insert into Dummy values(12,'BBB',2000); insert into Dummy values(13,'CCC',3000); insert into Dummy values(14,'DDD',4000); select * from Dummy; create nonclustered index IX_Name on Dummy(Name) 現在、Dmyテーブルを作成していますがDmy、SQL Server 2008 R2のキーと制約がテーブルに反映されません。 SELECT * INTO Dmy FROM Dummy

1
三元関係:単一のテーブルを持つことと複数のテーブルを持つことの違いは何ですか?
次の3項関係を考えます。 すべてのエンティティに2つの属性(PKと名前)しかないと仮定します。 ここに私が導き出した表があります(5つの表): Sector ------------------------- ID_Sector SectorName ------------------------- Product ------------------------- ID_Product ProductName ------------------------- Company -------------------------------------- ID_Company ID_Sector CompanyName -------------------------------------- Relationship 1 (R1) ------------------------- ID_Sector ID_Product ------------------------- Relationship 2 (R2) ------------------------- ID_Company ID_Product ------------------------- 質問: その三者関係の良い解決策ですか?次の単一のテーブルの代わりに2つのテーブル(R1とR2)を持つことの違いは何ですか? Ternary table ------------------------------------- ID_Sector ID_Company ID_Product ------------------------------------- 私には、各リレーションシップ(R1とR2)に2つの別々のテーブルがある方が、1つのテーブルを持つよりも良い解決策のように見えますが、それが実際に当てはまるのか、それが良い方法なのかはわかりません。

2
このデータに最適なリレーショナルデータベース構造
次のシナリオのデータベーススキームを作成しています。 ユーザーがいます ユーザーには役割があります(「開発者」や「CEO」など) ロールにはアプリケーションがあります(「Topdesk」など) アプリケーションには権限があります(「ナレッジベースの更新」など) ロールがアプリケーションへのアクセス権をすでに持っている場合、ロールは権限を持つことができます 高性能環境がない(速度を最適化する必要がない)と仮定すると、このスキーマを実装する最良の方法は何でしょうか?データベース環境には、MySQL、MSSQLを使用できます。リレーショナルデータベースの設計が重要です。 私自身は次のことを考え出しました: もちろん、最も不確かな部分は、Applications_Permissions_Rolesテーブルです。これは、リンクテーブルですの上に別のリンクテーブル。これまで使用したことも、見たこともありません。それを行う別の方法は、それを役割と権限の間のリンクテーブルで置き換え、次にコードまたは制約を使用して必要な関係を確認することです...しかし、それは私にとって良い解決策のようではありません。これらのことは、コードレベルではなく、可能な限り(可能であると思われる場合)データベースレベルで実施する必要があります。 次に、Permissions.ApplicationとApplications.Idの間のリンクが必要ですか?Roles_Applicationsに行がない可能性があるため(新しいアプリケーションを追加した直後など)、どの権限がどのアプリケーションに属しているかを判別することができないため、これを使用します。また、権限が属するアプリケーションを検索するための単一の参照ポイントでもあります。これは正しいと思いますが、それはまた、データベース設計において円を描くものです。ON_DELETEまたはON_UPDATEをカスケードに設定しようとすると、MSSQLエラーが発生します。 何か提案、またはこれはどのように行われることになっていますか?命名規則などに関するその他の提案も(おそらくコメントとして)歓迎されます。 ありがとう、 Luc 編集:タイトルを変更しました。以前のものはより包括的でしたが、おそらく複雑すぎます。

4
データベース設計-共有タグ付きのさまざまなオブジェクト
私の経歴は、データベース管理ではなく、Webプログラミングに詳しいので、ここで間違った用語を使用している場合は訂正してください。コーディングするアプリケーションのデータベースを設計する最良の方法を見つけようとしています。 状況:レポートが1つの表にあり、推奨事項が別の表にあります。各レポートには多くの推奨事項があります。キーワード用の別のテーブルもあります(タグ付けを実装するため)。ただし、キーワードを検索すると結果としてレポートと推奨事項が表示されるように、レポートと推奨事項の両方に適用されるキーワードのセットを1つだけ用意したいと思います。 これが私が始めた構造です: Reports ---------- ReportID ReportName Recommendations ---------- RecommendationID RecommendationName ReportID (foreign key) Keywords ---------- KeywordID KeywordName ObjectKeywords ---------- KeywordID (foreign key) ReportID (foreign key) RecommendationID (foreign key) 本能的には、これは最適ではないようで、タグ付け可能なオブジェクトを共通の親から継承し、そのコメントの親にタグを付けると、次のような構造になります。 BaseObjects ---------- ObjectID (primary key) ObjectType Reports ---------- ObjectID_Report (foreign key) ReportName Recommendations ---------- ObjectID_Recommendation (foreign key) RecommendationName ObjectID_Report (foreign …

3
適切な多言語スキーマ、またはやりすぎですか?
UPDATE 2:私は実際にこれを使用してしまいましたが、2、3の調整後は素晴らしいです。実際のデザインと実際の動作に関する私の投稿は次のとおりです。http://tim.hithlonde.com/2013/lemon-schema-works/ 私はWebアプリを作成していますが、複数の言語をサポートしたいと考えています。この構造には2つのコンポーネントがあります。 ロケール( 'english'、 'Deutch'など)と用語を関連付け、ロゼッタストーンの接続用語と特定の言語の用語を使用します。 ページごとに用語をグループ化します。私は言いたくない、私がページで必要とするかもしれない30以上の用語を通して、term1、term2などを選択します。彼らが接続しているページで尋ねたいのですが。 これが私の提案するテーブル構造です(すべてのIDには非常に効率的なクエリを作成するために、ID間に関係/インデックスがあることに注意してください)。 * locale * id * value //English, Deutch, etc// * terms * id * value //In English// * page * id * value //Think add entry, menu// * page_group //group all terms to a page, for easy pulling// * id * page.id …


2
1つのテーブルに2つの自動インクリメンタル列を設定するにはどうすればよいですか?
会社の請求書に関する情報を含むMySQLテーブルがあります。ただし、この会社には2つの支店があり、それぞれに固有の請求シーケンスがあります。いわば「セリエA」と「セリエB」。ただし、これは1つの会社であり、2つの請求書テーブルを作成したくありません。むしろ、1つのテーブルに2つの異なる自動インクリメントを設定したいのです。これは技術的に不可能であることはわかっていますが、これは他の人が以前に取り組んだ問題だと思うので、この問題の既知の「解決策」があるかどうか知りたいですか? 私が今行っているのは、請求書番号としてプライマリキーを使用すること(これは理想的です)ではなく、手動でインクリメントされる請求書IDを持つセカンダリ列を使用することです(まあ、PHPスクリプトを使用しますが、それでも自動ではありません) )、その特定のシリーズの最新の請求書を確認する。 これは私の現在の設定です: CREATE TABLE `invoices` ( `id` mediumint unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY, `invoicenumber` mediumint unsigned NOT NULL, `branch` enum('A','B') NOT NULL, `date` date NOT NULL, `client` varchar(100) NOT NULL ) COMMENT='' ENGINE='InnoDB'; 最新の請求書を確認するには、次のコマンドを実行します。 SELECT MAX(invoicenumber+1) AS new_invoice_number FROM invoices WHERE branch = 'A'

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