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

MySQLを使用しています。このアイデアは、異なるコンセプトのshopifyに似ているため、ユーザーは複数のタイプのバリアントと属性を持つ独自の製品を追加します。 私が行ったすべての調査から、これは私にとって最も可能性の高い解決策のようであり、次のスキーマに何か問題があるかどうか疑問に思っています。 ありがとうございました Table: products ------------------------------ | ID | ProductName | |----------------------------| | 1 | Leather Wallet Case | | 2 | Jeans | | 3 | Power Bank | Table: products_variants ------------------------------- | ID | ProductId | ParentId | Variant | VariantName | SKU | StockTotal | WholeSalePrice | …

11 mysql  database-design  schema  eav 

私が持っている回答のテーブルと質問表を。 回答のテーブルには、値を持っていますが、問題によっては、この値は以下のようになりbit、nvarcharまたはnumber（今のところ）。質問は、その意図した回答値の型がどうあるべきかという概念を持っています。 少なくとも数値を比較する必要があるため、これらのAnswer値をどこかで解析することが重要です。 もう少しコンテキストについては、質問と潜在的な回答（通常、テキストボックスタイプの入力に許可されているデータタイプ）は、ソートの調査で一部のユーザーによって提供されます。その後、指定された他のユーザーが回答を提供します。 私が検討したいくつかのオプションは次のとおりです。 A.目的のタイプに応じて異なる方法で解析されるXMLまたは文字列（質問で追跡されます） B. Answerテーブルを参照する（またはAnswerテーブルによって参照される）3つの個別のテーブル。意図されたタイプに基づいて結合されます。この場合、各質問の回答が1つだけになるように制約を設定する最善の方法、またはそれをアプリケーションに任せる必要があるかどうかはわかりません。 C.目的のタイプに基づいて取得できるAnswerテーブルの3つの個別の列。 私はこれらのアプローチの長所と短所、または私が考慮していなかった代替のアプローチについていくつかの情報を得ていただければ幸いです。

11 sql-server  database-design  eav 

履歴を追跡したい特定のフィールドと、履歴を追跡したくない特定のフィールドを持つオブジェクトがあるとします。正規化の観点からは、次のスキーマで問題ありません。 CREATE TABLE MyObject AS ( MyObjectId INT IDENTITY NOT NULL PRIMARY KEY, MyObjectField1 VARCHAR(100) NOT NULL, MyObjectField2 VARCHAR(100) NOT NULL, MyObjectField3 VARCHAR(100) NOT NULL, MyObjectTrackedField1 VARCHAR(100) NOT NULL, MyObjectTrackedField2 VARCHAR(100) NOT NULL, MyObjectTrackedField3 VARCHAR(100) NOT NULL, ) CREATE TABLE MyObjectHistory AS ( MyObjectHistoryId INT IDENTITY NOT NULL PRIMARY KEY, …

11 database-design  normalization 

Microsoft SQL Server 2014 Expressエディションのデータベースサイズの制限は10 GBです。さて、それは単一のインスタンスのためのものですか、それともエディションで許可される全体的なサイズですか？それとも、各データベースが10GB未満であれば、エディションを使用してデータベースをいくつでも持つことができるということですか？

10 sql-server  database-design 

大規模なクエリを高速化し、より良い結果を得るには、リレーショナルデータベースで（FOREIGN KEY制約定義を介して）関係の強制を取り除く方が良いと言うので、私は私が働いている会社の開発者と恒久的に話し合っています。パフォーマンス。 検討中のプラットフォームはMySQL 5.xであり、FOREIGN KEYがセットアップされておらず、関連するテーブルの一部のPRIMARY KEY制約が欠けていても、少なくとも私にとっては妥当ではありません。多分彼らは正しいのですが、私は間違っていますが、私はこの状況について議論するのに十分な議論がありません。 これは3年間、推奨されるアプローチでした。私はこの会社の新人です（わずか1か月）が、製品が「機能する」ため、データベースを拡張するのにためらいがあります。それにもかかわらず、最初に気付いたのは、1ページの読み込みに1分（はい、60秒！）かかっていることです。 現在の状況の背後にある主張の1つは、「非正規化された」データベースは正規化されたデータベースよりも速いということですが、私はそれが本当だとは思いません。 関連するクエリのほとんどにJOIN操作が含まれているため、大量のデータがあると非常に遅くなります（データベースには数百万の行が含まれます）。 通常、「CRUD」操作の処理は、アプリケーションプログラムコードレベルで実装されます。たとえば、FROMからデータを削除するには、次のようにしましょうTableA： との行の間に何らかの関係があるかどうかをその場で最初に確認する必要がTableAありますTableB。 上記の関係が「検出」された場合、アプリプログラムコードは関連する行の削除を許可しませんが、 何らかの理由でアプリのプログラムコードが失敗した場合、関連する行とテーブルに関係があるかどうかに関係なく、DELETE操作は「成功」します。 質問 議論を深めるために、私が良い、正確で確固とした答えを詳しく説明するのを手伝っていただけませんか？ 注：たぶん、このようなものは以前に尋ねられた（そして答えられた）かもしれませんが、Googleを使用して何も見つけることができませんでした。

10 mysql  database-design  normalization  relational-theory  denormalization 

3つのテーブルがあります。 人 役職 いいね ERモデルを設計すると、循環依存関係が発生します。 1：N 人-------- <投稿 1：N 投稿---------- <いいね 1：N 人-------- <いいね ロジックは次のとおりです。 1人が多くの投稿を持つことができます。 1件の投稿に多くの高評価があります。 1人が多くの投稿を高く評価できます（作成された人は自分の投稿を高く評価できません）。 この種類の循環設計を削除するにはどうすればよいですか？それとも私のdb設計は間違っていますか？

10 mysql  postgresql  database-design  design-pattern 

誰かがCustomerLocationテーブルに対するこのユーザーの回答を理解するのを手伝ってくれませんか。注文テーブルに住所を保存するための優れた方法が本当に必要です。 私が探しているのは、住所を設定する方法です。そのため、住所を編集しても、顧客が住所を更新したり移転したりしても、注文は影響を受けません。 現状では、私のスキーマは次のようになります。 Person |EntityID| EntityAddress |EntityID|AddressID| Address |AddressID|AddressType|AddressLine1|AddressLine2| Order |OrderID|BillingAddressID|

10 database-design  best-practices 

いつデータベースを分割したくないですか？（MySQLパーティショニングを考える） 私の場合 私は数百万行から始めます。そこから成長するはずです。 最も頻繁なクエリ制約として機能する文字フィールドの主キー（および検索が頻繁に-少なくとも1秒に数回）。 主キーは、パーティションキーとして機能するようにハッシュされます 上記の頻繁なクエリでプルされるすべての行が更新されます （日付列などに対する）頻度の低い検索では、すべてのパーティションをヒットする必要があります 最後の点でさえ、ルックアップは並行して実行されないので、すべての場合において、これは勝利ですか？パーティショニングの欠点は何ですか？少なくとも、100万件以上のレコードを表示しているときに、誰もがデフォルトで使用するものではないのですか？ 更新-私はzgguyの回答を選択しましたが、私にとって非常に有用な同様の質問に対する本当に良い回答へのリンクを含む自分の調査の結果に自分の回答を追加したことに注意してください。

10 mysql  database-design  partitioning 

テンポラルデータベースの設計に問題があります。店舗の任意の時間枠でアクティブレコードが1つだけであることを確認する方法を知る必要があります。私はこの答えを読みましたが、トリガーがどのように機能するかについて頭を抱えることはできません。特に、レコードの更新を防ぎ、代わりに新しいレコードを挿入する既存のトリガーをトリガーする方法。私の本当の問題は、終了日がnullの場合にストアが複数の有効日を持つことを防ぐ方法がわからないことです。（つまり、ストアの2つのアクティブなレコードを防止します） これは私が持っているものですが、有効日が異なる店舗の新しいレコードを挿入できます。 テーブル定義： /****** Object: Table [PCR].[Z_STORE_TEAM] Script Date: 05/09/2014 13:05:57 ******/ IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Z_STORE_TEAM]') AND type in (N'U')) DROP TABLE [Z_STORE_TEAM] GO IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Z_STORE_TEAM]') AND type in (N'U')) BEGIN CREATE TABLE [Z_STORE_TEAM]( [STORENUM] …

10 sql-server  database-design  t-sql  trigger 

リアルタイムのGPSデータを約5000 prのレートで受信します。分（4つのTCPサーバーから）。各サーバーは単一の接続を使用してデータを挿入し、挿入と挿入の間でデータをバッファーします。15分ほどごとに、サービスがこのデータをフェッチし、それをトリップに処理します。旅行が生成されたら、実際のGPSデータは通常、それほど重要ではありません。ユーザーが地図上でルートを確認したい場合のみです。 問題は、データベースが挿入されるデータの速度に追いつくのに苦労しているように見えることです。負荷が増加すると、挿入時間が急激に増加し（> 30秒）、その結果、より多くのデータをバッファリングできるようになり、その結果、挿入が大きくなり、挿入時間が長くなります。 現在のデザイン、パフォーマンスを改善するために必要ないくつかのアイデア、いくつかの質問への回答、および人々が持っている可能性のあるその他のヒントについて、いくつかコメントをいただければ幸いです。 現在のデザイン 現在、データは1週間を表すテーブルに分割されており、1年以上経過したデータはセカンダリデータベースにアーカイブされます。挿入と読み取りの両方に使用される編集可能なビューで全体が結合されます。 テーブルデザイン Id（PK、uniqueidentifier） DeviceId（FK、int） PersonId（FK、int） VehicleId（FK、int） TokenId（FK、int） UtcTime（PK、datetime2（3）） 緯度（float） 経度（float） 速度（smallint） 見出し（smallint） 衛星（tinyint） IOData（varbinary（100）） IgnitionState（tinyint） UserInput（tinyint） CreateTimeUtc（datetime2（3）） 指数 DeviceId_CreateTimeUtc_Desc DeviceId_UtcTime_Desc（クラスター化） PersonId_UtcTime_Desc TokenId_UtcTime_Desc VehicleId_UtcTime_Desc 現在、毎週、インデックスを含めて約10 GBを占めています。現在、メインデータベースには約300 GBのデータがあります。 メインデータベースのデータテーブルには、1つのファイルを持つ独自のファイルグループがありますが、メインデータベースの他のすべてのテーブルと同じディスク上にあります。セカンダリデータベースは別のディスクにありますが、同じマシン上にあります。 新しいテーブルパーティション（週）が使用されるときに、インデックスの再構築ジョブも毎週実行していると思います。縮小は行われません。 マシンは12 GBのメモリを搭載した8コアHPであり、メインデータベースを保持するディスクはRAID 10を実行しています。 アイデア プライマリデータベースに保存されるデータの量を、たとえば最大1か月に制限します。少なくとも、データベースをバックアップ/復元用に管理しやすくなりますが、これによりパフォーマンスの向上が見込めますか？ 現在のデータのファイルグループに2つのファイルを作成し、それらを2つの異なる物理パーティションに配布する 現在のデータを保持するマスタースレーブデータベースを作成して、挿入と読み取りが異なるデータベースで実行されるようにする 現在のデータのファイルをSSDディスクに配置します（ミラーリングによりSSDディスクとのパフォーマンスに違いが生じますか？） さらに情報が必要な場合はお知らせください。パフォーマンスに影響を与える恐ろしいほど多くの要因があり、おそらくそれを調整する多くの方法があります。

10 sql-server  database-design  performance  vldb 

多くのタイムゾーンのデータに対するレポートをサポートするデータウェアハウスの設計を最適化しようとしています。たとえば、アクティビティを1日の時間でグループ化して表示する必要がある、1か月分のアクティビティ（数百万行）のレポートがあるとします。そしてもちろんその日の時間は与えられたタイムゾーンの「ローカル」時間でなければなりません。 UTCと1つの現地時間をサポートしたときにうまく機能するデザインがありました。UTCおよび現地時間の日付と時刻のディメンションの標準設計、ファクトテーブルのID。ただし、100以上のタイムゾーンのレポートをサポートする必要がある場合、そのアプローチは拡張されないようです。 ファクトテーブルは非常に広くなります。また、レポートの特定の実行でグループ化に使用する日付と時刻のIDを指定するSQLの構文の問題を解決する必要があります。おそらく非常に大きなCASEステートメントでしょうか？ カバーしているUTC時間範囲ごとにすべてのデータを取得し、それをプレゼンテーションレイヤーに戻してローカルに変換してそこで集計するといういくつかの提案を見てきましたが、SSRSを使用した限られたテストでは、非常に遅くなることが示唆されています。 私はこの主題についてもいくつかの本を調べましたが、それらはすべて、UTCがあり、ディスプレイで変換するか、UTCと1つのローカルがあると言っているようです。任意の考えや提案をいただければ幸いです。 注：この質問は「データマート/倉庫でのタイムゾーンの処理」に似ていますが、その質問についてはコメントできません。 更新： Aaronが重要な更新を行い、サンプルコードと図を投稿した後、私はAaronの回答を選択しました。彼の回答に対する私の以前のコメントは、回答の元の編集を参照しているため、あまり意味がありません。必要に応じて戻ってきてこれをもう一度更新しようとします

10 sql-server  database-design  data-warehouse  reporting  timezone 

個々のレコードのメタデータをデータベースに保存するためのベストプラクティスは何ですか？ データベース内の多くのテーブルの作成時刻や最終更新時刻などの一般的なメタデータを保存する必要があります。私はいくつかの異なる解決策を見つけました： メタデータをテーブルに直接保存します。 長所： メタデータはレコードに直接リンクされています メタデータを取得するために結合は必要ありません 短所： 多くの重複列が必要です（継承が使用されている場合を除く） メタデータとビジネスデータは分離されていません で一般的なメタデータテーブルを作成し、ソフト外部キーを使用してデータを正しいテーブルとレコードにリンクします。 長所： 列の重複なし メタデータはビジネスデータから分離されています 短所： メタデータとデータ間の直接リンクなし（FKは使用できません） 結合には追加の条件が必要です メタデータを必要とするテーブルごとに個別のメタデータテーブルを作成します。 長所： メタデータはレコードに直接リンクされています メタデータはビジネスデータから分離されています 短所： 追加のテーブルがたくさん必要です 多くの重複列が必要です（継承が使用されている場合を除く） ここで述べたものよりも多くのオプション、長所または短所はありますか？そして、このメタデータを保存するためのベストプラクティスは何ですか？

10 postgresql  database-design  metadata 

説明なしの質問： とにかく、常に1が値を必要とする2つのnull値の制約を持つことはありますか？たとえば、2つの日付列はどちらもnullですが、値が必要な1 つ以上の列があります。 問題の説明： Expenseというテーブルがあるとします そして2つの日付があります： prevision_expense_expiration_date DATE NULLABLEense_payment_date DATE NULLABLE これら2つの列のロジックは次のとおりです。 私は何かを購入しましたが、電話代のような日付で支払う必要があることはわかっています。私はこれをexpense_payment_dateとともに費用として入力します。この日付は支払い予定日ですが、請求書の有効期限のような実際の支払い日ではありません。 他の状況では、あるサービスのギフトカードを販売しています。私があり、サービスが私のクライアントに転送私のプロバイダに購入の費用を持っているだけで、クライアントはカードを引き換える場合。したがって、ギフトカードには有効期限があります。ギフトカードが有効な期間の費用として挿入せずに、その「費用」を予測します。ギフトカードの有効期限が切れた場合、その「費用」はアカウントに入力しないでくださいシステム。 prevision_expenseとconfirm_expenseと呼ばれる2つの同等のテーブルを使用できることはわかっていますが、適切に聞こえないため、同じテーブルに2つの日付があり、nullを指定できますが、常に必要になるように制約または何かしたいです。 別の可能な戦略があります： payment_date DATE NOT NULL is_prevision_date BOOL NOT NULL したがって、この場合、日付がプロビジョニングの場合、ブール値は1になります。それ以外の場合は、0になります。null値はなく、すべて良好です。ただし、最初に予測日があり、THEN（2日後と言います）にその費用の確認日があるときに両方の値を保存するオプションが必要な場合を除きます。この場合、戦略2では、そのオプションはありません。 私はデータベース設計ですべてを間違っていますか？：D

10 mysql  database-design  null 

PostgreSQL 9.1データベースがあり、その一部がエージェントの手数料を処理しています。各エージェントには、彼らが得る手数料の計算式があります。エージェントごとのコミッションを生成する機能を持っていますが、エージェント数が増えると使えなくなります。非常に長いケースステートメントと繰り返しコードを実行することを余儀なくされたため、私の機能が非常に大きくなりました。 すべての数式には定数変数があります： d ..その月に働いた日数 r ..獲得した新しいノード l ..ロイヤルティスコア s ..サブエージェント手数料 b ..基本レート i ..獲得した収益 式は次のようになります。 d*b+(l*4+r)+(i/d)+s 各エージェントは、HR部門と支払い式を交渉します。では、式をエージェントテーブルに保存して、テーブルから式を取得して値で変換し、金額を計算するだけの小さな関数のようにできますか？

10 postgresql  database-design  stored-procedures  functions  postgresql-9.1 

Shopifyがすべてのショップに対して1つのデータベースのみを使用することを知っています。しかし、そのようなビッグデータを使用してデータベースをどのように処理できるでしょうか。50.000以上のショップで単一のデータベースを使用することは良い考えですか？

10 sql-server  database-design