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

特にデータベース自体が専用ツールを提供していない環境で、データベース操作のプログラムによるパフォーマンステストを実行するための効果的な方法は何ですか？ たとえば、Google App Engineでは、ページ読み込み全体が特定のデータベース操作を含む1つの操作として評価されます。この問題は、SQLiteやその他の統合DBにも存在する可能性があります。テストが必要な選択および挿入（と同等）を完全に抽象化することは困難なので、これらの種類のクエリでより徹底的な診断を実行するための推奨データベースツールはありますか？

17 performance  database-design  google-app-engine  performance-testing 

アプリケーションは、できるだけデータベースから最新のデータを更新する必要があります。そのような場合、タイマーベースのデータベースの要求（ポーリング）の他に、データを取得する他の方法はありますか？ 私はMS SQL Server 2008（および.NETアプリケーション+ Entity Framework）を使用していますが、他の種類のデータベースについても知りたいです。

17 database-design  database-recommendation  query 

次のエンティティ関係図に示されているシナリオをSQLに実装するにはどうすればよいですか？ それが示されているように、すべてのAエンティティタイプの発生に関連しなければならない少なくとも1つの B（二重接続線で示す）の対応、およびその逆。次の3つのテーブルを作成する必要があることを知っています。 CREATE TABLE A ( a INT NOT NULL, CONSTRAINT A_PK PRIMARY KEY (a) ); CREATE TABLE B ( b INT NOT NULL, CONSTRAINT B_PK PRIMARY KEY (b) ); CREATE TABLE R ( a INT NOT NULL, b INT NOT NULL, CONSTRAINT R_PK PRIMARY KEY (a, b), CONSTRAINT …

17 database-design  erd 

他の人とSQL Serverデータベースを作成しています。テーブルの1つは小さく（6行）、データはおそらく一定のままです。新しい行が追加される可能性はほとんどありません。テーブルは次のようになります。 CREATE TABLE someTable ( id int primary key identity(1,1) not null, name varchar(128) not null unique ); INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here'); 私はそのname列の文字の長さを調べていますが、その値はおそらく32文字を超えることは決してなく、おそらく24文字を超えることはないと思います。この列を変更する利点はありますか、たとえば、varchar(32)？ また、デフォルトの列サイズを4、8、32などの倍数に維持することには利点がありますか？

16 sql-server  database-design  varchar 

環境 分散アプリケーションからのデータを保存するデータベース（PostgreSQL 9.6）を設計しています。アプリケーションの分散された性質のSERIALため、潜在的な競合状態のため、自動インクリメント整数（）を主キーとして使用することはできません。 自然な解決策は、UUID、またはグローバルに一意の識別子を使用することです。Postgresには組み込みのUUIDtypeが付属しており、これがぴったりです。 私がUUIDで抱えている問題は、デバッグに関連しています。それは人間に優しい文字列です。識別子ff53e96d-5fd7-4450-bc99-111b91875ec5は何も教えてくれませんが、ACC-f8kJd9xKCdが一意であるとは限りませんが、ACCオブジェクトを扱っていることを教えてくれます。 プログラミングの観点からは、いくつかの異なるオブジェクトに関連するアプリケーションクエリをデバッグするのが一般的です。プログラマーACCがORD（order）テーブルで（account）オブジェクトを誤って検索するとします。人間が読み取れる識別子を使用して、プログラマーは問題を即座に特定しますが、UUIDを使用して、何が問題なのかを理解するのに少し時間を費やします。 UUIDの「保証された」一意性は必要ありません。私はない、競合なしで鍵を生成するためのいくつかの部屋を必要とするが、UUIDは過剰です。また、最悪のシナリオでは、衝突が発生した場合、世界の終わりにはなりません（データベースがそれを拒否し、アプリケーションが回復できます）。したがって、トレードオフを考慮して、より小さくても人間に優しい識別子が私のユースケースにとって理想的なソリューションになるでしょう。 アプリケーションオブジェクトの特定 私が思いついた識別子の形式は次のとおりです。{domain}-{string}ここ{domain}で、はオブジェクトドメイン（アカウント、注文、製品）に置き換えられ{string}、ランダムに生成された文字列です。場合によっては{sub-domain}、ランダムな文字列の前にaを挿入することも理にかなっています。レッツは、の長さを無視{domain}し、{string}一意性を保証する目的のために。 インデックス作成/クエリのパフォーマンスに役立つ場合、形式のサイズを固定できます。 問題 知っています： のような形式の主キーが必要ですACC-f8kJd9xKCd。 これらの主キーは、いくつかのテーブルの一部になります。 これらすべてのキーは、6NFデータベースのいくつかの結合/関係で使用されます。 ほとんどのテーブルのサイズは、中規模から大規模（平均で最大100万行、最大で最大1億行）です。 パフォーマンスに関して、このキーを保存する最良の方法は何ですか？ 以下に4つの解決策を示しますが、データベースに関する経験が少ないため、どれが最適かはわかりません。 考慮された解決策 1.文字列として保存（VARCHAR） （Postgresはの間に違いはありませんCHAR(n)とVARCHAR(n)、私は無視していますCHAR）。 いくつかの調査の後VARCHAR、特に結合操作での文字列比較は、を使用するよりも遅いことがわかりましたINTEGER。これは理にかなっていますが、この規模で心配する必要があるのでしょうか？ 2.バイナリとして保存（bytea） Postgresとは異なり、MySQLにはネイティブUUIDタイプがありません。BINARY36 バイトのフィールドではなく、16バイトのフィールドを使用してUUIDを保存する方法を説明する投稿がいくつかありますVARCHAR。これらの投稿は、キーをバイナリとして保存するというアイデアを与えてくれました（byteaPostgresで）。 これによりサイズを節約できますが、パフォーマンスに関心があります。どの比較が高速であるかについての説明、つまりバイナリまたは文字列の説明を見つけることができなかった。バイナリ比較の方が速いと思います。もしそうであれば、プログラマは毎回データをエンコード/デコードする必要がありbyteaますがVARCHAR、おそらくの場合よりも優れています。 私は間違っているかもしれないが、私は両方だと思うbyteaとVARCHAR、バイト（または文字単位）による（平等）のバイトを比較します。この段階的な比較を「スキップ」し、単に「全体」を比較する方法はありますか？（私はそうは思いませんが、チェックの費用はかかりません）。 として保存するのbyteaが最善の解決策だと思いますが、私が無視している他の選択肢があるのではないかと思います。また、ソリューション1で述べたのと同じ懸念が当てはまります。比較のオーバーヘッドは心配するほど十分ですか？ 「クリエイティブ」ソリューション 動作する2つの非常に「創造的な」ソリューションを思い付きました。どの程度であるかわかりません（つまり、テーブル内で数千行以上にスケーリングするのが難しい場合）。 3. UUID「ラベル」を付けて保存する UUIDを使用しない主な理由は、プログラマーがアプリケーションをよりよくデバッグできるようにするためです。しかし、両方を使用できる場合：データベースはすべてのキーをUUIDs としてのみ格納しますが、クエリが実行される前/後にオブジェクトをラップします。 たとえば、プログラマはを要求しACC-{UUID}、データベースはそのACC-部分を無視し、結果を取得して、すべてをとして返します{domain}-{UUID}。 おそらく、ストアドプロシージャまたは関数を使用したハッカーでこれが可能になるかもしれませんが、いくつかの質問が思い浮かびます。 これ（各クエリでドメインを削除/追加する）はかなりのオーバーヘッドですか？ これも可能ですか？ ストアドプロシージャや関数を使用したことがないため、これが可能かどうかもわかりません。誰かが光を当てることはできますか？プログラマと保存されたデータの間に透明なレイヤーを追加できれば、それは完璧なソリューションのようです。 4.（私のお気に入り）IPv6として保存 cidr はい、あなたはそれを正しく読みました。IPv6アドレス形式は私の問題を完全に解決することがわかりました。 最初の数オクテットでドメインとサブドメインを追加し、残りをランダム文字列として使用できます。 衝突確率は OKです。（ただし、2 ^ 128は使用しませんが、それでも大丈夫です。） 等値比較は（できれば）最適化されているため、単にを使用するよりもパフォーマンスが向上する可能性がありますbytea。 containsドメインとその階層がどのように表されるかに応じて、実際にいくつかの興味深い比較を実行できます。 たとえば0000、ドメイン「製品」を表すためにコードを使用するとします。キー0000:0db8:85a3:0000:0000:8a2e:0370:7334は製品を表します0db8:85a3:0000:0000:8a2e:0370:7334。 …

16 postgresql  database-design 

私はデータベース設計が比較的新しいので、練習用に独自の仮想データベースを作成することにしました。ただし、多くの多対多（M：N）の関係があると考えているため、モデリングと正規化に問題があります。 一般的なシナリオの説明 このデータベースは、ゼルダシリーズで働いたさまざまな人々に関するデータを保持することを目的としています。私はのトラック維持したいコンソール（S）というゲームがで再生することができ、従業員に参加を持っていたゲーム開発をジョブズ従業員は、（多くの持っていた従業員が異なる上で働いていたジョブズ複数にわたるゲームなど、） ビジネスルール 複数の従業員が複数のゲームで作業できます。 同じコンソール上に複数のゲームを配置できます。 複数のコンソールを同じゲームのプラットフォームにすることができます。 複数の従業員が同じジョブを持つことができます。 アン従業員は複数持つことができますジョブを。 A ゲームは複数持つことができる従業員を。 ゲームは、複数の種類持つことができるジョブのそれの発展に 複数のゲームに同じタイプのジョブを添付できます。 A コンソールは複数持つことができます人々はそれに取り組んで。 A 人は複数で作業することができますコンソール。 属性名とサンプル値 FirstとLastに分割できる従業員名（「John」と「Doe」など） ゲームのタイトル（たとえば、「Ocarina of Time」） 役職（たとえば、「レベル設計」、「ディレクター」、「構成」、「レベル設計者」、「プログラマー」、「ローカリゼーション」など）。 コンソール名（「Game Boy Advance」など） 問題 これまでのところ、データの冗長性と、関心のあるエンティティタイプ間のM：N関係が至る所にあるように設計されているようです。しかし、データベース設計者は常にこの種の問題に遭遇しなければならないので、解決策が必要だと感じています。 注：テーブルを満たすデータを見つけることはできますが、問題は、正規化された形式のテーブルを持つデータベースにデータを整理することです。

16 database-design  normalization  denormalization  many-to-many 

私はこのBBCニュースの記事を読んでいて、次の抜粋が私の注目を集めました。Always On可用性グループまたは高可用性ミラーリングのように聞こえますが、セキュリティが自動的に含まれている場合があります。 ブロックチェーンは、トランザクション量の多い最新のアプリケーションにとって実行可能なデータベースソリューションですか？ 個人の医療記録のような少量のトランザクションに価値があることは簡単にわかりますが、大量のデータベースについてはどうでしょうか？ ブロックチェーンとは何ですか？ ブロックチェーンは暗号化に依存しており、中央のアクターを必要とせずに一連のコンピューターがグローバルレコードを変更できるようにします。 仲介者を削除すると、ほぼすべての部門でコストが削減されます。 ブロックチェーンは、「ブロック」として知られるデータのコレクションに発生するすべてを時系列または「チェーン」で記録する台帳です。 通貨としてこれは重要な機能です。これにより、ユーザーは自分のデジタルマネーが種類の1つであることを確認できるため、ウォレット内の各紙幣が一意であるのと同じです。 「ブロックチェーン技術は、コピーせずにデジタル情報を転送できるため、私たちが資産を作成する方法になります」と、ブロックチェーンネットワークを構築するChain.comのCEO、Adam Ludwin氏は述べています。 ブロックチェーンは、あらゆる種類の情報の履歴を追跡し、その価値を維持するために使用できます。たとえば、医師はそれを使用して医療記録を更新できます。 ブロックチェーンへの各変更はネットワーク全体で同時に行われるため、情報が失われることはなく、変更を元に戻すことができないため、システムはその透明性を維持します。各ブロックを変更するには特別なキーが必要なので、個人はそのキーを保護することで記録を安全に保つことができます。

16 database-design  normalization  distributed-transactions 

いくつかの調査を行った結果、ルートを一連のストップとして保存する必要があることがわかりました。何かのようなもの： Start -> Stop A -> Stop B -> Stop C -> End 3つのテーブルを作成しました。 ルート 止まる ルートストップ ... RouteStopsはジャンクションテーブルです。 私のようなものがあります： ルート +---------+ | routeId | +---------+ | 1 | +---------+ | 2 | +---------+ 駅 +-----------+------+ | stationId | Name | +-----------+------+ | 1 | A | +-----------+------+ | 2 …

16 database-design 

私はテーブル設計シナリオを持っていますが、非DBAタイプとして、よりスケーラブルな意見を求めています。 メトロエリアの家に関する情報を記録するように求められたとします。小さな近所（200の家）から始まり、最終的には5000000以上の家に成長します。 基本情報を保存する必要があります：ID＃（一意のインデックスとして使用できる一意のロット番号）、Addr、City、State、Zip。素晴らしくシンプルなテーブルがそれを処理します。 しかし、毎年、すべての家に関する追加情報を記録するように求められます-そして、何の情報は毎年変わります。したがって、たとえば、最初の年には、所有者の姓と面積を記録するように求められます。2年目は、姓を残すよう求められますが、面積を捨てて、代わりに所有者の名の収集を開始します。 最後に-毎年、追加の列の数が変更されます。余分な2つの列から始めて、来年は6に、その後2に戻すことができます。 そのため、テーブルのアプローチの1つは、ハウステーブルの列としてカスタム情報を追加して、テーブルが1つだけになるようにすることです。 しかし、私は誰かがこれのためにテーブルを次のようにレイアウトする状況を持っています： 「House Table」列：ID、Addr、City、State、Zip-家ごとに1行 ID Addr City State Zip ------------------------------------------- 1 10 Maple Street Boston MA 11203 2 144 South Street Chelmsford MA 11304 3 1 Main Avenue Lowell MA 11280 「カスタム情報テーブル」列：ID、名前、値-テーブルは次のようになります。 ID Name Value 1 Last Name Smith 2 Last Name Harrison 3 Last …

16 database-design  normalization  architecture  table 

別のエンティティに定義されない限り存在できないエンティティがあり、このエンティティを多対多の関係に参加させたい。 例：アーティストにはアルバムがあり（アルバムはアーティストなしでは存在できません）、アルバムにも多くのトラックがありますが、同じトラックが多くのアルバムに存在する可能性があります。 そのため、アルバムとトラックの間には多対多の関係があります。 アルバムが弱いエンティティである場合、その主キーはアーティストを参照する外部キーであるため、多対多の関係を表す別のテーブルへの外部キーにすることはできません。 問題は、SQLでこのような関係を持つことは可能ですか？その場合、どのように表現するのですか？

16 database-design  foreign-key  referential-integrity 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は古い学校に育ちました-アプリケーションのビジネスレイヤーの前にデータベーススキーマを設計することを学びました（または他のすべてにOOADを使用しました）。私はスキーマ（IMHO :)の設計にかなり長けており、不必要な冗長性を削除するためだけに正規化しましたが、速度に影響を与える場所ではありません。つまり、結合がパフォーマンスに影響した場合、冗長性はそのまま残されました。しかし、ほとんどそうではありませんでした。 RubyのActiveRecordやActiveJDBCなどのいくつかのORMフレームワークの出現により（覚えていないが他にもいくつかありますが、たくさんあると確信しています） 「メール」-2NFを完全に破壊します。さて、あまり理解していませんが、これらのORM（またはプログラマー）の一部が1-1または1-0 | 1（つまり、1対0または1）を認識しないと、（ほとんど）緊張します。彼らは、nulls 「今日のシステムがそれを処理できる」という大量の情報がある場合でも、すべてを1つの大きなテーブルとして保持する方が良いと述べています。 メモリの制約は正規化と直接的な相関関係があることに同意します（他の利点もあります:)が、今日の安価なメモリとクアッドコアマシンでは、DB正規化の概念はテキストに残されていますか？DBAは3NF（BCNFではない場合）への正規化を実践していますか？それは重要ですか？「ダーティスキーマ」設計は本番システムに適していますか？それがまだ関連している場合、どのように「正規化」のためにケースを作るべきか。 （注：設計の一部/必要性として冗長性を備えたデータウェアハウスのスター/スノーフレークスキーマについてではなく、たとえばStackExchangeのようなバックエンドデータベースを備えた商用システムについてです）

16 database-design  normalization 

アカウントで収集するための1日のコストを追跡する何かを作成するように求められ、これをサポートするデータベーステーブルスキーマを見つけようとしています。 これが私が知っていることです 会社は250万以上のアカウントを持っています これらのうち、彼らは現在、1か月あたり平均20万人働いています（現在は低い人員配置レベルで変化します） 追跡したい13の異なるコストタイプがあり、将来さらに追加する可能性があると警告しています。 コストを毎日追跡したい コストは在庫全体に分割されません。それらは、1か月あたり働くアカウント数（200,000）に分割されるか、ユーザーがアカウント識別子を入力してアカウントのグループにコストを適用するか、単にコストを適用するアカウントを指定できます。 最初に考えたのは、正規化されたデータベースです。 アカウントID 日付 CostTypeId 量 これに関する私の問題は、数学をすることです。このテーブルはすぐに巨大になります。13のすべてのコストタイプが今月のすべての作業済みアカウントに適用されると仮定すると200k * 13 * N days in month、これは1か月あたり約7500〜8000万レコード、または1年あたり約10億レコードになります。 私の2番目の考えは、それを少し非正規化することでした アカウントID 日付 総費用 CostType1 CostType2 CostType3 CostType4 CostType5 CostType6 CostType7 CostType8 CostType9 CostType10 CostType11 CostType12 CostType13 この方法はより非正規化されており、1か月あたり最大600万レコード（200k * N days in month）、または1年あたり約7,200 万レコードを作成できます。最初の方法よりもはるかに少ないですが、将来会社が新しいコストタイプを決定した場合は、別のデータベース列を追加する必要があります。 2つの方法のうち、どちらがお好みですか？どうして？これをより良く処理できると考えられる別の選択肢はありますか？ 私は、要約レポートと詳細レポートの両方のパフォーマンスのレポートに最も興味があります。アカウントに費用を配分するジョブは、誰もいないときに夜間に実行されます。二次的な懸念は、データベースのサイズです。既存のデータベースはすでに約300 GBであり、ディスク上のスペースは約500 GBであると思います。 データベースはSQL Server …

16 sql-server  performance  database-design 

SQL Server 2012データベースを開発していますが、One-to-Zero-Or-Oneの関係について質問があります。 2つのテーブルがCodesありHelperCodesます。コードには、ゼロまたは1つのヘルパーコードを含めることができます。これは、これら2つのテーブルとそれらの関係を作成するSQLスクリプトです。 CREATE TABLE [dbo].[Code] ( [Id] NVARCHAR(20) NOT NULL, [Level] TINYINT NOT NULL, [CommissioningFlag] TINYINT NOT NULL, [SentToRanger] BIT NOT NULL DEFAULT 0, [LastChange] NVARCHAR(50) NOT NULL, [UserName] NVARCHAR(50) NOT NULL, [Source] NVARCHAR(50) NOT NULL, [Reason] NVARCHAR(200) NULL, [HelperCodeId] NVARCHAR(20) NULL, CONSTRAINT [PK_Code] PRIMARY KEY CLUSTERED ( …

15 database-design  sql-server-2012 

私はこれがこことここで尋ねられたことを知っていますが、異なる考えられる実装で同じ考えを持っているので、助けが必要です。 最初は、blogstoriesこの構造のテーブルがありました。 | Column | Type | Description | |-----------|-------------|------------------------------------------------| | uid | varchar(15) | 15 characters unique generated id | | title | varchar(60) | story title | | content | longtext | story content | | author | varchar(10) | id of the user that originally wrote the …

15 mysql  database-design 

最初にいくつかの背景。 LedgerSMBプロジェクトは、PostgreSQLで実行されるオープンソースの財務会計ソフトウェアプロジェクトです。ユーザー定義関数に非常に大量のビジネスロジックを実装します。これらは、プログラムオブジェクトメソッドとデータベースの動作間の主要なマッピングツールとして機能します。現在、認証ユーザーとしてデータベースユーザーを使用します（一部は選択（これにより中央集中型のセキュリティロジックが可能になり、他のツールを記述してユーザーに与えられたアクセス許可を再利用できます））。また、一部は必要に応じて（SQL-Ledgerそのコードベースにセキュリティをレトロフィットするオプションはあまりありませんでした）。 これにより、LDAPからKerberos 5まで、PostgreSQLがアクセスできる合理的な数のシングルサインオンオプションにアクセスできます。パスワードが関係する場所でもPAMを使用できます。また、他のアプリケーションと統合したり、他のクライアントインターフェイスを許可したりするときに、アクセス許可を再利用できます。財務会計アプリケーションにとって、これは正味の勝利のように思えます。 明らかにコストがかかります。Webアプリケーションの場合、サポートできるHTTP認証のタイプは非常に限られています。たとえば、DIGESTは完全に除外されています。BASICが機能し、KRB5を簡単に実装できます（これは1.4でサポートされ、そのまま使用できるようにする予定です）。非常に強力な認証対策は、これを直接適切に管理することはできませんが、おそらく必要に応じてそれらをシムできます（たとえば、ユーザー名と特定のルートCAに一致するcnを持つBASIC +クライアント側SSL証明書）。 同時に、主に開発群衆から、そして時折、アプリケーションはデータベースではなくセキュリティバリアであるべきだと言うdbaからかなりの批判を受けています。私の見解では、セキュリティ境界は小さいほうが一般的に優れており、ビジネスロジックとセキュリティロジックの再利用が一緒になり、同じレベルでセキュリティロジックを再利用せずにビジネスロジックを再利用するのは危険だと思いますプログラムの。 ここで大きなトレードオフがありませんか？私が検討していない落とし穴はありますか？

15 database-design  postgresql  security