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

データベースの設計とは、データベースの構造、つまりデータベースの論理的な側面を指定するプロセスです。データベース設計の目標は、データベースがモデル化しようとしている事実の種類、ビジネスルール、およびその他の要件である「談話の世界」を表現することです。

5
リレーショナルテーブルの命名規則
私は新しいプロジェクトを始めており、最初からテーブル名と列名を取得したいと考えています。たとえば、私は常にテーブル名に複数を使用してきましたが、最近学んだ単数は正しいです。 したがって、「user」というテーブルを取得して、そのユーザーだけが持つ製品を取得した場合、テーブルの名前を「user_product」または単に「product」にする必要がありますか?これは1対多の関係です。 さらに、(何らかの理由で)各製品について複数の製品の説明がある場合、それは「user_product_description」または「product_description」または単に「説明」でしょうか?もちろん、適切な外部キーが設定されている場合。ユーザーの説明やアカウントの説明などがあるため、説明に名前を付けるだけでも問題があります。 列が2つだけの純粋なリレーショナルテーブル(多対多)が必要な場合はどうなりますか?「user_stuff」または「rel_user_stuff」のようなものですか?そして、最初の場合、たとえば「user_product」とこれをどのように区別しますか? どんな助けも高く評価されます。皆さんがお勧めする命名規則の標準がある場合は、自由にリンクしてください。 ありがとう

7
ツリーデータ構造のデータベース構造
データベースにカスタマイズ可能な(レベル数が不明なツリー構造)ツリーデータ構造を実装する最良の方法は何でしょうか。 自分自身への外部キーを持つテーブルを使用する前に、これを1回実行しました。 他にどのような実装を見ることができますか?この実装は意味がありますか?

5
監査ログのデータベース設計
新しいデータベースを設計する必要があるたびに、変更の監査ログを保持するためにデータベーススキーマをどのように設定するかについてかなりの時間を費やしています。 これについてはすでにいくつかの質問がここで行われていますが、すべてのシナリオに単一の最良のアプローチがあることに同意しません。 改訂のためのデータベース設計 変更ログ監査データベーステーブルの最適な設計 監査証跡をキャプチャするためのデータベース設計に関するアイデア また、データベースの変更のログを管理するという興味深い記事に出会い、各アプローチの長所と短所をリストアップしようとしました。それは非常によく書かれていて興味深い情報がありますが、それは私の決定をさらに難しくしました。 私の質問は、私が使用できる参照、おそらく本や決定木のようなものであり、いくつかの入力変数に基づいてどの方向に進むべきかを決定するために参照できますか? データベーススキーマの成熟度 ログのクエリ方法 レコードを再作成する必要がある確率 さらに重要なこと:書き込みまたは読み取りのパフォーマンス ログに記録される値の性質(文字列、数値、ブロブ) 利用可能な収納スペース 私が知っているアプローチは次のとおりです。 1.作成および変更された日付とユーザーの列を追加する テーブルの例: id value_1 値_2 value_3 作成日 modified_date によって作成された 変更された 主な短所:変更の履歴が失われます。コミット後にロールバックできません。 2.テーブルのみを挿入する 表の例: id value_1 値_2 value_3 から に 削除(ブール) ユーザー 主な短所:外部キーを最新に保つ方法は?巨大なスペースが必要 3.テーブルごとに個別の履歴テーブルを作成する 履歴テーブルの例: id value_1 値_2 value_3 value_4 ユーザー 削除(ブール) タイムスタンプ 主な短所:すべての監査済みテーブルを複製する必要があります。スキーマが変更された場合、すべてのログを移行するためにも必要になります。 4.すべてのテーブルの統合履歴テーブルを作成する 履歴テーブルの例: table_name …

15
いつ/なぜSQL Serverでカスケードを使用するのですか?
SQL Serverで外部キーを設定する場合、どのような状況で削除または更新時にカスケードする必要がありますか?その背後にある理由は何ですか? これはおそらく他のデータベースにも当てはまります。 私は、各シナリオの具体的な例として、できればそれらをうまく使用した人からの検索をしています。

6
複合主キーのnull許容列の何が問題になっていますか?
ORACLEでは、主キーを構成する列にNULL値を使用できません。同じことが他のほとんどの「エンタープライズレベル」のシステムにも当てはまるようです。 同時に、ほとんどのシステムでは、null許容列に一意の制約も許可されています。 一意制約にNULLを設定できるのに、主キーには設定できないのはなぜですか?これには根本的な論理的な理由がありますか、それともこれは技術的な制限ですか?

5
PostgreSQL:それぞれ1つのスキーマを持つ複数のデータベース、または複数のスキーマを持つ1つのデータベースを使用する方が良いですか?
私の質問の1つに対するこのコメントの後、Xスキーマを備えた1つのデータベースを使用する方が良いのか、またはその逆なのかを考えています。 私の状況:登録時にデータベースを(実際には)作成するWebアプリケーションを開発しています(いいえ、それはソーシャルネットワークではありません:誰もが自分のデータにアクセスできなければならず、他のユーザーのデータを見ることはありません)。 。 これが、以前のバージョンのアプリケーション(まだMySQLで実行されている)で使用した方法です。PleskAPIを使用して、すべての登録に対して、次のことを行います。 制限付きの権限を持つデータベースユーザーを作成します。 前に作成したユーザーとスーパーユーザーだけがアクセスできるデータベースを作成します(メンテナンス用) データベースに入力する 今、私はPostgreSQLでも同じことをする必要があります(プロジェクトは成熟し、MySQLになっています...すべてのニーズを満たすわけではありません)。 すべてのデータベース/スキーマのバックアップを独立させる必要があります。pg_dumpは両方の方法で完全に機能し、1つのスキーマまたは1つのデータベースのみにアクセスするように構成できるユーザーにとっても同じです。 それで、あなたが私よりも経験豊富なPostgreSQLユーザーであると仮定すると、私の状況に最適なソリューションは何だと思いますか、そしてその理由は? $ xスキーマの代わりに$ xデータベースを使用するとパフォーマンスに違いがありますか?そして、どのソリューションが将来的に維持する方が良いでしょう(信頼性)? すべてのデータベース/スキーマは常に同じ構造になります! バックアップの問題(pg_dumpを使用)の場合、1つのデータベースと多くのスキーマを使用して、すべてのスキーマを一度にダンプする方が良いでしょう。回復は、開発マシンにメインダンプをロードして、必要なスキーマだけをダンプして復元することで非常に簡単です。これは1つの追加ステップですが、すべてのスキーマをダンプすると、1つずつダンプするよりも高速に見えます。 アップデート2012 さて、この2年間で、アプリケーションの構造とデザインは大きく変化しました。私はまだこのone db with many schemasアプローチを使用していますが、アプリケーションのバージョンごとに 1つのデータベースがあります。 Db myapp_01 \_ my_customer_foo_schema \_ my_customer_bar_schema Db myapp_02 \_ my_customer_foo_schema \_ my_customer_bar_schema バックアップについては、各データベースを定期的にダンプし、バックアップを開発サーバーに移動しています。 私はPITR / WALバックアップも使用していますが、前に述べたように、すべてのデータベースを一度に復元する必要はほとんどないので、おそらく今年は却下されます(私の状況では最善のアプローチではありません) )。 アプリケーションの構造が完全に変更されていても、one-db-many-schemaアプローチは今から非常にうまく機能しました。 私はほとんど忘れてしまいました:すべてのデータベース/スキーマは常に同じ構造になります! ...すべてのスキーマには、ユーザーのデータフローに応じて動的に変化する独自の構造があります。

7
データベースにコメントといいね!を実装する
私はソフトウェア開発者です。私はコードを愛して、私は現在、私のように、ユーザがエンティティをマークするために許可されるには、ウェブサイト作成しています...データベースを嫌い言っています(FBでのように)、タグ、それをしてコメントを。 この機能を処理するためのデータベーステーブルの設計に行き詰まっています。1つのタイプ(写真など)に対してのみこれを実行できる場合、解決策は簡単です。しかし、私はこれを5つの異なるものに対して有効にする必要があります(現時点では、サービス全体が成長するにつれて、この数が増える可能性があることも想定しています)。 ここで似たような質問をいくつか見つけましたが、どれも満足のいく答えはありません。そのため、もう一度この質問をします。 質問は適切、方法、である効率的かつ弾力それが異なるため、コメント保存することができるように、データベースを設計テーブルを、好き異なるため、テーブルやタグ彼らのために。回答としてのいくつかのデザインパターンが最良です;) 詳細な説明:私はテーブル User一部のユーザーデータ、および3つの以上とテーブルを:Photoで撮影、Articlesとの記事、Placesと場所。ログインしたユーザーが次のことをできるようにしたい: これら3つのテーブルのいずれかにコメントする それらのいずれかを好きとしてマーク それらのいずれかにいくつかのタグを付けます また、すべての要素のいいねの数と、特定のタグが使用された回数をカウントしたいと思います。 1 回目のアプローチ: a)のためのタグ、私が作成するテーブルを Tag [TagId, tagName, tagCounter]、そして私が作成する多対多の関係のテーブルをするために:Photo_has_tags、Place_has_tag、Article_has_tag。 b)コメントも同じです。 C)私が作成するテーブルを LikedPhotos [idUser, idPhoto]、LikedArticles[idUser, idArticle]、LikedPlace [idUser, idPlace]。多くの同類をして算出されたクエリ(私が悪いと仮定し、)。そして... 私は最後の部分のこのデザインが本当に好きではありません、それは私にとってひどいにおいがします;) 2 番目のアプローチ: 私は、テーブルが作成されますElementType [idType, TypeName == some table name]の名前を持つ管理者(私)によって移入されたテーブルすることができます言っています、コメントやタグ付けを。次に、テーブルを作成します。 a)LikedElement [idLike, idUser, idElementType, idLikedElement]それぞれに適切な列があるコメントとタグについても同じです。今、私は写真を好きにしたいときに挿入します: typeId = SELECT id FROM ElementType WHERE TypeName == 'Photo' …

12
SQL Serverデータベースで単一行構成テーブルを使用する。悪いアイデア?
ショッピングカートアプリケーションを開発する際に、管理者の好みと要件に基づいて設定と構成を保存する必要があることがわかりました。この情報には、会社情報、配送アカウントID、PayPal APIキー、通知設定などが含まれます。 リレーショナルデータベースシステムで単一の行を格納するテーブルを作成することは非常に不適切と思われます。 この情報を保存する適切な方法は何ですか? 注:私のDBMSはSQL Server 2008で、プログラミングレイヤーはASP.NET(C#)で実装されています。

14
ユーザー定義フィールドのデータベースを設計する方法は?
私の要件は: 任意のデータ型のユーザー定義フィールドを動的に追加できる必要がある UDFをすばやく照会できる必要がある データ型に基づいてUDFの計算を実行できる必要がある データ型に基づいてUDFをソートできる必要がある その他の情報: 主にパフォーマンスを探しています UDFデータを添付できる数百万のマスターレコードがあります。 私が最後に確認したとき、現在のデータベースには50mil以上のUDFレコードがありました ほとんどの場合、UDFはすべてではなく数千のマスターレコードにのみ添付されます。 UDFは結合されないか、キーとして使用されません。これらはクエリやレポートに使用される単なるデータです オプション: StringValue1、StringValue2 ... IntValue1、IntValue2、...などで大きなテーブルを作成します。私はこのアイデアは嫌いですが、他のアイデアよりも優れていると誰かが教えてくれればそれを考慮します。 必要に応じてオンデマンドで新しい列を追加する動的テーブルを作成します。また、すべての列にインデックスを付けないとパフォーマンスが低下するので、このアイデアは好きではありません。 UDFName、UDFDataType、およびValueを含む単一のテーブルを作成します。新しいUDFが追加されたら、そのデータだけをプルして指定されたタイプに解析するビューを生成します。解析基準を満たさないアイテムはNULLを返します。 データ型ごとに1つずつ、複数のUDFテーブルを作成します。したがって、UDFStrings、UDFDatesなどのテーブルがあります。おそらく、#2と同じように実行され、新しいフィールドが追加されるたびにビューを自動生成します。 XMLデータ型?私はこれまでこれらを扱ったことがありませんが、言及されているのを見ました。特にパフォーマンスに関して、期待どおりの結果が得られるかどうかはわかりません。 他に何か?

4
各製品に多くのパラメーターがある多くの種類の製品の製品テーブルを設計する方法
私はテーブルデザインの経験があまりありません。私の目標は、以下の要件を満たす1つ以上の製品テーブルを作成することです。 多くの種類の製品(TV、電話、PCなど)をサポートします。製品の種類ごとに、次のような異なるパラメータセットがあります。 電話には、色、サイズ、重量、OSがあります... PCにはCPU、HDD、RAMが搭載されています... パラメータのセットは動的である必要があります。任意のパラメーターを追加または編集できます。 製品の種類ごとに個別の表がなくても、これらの要件を満たすにはどうすればよいですか?

8
タグをデータベースに保存する最も効率的な方法は何ですか?
私のウェブサイトに、stackoverflowで使用するのと同じようにタグ付けシステムを実装しています。私の質問は、タグを保存して検索およびフィルタリングできるようにする最も効果的な方法は何ですか? 私の考えはこれです: Table: Items Columns: Item_ID, Title, Content Table: Tags Columns: Title, Item_ID これは遅すぎるのですか?もっと良い方法はありますか?

20
データベーススキーマを視覚化するための良いツールですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。事実、参考文献、専門知識によって回答が裏付けられることを期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問が改善され、場合によっては再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 既存のデータベーススキーマを視覚化するための優れたツールはありますか?必要に応じて、MySQLを使用しています。 私は現在、MySQL Workbenchを使用してSQL作成スクリプトダンプを処理していますが、それは不格好で時間がかかり、手動ですべてのテーブルをドラッグします(それほど遅くなければ大丈夫です)。

24
2つのテーブルを一緒にマップするテーブルにはどのような名前を付ける必要がありますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 この質問を改善する 2つのテーブルがあるとします。 Table: Color Columns: Id, ColorName, ColorCode Table: Shape Columns: Id, ShapeName, VertexList 色を形にマップするテーブルを何と呼ぶべきですか? Table: ??? Columns: ColorId, ShapeId

13
Facebookデータベース設計?
私はFacebookがどのようにして友達<->ユーザー関係を設計したのかといつも疑問に思っていました。 ユーザーテーブルは次のようなものだと思います。 user_email PK user_id PK password ユーザーのデータ(性別、年齢など、私が想定するユーザーの電子メールを介して接続されている)を表に示します。 すべての友達をこのユーザーにどのように接続しますか? このようなもの? user_id friend_id_1 friend_id_2 friend_id_3 friend_id_N おそらく違います。ユーザー数は不明で拡大するため。

9
データベースの継承をどのように効果的にモデル化しますか?
データベースの継承をモデル化するためのベストプラクティスは何ですか? トレードオフとは何ですか(クエリ可能性など)? (私はSQL Serverと.NETに最も興味がありますが、他のプラットフォームがこの問題にどのように対処するかについても理解したいと思います。)

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