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

この段階では、可能な限り少ない仮定（Webアプリの実際の進化に関する）でデータベース設計を決定しようとしています。 JOINSが高価であることを理解するための最初のステップとして、多数の正規化された小さなテーブルではなく、少数のモノリシックテーブルを検討しています。2番目のポイントとして、hstoreと通常のテーブルとJSONB（GiSTインデックス付け）を使用することで混乱しています。 知っている（気軽に修正してください）： 一般に、Postgresでは、hstoreは他のデータ型よりもパフォーマンスが良いことが知られています。FOSDEM PGDAYからのこのプレゼンテーションには、いくつかの興味深い統計があります（スライドの後半）。 https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf hstoreの利点は、高速インデックス（GiNまたはGiST）です。ただし、JSONBでは、GiNおよびGiSTインデックス付けをJSONデータに適用することもできます。 第2象限の専門家によるこのブログは、「この時点で、おそらくすべての新しいアプリケーションでhstoreの使用をjsonbに置き換える価値がある」と述べています（最後までスクロール）：http ://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns / だから私は次のことを決定したいと思います： データの主要な（構造化された）部分の場合：いくつかのリレーショナルテーブル（多くの列を持つ比較的大きい）に入れるべきですか、それともhstoreを使用する多数のキー値ストアである必要がありますか？ アドホック（ユーザー提供/非構造化）データの場合、JSONまたはhstoreのアドホックキー値ストア（メインリレーショナルテーブルのいずれかにキーが格納されている）に格納する必要がありますか？

28 postgresql  database-design 

今日私はロバート・マーティンについて聞いただけで、彼はソフトウェアの世界で有名な人物のようですので、タイトルがクリックの餌のように見えたり、口に言葉を入れているように見えるわけではありませんが、これは単に限られた経験と理解で彼から聞いたことをどのように解釈したか。 本日（ソフトウェアアーキテクチャ）、ロバートC.マーティンの講演でビデオを見ていました。ビデオの後半では、データベースのトピックが主な焦点でした。 彼の発言を理解したところ、SSDはデータベースの有用性を（かなり）低下させると言っていたようです。 この解釈に至った経緯を説明するには： 彼は、HDD /スピニングディスクでは、データの取得が遅い方法について説明しました。しかし、最近ではSSDを使用している、と彼は指摘しました。「RAM is coming」で始まり、RAMディスクについて言及し続けますが、RAMディスクと呼ぶことはできないと言うので、RAMと言うことに頼ります。したがって、RAMでは、すべてのバイトが取得するのに同じ時間がかかるため、インデックスは必要ありません。（この段落は私によって言い換えられています） だから、彼はDBの代わりにRAMを（コンピューターのメモリのように）提案することは（それは私が彼の声明を解釈したものだから）意味をなさない。オンデマンドでディスクファイルからプルしない限り） だから、私はRAMで考えることに頼った、彼はSSDを意味します。したがって、その場合、彼はSSDがデータベースの有用性を低下させると言っています。彼は「私がオラクルだったら怖いだろう。私が存在する理由の根底にあるのは蒸発する」とさえ言う。 SSDについての私のわずかな理解から、O(n)シーク時間であるHDDとは異なり（私は思う）、SSDは近くO(1)、またはほぼランダムです。だから、彼の提案は私にとって興味深いものでした。数年前に私が初めてデータベースを紹介されたとき、教授が通常のファイルシステムに対する利点を説明していたとき、私はデータベースの主な役割は本質的に非常にインデックス付けされたファイルシステムであると結論付けました（最適化、キャッシュ、同時アクセス、など）、したがって、SSDでインデックスが必要ない場合、この種のデータベースの有用性は低下します。 それにもかかわらず、私が初心者であることを前にすると、純粋なファイルシステムではなくDBをアプリケーションの主要なポイントとして誰もが使用し、彼が単純化しすぎていると感じたため、それらがあまり有用ではなくなると信じることは難しいデータベースの役割。 注：彼が何か違うことを言わないように最後まで見ました。 参考までに、42：22はデータベーストピック全体が表示されるとき、43： 52は 「なぜデータベースがあるのか​​」で始まるときです。 この答えは、SSDがDBを大幅に高速化すると言っています。 この質問は、最適化がどのように変更されるかについて尋ねます。 TL; DR私の質問は、サーバ市場で広くSSDの使用の出現は（それは今後のだか、すでに起こっているかどうか）のデータベースの有用性を減らすのですか？ プレゼンターが伝えようとしていたのは、SSDを使用すると、データをディスクに保存でき、SSDのように古いHDDのようにデータを取得するのに時間がかかることを心配する必要がないということでしたO(1)（おもう）。そのため、それが真実である場合、それはそれが持っていた利点の1つを仮定的に失うでしょう：インデックス付け、より速いシーク時間のためのインデックスを持つ利点がなくなったので。

28 database-design  performance  index  hardware  ssd 

データベースを使用する際の一般的なニーズは、レコードに順番にアクセスすることです。たとえば、ブログがある場合、ブログの投稿を任意の順序に並べ替えることができます。これらのエントリには多くの場合、多くの関係があります。そのため、リレーショナルデータベースは理にかなっているようです。 私が見た一般的な解決策は、整数列を追加することですorder： CREATE TABLE AS your_table (id, title, sort_order) AS VALUES (0, 'Lorem ipsum', 3), (1, 'Dolor sit', 2), (2, 'Amet, consect', 0), (3, 'Elit fusce', 1); 次に、行を並べ替えorderて適切な順序で並べます。 しかし、これは不器用なようです： レコード0を先頭に移動する場合は、すべてのレコードを並べ替える必要があります 真ん中に新しいレコードを挿入したい場合は、その後のすべてのレコードを並べ替える必要があります レコードを削除する場合は、それ以降のすべてのレコードを並べ替える必要があります 次のような状況は簡単に想像できます。 2つのレコードは同じです order orderレコード間にギャップがあります これらは、いくつかの理由でかなり簡単に発生する可能性があります。 これは、Joomlaなどのアプリケーションがとるアプローチです。 ここでのインターフェイスは悪いと主張し、人間が直接数字を編集する代わりに、矢印またはドラッグアンドドロップを使用する必要があります。おそらく正しいでしょう。しかし、舞台裏では、同じことが起こっています。 一部の人々は、「2.5」を使用して順序2と3のレコードの間にレコードを挿入できるように、10進数を使用して順序を格納することを提案しています。そして、それは少し助けにはなりますが、奇妙な小数（どこで止まりますか？2.75？2.875？2.8125？） 注文をテーブルに保存するより良い方法はありますか？

28 database-design  relational-theory  order-by  database-agnostic 

テーブルパーティションの長所と短所の概念をつかむのが困難です。8つのテーブルを持つプロジェクトの作業を開始しようとしていますが、そのうちの1つは1億8千万から2億6千万件のレコードを保持するメインデータテーブルになります。適切にインデックスが付けられたテーブルになるので、9〜13個のテーブルを作成する必要があるこの方法で、テーブルレコードを2,000万に制限することを考えています。 しかし、同じマシン（32GB RAM）に座っているため、パフォーマンスがどのように改善されるかについてはよくわかりません。 私はMySQLを使用しており、テーブルはMyISAMであり、大きなテーブルにはidフィールドにインデックスがあり、フルテキスト検索などの複雑さはありません。 また、テーブルのパーティション分割とデータベースのパーティション分割についても明らかにしてください。

28 mysql  database-design  performance  partitioning  myisam 

多くの人がmanyいデータベースを扱っている/使っていると確信しています。まったく正規化されていないデータベース、最も些細なデータを取得するために大きな苦痛を伴うクエリを実行する必要があるデータベース、運用中のデータベース、少し変更することはできません... 、 "それです"。 私の質問は、どのように対処しますか？ 新しいデータベースを作成しようとしていますか？ あきらめて、放っておけますか？ どのようなアドバイスができますか？

26 database-design 

アプリケーションのテナントのインスタンスごとに個別のデータベースを持つ共通サーバーで適度な数の顧客（テナント）を処理するのは比較的簡単で、通常これを行う正しい方法です。現在、各テナントが独自のデータベースインスタンスを持つアプリケーションのアーキテクチャを検討しています。 ただし、問題は、このアプリケーションに多数のテナント（5,000〜10,000）があり、かなりの数のユーザー（おそらく単一のテナントでは2,000）があることです。毎週数人のテナントによるシステムの成長をサポートする必要があります。 さらに、すべてのテナントとそのユーザーに共通のログインプロセスが表示されます（つまり、各テナントが独自のURLを持つことはできません）。これを行うには、集中ログインプロセスと、システムにデータベースを動的に追加し、ユーザーを登録する手段が必要です。 登録およびデータベース作成プロセスをどのように堅牢に自動化できますか？ システムでテナントのデータベースを作成および登録するプロセスは、パフォーマンスまたはロックの問題を引き起こす可能性がありますか？これが問題になると思われる場合、誰でもそれを軽減する方法を提案できますか？ ユーザー資格情報が特定のテナントのデータベースに関連付けられているが、ユーザーは共通のページからログインできる（つまり、すべて同じログインURLであるが、ホームアプリケーションは特定のテナントのデータベースにある）方法で中央認証を管理する方法）。テナントは独自のログインとアクセス許可を維持できる必要がありますが、中央ログインシステムはこれらを認識している必要があります。誰でもこれを行う方法を提案できますか？ 複数のデータベースサーバーを追加して「スケールアウト」する必要がある場合、サーバー全体のユーザーIDの管理（なりすましなど）で対処しなければならない問題と、それらの問題を軽減する方法を誰か提案できますか？

26 sql-server  database-design 

以下を考慮してください。 entity User { autoincrement uid; string(20) name; int privilegeLevel; } entity DirectLoginUser { inherits User; string(20) username; string(16) passwordHash; } entity OpenIdUser { inherits User; //Whatever attributes OpenID needs... I don't know; this is hypothetical } さまざまな種類のユーザー（直接ログインユーザー、およびOpenIDユーザー）がIS-A関係を表示します。つまり、両方のタイプのユーザーがユーザーです。現在、これをRDBMSで表す方法はいくつかあります。 ウェイワン CREATE TABLE Users ( uid INTEGER AUTO_INCREMENT NOT NULL, name VARCHAR(20) …

26 database-design 

現在のプロジェクトでは、列を数文字だけ拡張する必要があることが頻繁に発生します。からvarchar(20)へvarchar(30)と上のようにします。 現実には、どれほど重要なのでしょうか？これはどの程度最適化されていますか？通常の「入力」フィールドに100文字、200文字、さらには500文字を許可した場合の影響は何ですか？メールには320文字しか使用できないため、OK-そこには十分な制限があります。しかし、200に設定した場合、それより長い電子メールアドレスは期待できないため、何を得ることができますか。 通常、テーブルには100.000行を超えることはなく、最大20または30個のこのような列があります。 現在SQL Server 2008を使用していますが、さまざまなDBがこの問題をどのように処理するかを知ることは興味深いでしょう。 影響が非常に小さい場合-予想どおり、この長距離パラノイアは実際には必要ではないと、DBAに納得させるために（リンクでバックアップされている？）良い議論を得るのに役立ちます。 そうである場合、私は学ぶためにここにいます:-)

26 sql-server-2008  database-design  datatypes 

私は非常に安全な環境で作業することに慣れているため、非常に細かい粒度で権限を設計します。私が通常行うことの1つは、更新されるべきではない列DENYに対する機能を明示的にユーザーに提供するUPDATEことです。 例えば： create table dbo.something ( created_by varchar(50) not null, created_on datetimeoffset not null ); これらの2つの列は、値が設定されたら変更しないでください。したがって、私は明示的にそれらDENYのUPDATE許可をします。 最近、チームミーティング中、開発者は、「何らかの理由で値を更新する必要がある場合」に、フィールドが更新されないことを保証するロジックをデータベース層ではなくアプリケーション層に含めるべきであると指摘しました。私にとっては、典型的な開発者のメンタリティのように聞こえます（私は知っています、私は以前は1人でした！） 私は会社のシニアアーキテクトであり、アプリを機能させるために必要な最小限の特権の原則に常に取り組んできました。すべての許可は定期的に監査されます。 このシナリオのベストプラクティスは何ですか？

25 sql-server  database-design  permissions  best-practices 

私はデータベースを設計している最中であり、最初の設計決定について再考しています... 製品タイプは次のとおりです...モデル、部品、交換部品キットおよびオプション。 オプションA（最初の設計）：上記の製品タイプ用に別々のテーブルを用意する予定でした。各テーブルでフィールドの約75％が同じになると思います。 それらの間に作成する必要がある関連付けのため、各製品タイプを個別のテーブルとして作成しました。たとえば、モデルには多くのオプションがあり、オプションには多くのモデルがあります。オプションには多くのパーツを含めることができ、パーツには多くのオプションを含めることができます...など... オプションB：個別のテーブルを作成する代わりに、モデル、パーツ、交換パーツキットおよびオプションを含むProductというテーブルを作成できます。モデルやオプションなどを区別するために、typeというフィールドを1つ持つことができます。特定の製品タイプでは、いくつかのフィールドが使用されない（nullのままになる）ことになると思います。私はこれが「ベストプラクティスではない」が出てくる場所だと推測しています。 オプションBは、db設計の複雑さを大幅に軽減します。また、クエリのためにデータを引き出すときに、大量のテーブルを参照することを心配する必要もありません...

25 database-design  database-recommendation 

すべての登録ユーザーのIPアドレスをデータベースに保存する必要があります。このような列に対して何文字を宣言すればよいのでしょうか？ IPv6もサポートする必要がありますか？ある場合、IPアドレスの最大長は？

25 mysql  database-design  datatypes 

データウェアハウスモデリングの主要なトポロジ（スター、スノーフレーク）は、1対多の関係を念頭に置いて設計されています。これらのモデリングスキームで多対多の関係に直面すると、クエリの可読性、パフォーマンス、および構造が大幅に低下します。 ディメンション間、またはファクトテーブルとデータウェアハウスのディメンションの間に多対多の関係を実装する方法と、必要な粒度とクエリパフォーマンスに関してどのような妥協がありますか？

25 database-design  data-warehouse 

ユーザーがいて、各ユーザーが複数のメールアドレスを持つことができるとします CREATE TABLE emails ( user_id integer, email_address text, is_active boolean ) いくつかのサンプル行 user_id | email_address | is_active 1 | foo@bar.com | t 1 | baz@bar.com | f 1 | bar@foo.com | f 2 | ccc@ddd.com | t すべてのユーザーがアクティブなアドレスを1つだけ持つという制約を施行したい。Postgresでこれを行うにはどうすればよいですか？私はこれを行うことができました： CREATE UNIQUE INDEX "user_email" ON emails(user_id) WHERE is_active=true; これは、複数のアクティブなアドレスを持つユーザーを保護しますが、すべてのアドレスがfalseに設定されることは保護しません。 可能であれば、トリガーまたはpl / …

24 postgresql  database-design  constraint  ddl  referential-integrity 

ソフトウェア開発者向けにテーブルとリレーションを設計するチームがあります。私たちの組織では、彼らは3NF正規化の実施について非常に厳しいです。正直に言うと、私たちの組織の規模と、ニーズやクライアントが時間とともにどのように変化するかを考えると同意します。設計決定の背後にある理由について明確になっていない領域は、アドレスのみです。 これは主に米国の住所に焦点を当てていますが、これはこれを行うすべての国に当てはまると思います。住所の各部分は、住所テーブルの独自の列を取得します。たとえば、この厄介な米国の住所を使用します。 Attn: Jane Doe 485 1/2 N Smith St SW, APT 300B Chicago, IL 11111-2222 次のようにデータベース内で分割されます。 番地：485 ストリートフラクション：1/2 ストリートプレディレクショナル：N（北） 通りの名前：スミス 通りのタイプ：ST（通り） ストリートポスト方向：SW（南西） 市：シカゴ 州：IL（イリノイ州） 郵便番号：11111 Zip4コード：2222 国（米国を想定） 注意：ジェーンドゥ 私書箱：NULL 住居の種類：APT（アパート） 住居番号：300B また、田舎のルートと契約ルートに関連する他の列がいくつかあります。さらに、特定のアプリケーションには、いくつかの国際アドレスが含まれている可能性があります。データモデラーは、国際住所に固有の列を追加すると述べました。これは通常の行1、行2のフィールドです。 最初は、これはWAYオーバーボードだと思いました。オンラインで繰り返し調べるとは、住所1、2、3、場合によっては4を使用してから、都市、地域、郵便番号を分割することです。この粒度が有益な新しいアプリケーションのユースケースが1つあります。ユーザーが重複したビジネスを作成していないことを検証する必要があり、住所の確認は検証の1つです。私たちはできるアドレスライン1と2で動作するようにそれを得るが、それはより困難になるであろう。 特定のアプリケーションに関しては、ビジネスと人々（物理、郵送、出荷など）のために複数の種類のアドレスを保存する必要があります。我々は可能性がある印刷可能な形式の文字を生成する必要がありますが、その要件は、これまで議論されていません。 組織内のアプリケーションがサポートする必要があるその他の事項： 監査（完全な履歴テーブルを使用） 宛名ラベルの印刷 印刷フォームの生成 報告（国および地方政府向け） 私たちのアプリケーションは、他のすべてのアプリケーションが行っていることをすべて行っているわけではありませんが、アドレスを複数のコンポーネントに分割することは、私が働いている企業標準です。アプリケーションがその恩恵を受けるかどうかに関係なく、私たちはこれを強制されます。 半関連のStackOverflowの質問：閉じられた良いアドレスパーサーはどこにありますが、アドレスの解析がどれほど難しいかを示しています。 私が彼らの設計決定をよりよく理解し、アイデアでクライアントを売るために... 住所を個々の列に分割すると、どのような問題が解決しますか？ 問題が発生したため、このようなシステムを実装した人にとってのボーナスポイント。

24 database-design  normalization  best-practices  address 

PostgreSQL 9.2のアイドル接続について尋ねたこの質問に対するコメントによると、いくつかのコミットされていないトランザクション（これらのアイドル接続の一部に関連している可能性があります）はパフォーマンスの問題を引き起こす可能性があります。 コミットされていないトランザクションがあるかどうかを判断する良い方法は何ですか（接続している接続がアイドル状態かどうかを知る方法がある場合のボーナスポイント）。 どうもありがとう！

24 postgresql  database-design  performance