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

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 この質問を改善する 列が1つだけのテーブルがあってもよろしいですか？技術的に違法ではないことは知っていますが、デザインが悪いと考えられますか？ 編集： 以下にいくつかの例を示します。 50の有効な米国の州コードを持つテーブルがありますが、詳細な州名を格納する必要はありません。 メールのブラックリスト。 キーフィールドの追加について誰かが言及しました。私の見たところ、この単一の列が主キーになります。

111 sql  database-design 

かなり大きなOracleデータベースを使用するプロジェクトで作業しています（私の質問は他のデータベースにも同様に当てはまります）。私たちは、ユーザーがフィールドのほとんどすべての可能な組み合わせで検索できるWebインターフェースを持っています。 これらの検索を高速化するために、ユーザーがよく検索すると思われるフィールドおよびフィールドの組み合わせにインデックスを追加します。ただし、お客様がこのソフトウェアをどのように使用するかは実際にはわからないため、どのインデックスを作成するかを判断するのは困難です。 スペースは問題ではありません。4テラバイトのRAIDドライブがあり、そのごく一部しか使用していません。ただし、インデックスが多すぎるとパフォーマンスが低下する可能性があるのではないかと心配しています。行が追加、削除、または変更されるたびにこれらのインデックスを更新する必要があるため、1つのテーブルに数十のインデックスを作成するのは悪い考えだと思います。 それでは、いくつのインデックスが多すぎると考えられますか？10？25？50？それとも、本当に一般的で明白なケースをカバーし、それ以外はすべて無視するべきでしょうか？

109 database  oracle  database-design 

この例はw3schoolsからの引用です。 CREATE TABLE Persons ( P_Id int NOT NULL, LastName varchar(255) NOT NULL, FirstName varchar(255), Address varchar(255), City varchar(255), CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName) ) 私の理解では、両方の列（P_IdおよびLastName）は一緒にテーブルの主キーを表しますPersons。これは正しいです？ なぜ誰かが単一の列ではなく複数の列を主キーとして使用したいのですか？ 特定のテーブルで主キーとして一緒に使用できる列の数はいくつですか？

109 database-design  relational-database  primary-key  ddl  database-table 

ビューを実際のテーブルで実際に使用する必要があるのはいつですか？これによりどのような利益が期待できますか？ 全体として、テーブルよりもビューを使用する利点は何ですか？そもそもビューがどう見えるかでテーブルをデザインすべきではないでしょうか？

108 sql  database-design  view 

RDBMSに住所を保存するためのベストプラクティスに関する適切なリファレンスはありますか？評価できるトレードオフはたくさんあり、それぞれの長所と短所がたくさんあるようです-確かにこれは何度も何度も行われていますか？たぶん誰かが少なくともどこかで学んだいくつかのレッスンを書いたことがありますか？ 私が話しているトレードオフの例は、郵便番号を整数フィールドと文字フィールドとして格納すること、家番号を別のフィールドまたは住所行1の一部として格納する場合、スイート/アパートメント/その他の番号を正規化するか、または単に住所行2のテキストのチャンク。zip+4（個別のフィールドまたは1つの大きなフィールド、整数とテキスト）をどのように処理しますか？等 この時点では主に米国の住所に関心がありますが、グローバルになる可能性に備えていくつかのベストプラクティスがあると思います（たとえば、州ではなく地域や郵便番号ではなく郵便番号などのフィールドに適切な名前を付ける）等

106 database  database-design  types  street-address  postal-code 

なぜデータベース関係者は正規化を続けるのですか？ それは何ですか？それはどのように役立ちますか？ データベース以外にも適用されますか？

104 database-design  database-normalization  relational 

DWを設計し、具体化されたビューについて聞いた。実際にビューを作成したいのですが、ベーステーブルが変更されると自動的に更新されます。誰でもクエリの例で説明できますか？

101 sql-server  database-design  indexed-views 

時間をデータベーステーブルに格納したいが、時間と分のみを格納する必要がある。DATETIMEだけを使用して日付の他のコンポーネントを無視できることはわかっていますが、実際に必要な情報よりも多くの情報を保存せずにこれを行うための最良の方法は何ですか？

100 sql-server  database  database-design  datetime 

ユーザーが読んだ記事を追跡する機能を実装しています。 create_table "article", :force => true do |t| t.string "title" t.text "content" end これがこれまでの私の移行です： create_table :user_views do |t| t.integer :user_id t.integer :article_id end user_viewsテーブルは、常に1つだけではなく、両方の列を検索するために照会されます。私の質問は私のインデックスがどのように見えるべきかです。これらのテーブルにいくつかのオプションがある場合、これらのテーブルの順序に違いはありますか？私のターゲットDBはPostgresです。 add_index(:user_views, [:article_id, :user_id]) ありがとう。 更新： 両方の列に同じ値を含む行は1つしか存在できないため（user_idがarticle_idを読み取ったかどうかを知るため）、: uniqueオプションを検討する必要がありますか？私が誤解していないのであれば、それは自分でチェックする必要がなく、ユーザーが記事にアクセスするたびに挿入するだけです。

97 ruby-on-rails  ruby-on-rails-3  database-design  indexing 

「インデックスとは何ですか？インデックスを使用してデータベースのクエリを最適化するにはどうすればよいですか？」のフォローアップとして、インデックスについて学習しようとしているところ、どのカラムがインデックス候補として適していますか？特にMS SQLデータベースについては？ いくつかのグーグルの後、私が読んだすべては、一般的に増加し、一意である列が良いインデックスを作成することを示唆しています（MySQLのauto_incrementのようなもの）、私はこれを理解していますが、MS SQLを使用しており、主キーにGUIDを使用しているため、そのインデックスはGUID列にはメリットがありません...

97 sql-server  database  optimization  database-design  indexing 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して質問を更新し、事実と引用で回答できるようにします。 4年前休業。 この質問を改善する 私たちの開発グループでは、主キーと外部キーの命名規則に関して激しい議論があります。私たちのグループには、基本的に2つの考え方があります。 1： Primary Table (Employee) Primary Key is called ID Foreign table (Event) Foreign key is called EmployeeID または 2： Primary Table (Employee) Primary Key is called EmployeeID Foreign table (Event) Foreign key is called EmployeeID 私は、どの列でもテーブルの名前を複製しないことを好みます（したがって、上記のオプション1を好みます）。概念的には、プロパティ名にオブジェクトの名前を使用しない他の言語で推奨されている多くの慣習と一致しています。私は、外部キーに名前を付けるとEmployeeID（またはそれEmployee_IDよりも良いかもしれません）、それが表のID列であることを読者に伝えると思いますEmployee。 列名がデータベース全体で同じになるように、テーブル名を前に付けた主キーに名前を付けるオプション2を好む人もいます。その点はわかりましたが、主キーと外部キーを視覚的に区別することはできなくなりました。 また、私はそれはあなたがエンティティとそのエンティティのプロパティまたは属性として列としてテーブルを考えるならば、あなたはのID属性と考えるので、列名にテーブル名を持つように冗長だと思うEmployee、ありませんEmployeeID従業員の属性。私は同僚に何を言っているのPersonAgeか尋ねませんPersonGender。私は彼に彼の年齢は何であるか尋ねます。 だから私が言ったように、それは激しい議論であり、私たちはそれについて何度も何度も繰り返します。私はいくつかの新しい視点を得ることに興味があります。

95 sql  database-design  naming-conventions 

タイトルは一目瞭然だと思います。多対多の関係を作成するには、PostgreSQLでテーブル構造をどのように作成しますか。 私の例： Product(name, price); Bill(name, date, Products);

95 sql  database  postgresql  database-design  many-to-many 

以下は、EMAIL_ADDRESS列のデータ型とプロパティを反映した、クエリの抽出部分です。 EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, ただし、John Saundersはを使用していVARYING(256)ます。 これは、必ずしもVARYINGを正しく理解しているわけではないことを示唆しています。 私の場合、メールアドレスの長さは20文字、Jodnの長さは256文字であると理解しています。 ジョンのコードのコンテキスト CREATE TABLE so."User" ( USER_ID SERIAL NOT NULL, USER_NAME CHARACTER VARYING(50) NOT NULL, EMAIL_ADDRESS CHARACTER VARYING(256) NOT NULL, // Here HASHED_PASSWORD so.HashedPassword NOT NULL, OPEN_ID CHARACTER VARYING(512), A_MODERATOR BOOLEAN, LOGGED_IN BOOLEAN, HAS_BEEN_SENT_A_MODERATOR_MESSAGE BOOLEAN, CONSTRAINT User_PK PRIMARY KEY(USER_ID) ); 普通の人が使う20文字以上のメールアドレスは見たことがありません。 …

93 database  performance  email  database-design 

そのnoobの質問で申し訳ありませんが、データベース内のテーブルと1対1の関係を使用する必要がありますか？1つのテーブル内に必要なすべてのフィールドを実装できます。データが非常に大きくなった場合でも、SELECTを使用する代わりに、ステートメントで必要な列名を列挙できますSELECT *。この分離が本当に必要なのはいつですか。

92 database  database-design  relational-database 

PostgreSQL 9.0を使用して、「スタッフ」というグループの役割を持っています。特定のスキーマのテーブルで、この役割にすべての（または特定の）特権を付与したいと考えています。次の作業はありません GRANT ALL ON SCHEMA foo TO staff; GRANT ALL ON DATABASE mydb TO staff; 「スタッフ」のメンバーは、まだデータベース内の任意のテーブルに（2番目のコマンドの場合）、スキーマ「foo」というか、個々のテーブルで選択することができない、またはUPDATEある場合を除き、私はその特定のテーブルの上にすべてを付与します。 自分とユーザーの生活を楽にするために何ができますか？ 更新： serverfault.comでの同様の質問の助けを借りて、それを理解しました。 GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;

91 postgresql  database-design  roles  privileges  grant