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

ウェブサイトの製品データベースの更新に取り組んでいます。MySQLに組み込まれていますが、これは一般的なデータベース設計パターンの問題です。 Supertype / Subtypeパターンへの切り替えを計画しています。現在/以前のデータベースは、主に単一のタイプの製品に関するデータを含む単一のテーブルです。私たちは、異なる製品を含めるために製品提供を拡大することを検討しています。 この新しいドラフトデザインは次のようになります。 Product product_[type] product_attribute_[name] ---------------- ---------------- ---------------------------- part_number (PK) part_number (FK) attributeId (PK) UPC specific_attr1 (FK) attribute_name price specific_attr2 (FK) ... ... 製品の属性表について質問があります。ここでのアイデアは、色：赤、緑、青、または材料：プラスチック、木材、クロム、アルミニウムなどの特定の属性のリストを持つことができる製品です。 このリストはテーブルに格納され、その属性項目の主キー（PK）は特定の製品テーブルで外部キー（FK）として使用されます。 （Martin Fowler氏の著書「Patterns of Enterprise Application Architecture」では、これを「外部キーマッピング」と呼んでいます） これにより、Webサイトインターフェースは、指定された属性タイプの属性のリストをプルし、ドロップダウン選択メニューまたはその他のUI要素にそれを吐き出すことができます。このリストは、属性値の「許可された」リストと考えることができます。 特定の製品をプルするときに発生する結合の数が多すぎるように見えます。すべての製品属性テーブルを製品に結合して、その属性のフィールドを取得できるようにする必要があります。一般的に、そのフィールドは、単にその名前の文字列（varchar）にすぎません。 この設計パターンでは、多数のテーブルが作成されるだけでなく、属性ごとにテーブルが作成されます。これに対抗する1つのアイデアは、すべての製品属性に対して「グラブバッグ」テーブルのようなものを作成することです。このようなもの： product_attribute ---------------- attributeId (PK) name field_name このようにすると、テーブルは次のようになります。 1 red color 2 blue color …

9 mysql  database-design 

人のディレクトリであるWebサイトを想像してみましょう。それぞれの人にプロフィール写真と伝記があるかもしれません。 私はSQLクエリの方が優れていることを認めますが、一般的には何がより速く、より少ない処理能力を使用します。 ファイルが存在するかどうかを確認してから開くには、または MySqlをチェックして、略歴が存在するかどうかを確認し、表示します。 上記の場合、ファイルシステムはmysqlデータベースをスモークします。 データベースを読み取り専用の区切りテキストファイルにするとどうなりますか？ この場合、何が速くなりますか？ txtファイルにレコードが多すぎる場合、MySqlを使用する方がよい特定のポイントはありますか？

9 mysql  database-design  datafile 

1000 ADより前に拡張するレコードのデータベースを作成していますが、MySQLのDateおよびDateTimeフィールドは1000から始まる日付のみをサポートしています。 bigint型を使用してUnixタイムスタンプを使用して1970年1月1日の前/後の秒数をカウントする方法、またはより広い日付範囲をサポートするデータベースソフトウェアに切り替える方法よりも便利な方法はありますか？

9 mysql  database-design  best-practices  timestamp  date-format 

私はデータマートの設計に不慣れで、いくつかの概念をクリアする必要があります。 ファクトテーブルにディメンションテーブルへの外部キー参照が格納されていることがわかるディメンションモデリングについて少し読んだことがあります。 ここで、phonenumberディメンションテーブルとphone_extensionディメンションテーブルがあるとします。（これらの表は、詳細が異なるため、組み合わせることができません） 私が理解しているように、これらの両方のディメンションテーブルには、パフォーマンスを向上させるための整数主キーがあり、ファクトテーブルには独自の整数主キーがあり、これらのディメンションテーブルへの外部キー参照も格納されます。 しかし、すべての電話番号に関連するphone_extensionがあるわけではない状況があるとします。（一部の電話番号には内線が必要ありません） 内線番号を持つ電話番号の場合、ファクトテーブルには両方のディメンションテーブルへの外部キー参照がありますが、電話番号のみで内線番号がない（およびその逆、つまり電話番号のない内線番号）状況をどのようにキャプチャしますか？ 値とphone_extension外部キーがnullであるファクトテーブルの電話番号FKでこのような情報をキャプチャする必要がありますか？または、そのような非関連オブジェクトがファクトテーブルに記録されていませんか？ また、このデータマートのレポートを生成する必要があります。それでは、まずファクトテーブルをクエリしてディメンションキーの値を取得するか、ディメンションテーブルから直接レポートを作成しますか？ これを読んでくれてありがとう！ 助けてくれてありがとう!!

9 database-design  data-warehouse 

データベースサーバーでのクエリの応答に時間がかかるようで、CPU使用率が高いと思います。を実行するとps aux、約250の「アイドル」接続が表示されます（多すぎると思われます）。私は完全な診断を始めていませんが、これが探し始めるのに良い場所かどうか知りたいと思っていました。 また、PgBouncerをトランザクションレベルのプールで使用しています。idleプールサイズを調整することで、接続数を簡単に減らすことができると思います。ただし、正当な理由がない限り、あまり多くの変更を開始したくありません。 idlePostgreSQL 9.2の多くの接続がパフォーマンスに影響を与える可能性はありますか？ どうもありがとう！

8 postgresql  database-design  performance  query-performance 

現在、トランザクションテーブルを設計しています。各行の現在までの合計を計算する必要があり、パフォーマンスが低下する可能性があることに気付きました。そこで、テスト用に100万行のテーブルを作成しました。 CREATE TABLE [dbo].[Table_1]( [seq] [int] IDENTITY(1,1) NOT NULL, [value] [bigint] NOT NULL, CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED ( [seq] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO そして、最近の10行とその現在までの合計を取得しようとしましたが、約10秒かかりました。 --1st attempt SELECT TOP 10 seq …

8 sql-server  database-design  t-sql  query-performance  execution-plan 

私はリレーショナルデータベースについてもっと学びたいと思っており、実際に何かをするために学ぶより良い方法はないと思いました。私は個人的な予算の会計と予測を見る個人的な試みをすることにしました。これまでにいくつかの調査を行ったので、現在のデータベースの設計と正規化について洞察を得たいと思います。 現在のデータベース設計に関するあなたの考えと提案は何ですか？私はあなたが私を助けるのをよりよく助けるためにいくつかの情報を以下に含めました:) 開示：これは個人的なプロジェクトです。宿題や仕事のためではありません。 ビジネスの事実 銀行ACCOUNTは多くのことができますENTRIES はENTRY、CREDITまたはDEBIT アンはENTRY、それは上の貸方かに引き落とされた日付を持っています アンはENTRYシングルを持っていますPAYEE ENTRYAに関連付けることができますBUDGET CATEGORY A CREDITはENTRY のCREDIT説明がありますENTRY A CREDITは将来的にスケジュールできます A CREDITは頻度や量で再発する可能性があります A DEBITはENTRY のDEBIT説明がありますENTRY A DEBITは将来的にスケジュールできます A DEBITは頻度や量で再発する可能性があります A PAYEEには名前があります AにBUDGETは多くのBUDGET CATEGORIES A BUDGETは単一のカレンダーにのみ関連付けることができます A BUDGET CATEGORYは多くのENTRIES A BUDGET CATEGORYには名前があります A BUDGET CATEGORYにはBUDGET金額があります A FORECASTには開始日があります A FORECASTには終了日があります A FORECASTには期首残高があります AにFORECASTは多くのFORECASTED DAYS A FORECASTは1つFORECASTED BUDGET …

8 sql-server  database-design  best-practices 

私はPostgreSQLのINSERT INTO .. ON CONFLICT (..) DO UPDATE ..構文を見ていましたが、それを使用して複数の一意制約チェックを実行することはできません。つまり、複合一意インデックスを列名で参照するかON CONFLICT (Name, Symbol)（一意のインデックスがこれらの2つの列に対して定義されている場合）、または主キーを使用します。列に2つの個別の一意のインデックスを定義する場合、チェックできるのは1つだけです。 CREATE TABLE student (Id int primary key, Name varchar(50), Symbol varchar(50), CONSTRAINT col1_unique UNIQUE (Name), CONSTRAINT col2_unique UNIQUE (Symbol) ); INSERT INTO student (Id, Name, Symbol) VALUES (1, 'John', 'J'), (2, 'David', 'D'), (3, 'Will', 'W'); INSERT INTO …

8 postgresql  database-design  merge 

2つのテーブル間の関係をm：1からm：nに変更する必要がある状況があります。 したがって、これら2つのテーブルの間に相互参照テーブルを作成する必要があります。 すべての既存のデータを「子」テーブルから相互参照テーブルに移行した後、子テーブルの元の外部キー列を削除することは悪い考えでしょうか？ そこに置いておくと、基本的に技術的な負債があります。しかし、私はdbaではなく、テーブルから列を削除することの意味をよく理解していません。（私はそれが可能であることを知っていますが、それは悪い考えですか？私のデータベースはそれを嫌いますか？） ありがとう

8 sql-server  database-design 

私は、センサーアレイからの気象データを保存するソリューションを実装/再設計することを任されています。アレイは約40のタワーで構成され、それぞれに約10のセンサーがあり、未確定の時間（年）にわたって10秒間隔で大気条件をサンプリングします。このタスクのいくつかのアプリケーションと要件は次のとおりです。 タワー/センサー構成を管理および取得して、データ分析を理解します。 気象観測のためのセンサーまたは時間間隔によるデータ可視化。 モデルとセンサーのパフォーマンスを比較するために、信頼性のある永続的なデータリソース/データセットを顧客に提供します（必要な形式で配信するには、いくつかの後処理が必要になる場合があります）。 注：現在のソリューション（5つのタワーを備えた概念実証として実装）では、データをフラットファイル（1時間に1ファイル）として保存します。 これが将来的にビッグデータの問題になるかどうかは当初はわからなかったので、リレーショナルデータベースとNoSQLデータベースの両方についていくつかのソリューションを調査しましたが、データ管理の専門家ではないため、もう少しガイダンスが必要だと思います。 私が考えたソリューションの1つは、タワー、センサー、タイムスタンプでインデックスが付けられたリレーショナルデータベースにデータを保存し、日付でテーブルを分割することでした。 もう1つは、将来のスケーリングに基づいて、MongoDBなどのドキュメントタイプのNoSQLデータベースに保存し、現在のソリューションの構造を模倣することでした。 これらの良いアプローチのいずれかはありますか？そうでない場合、より良い/推奨されるソリューションは何ですか？また、現在のソリューションを再設計する必要があるでしょうか？フラットファイルを使用する理論的根拠は、リレーショナルデータベースはオーバーヘッドがかかりすぎると信じているということです。もしそうなら、これを回避する方法はありますか？

8 database-design  nosql  scalability 

特定の日付で製品価格のデータベースを照会できるように、製品価格の変化を追跡する必要があります。この情報は、履歴監査を計算するシステムで使用されるため、購入日に基づいて、正しい製品の正しい価格を返す必要があります。 私はデータベースの構築にpostgresを使用したいと思います。 データベースの設計が必要ですが、あらゆるベストプラクティスの提案も歓迎します。

8 database-design  best-practices 

座席予約データベースを検討してください。nシートのリストがあり、それぞれに属性がありますis_booked。0はそうでないことを意味し、1はそうであることを意味します。それ以上の数でオーバーブッキングがあります。 オーバーブッキングを許可せずに複数のトランザクション（各トランザクションが同時にyシートのグループを予約する）の戦略は何ですか？ 私は単にすべての未予約の座席を選択し、ランダムに選択されたyのグループを選択し、それらすべてを予約し、その予約が正しいかどうかを確認します（別名is_bookedの数が1を超えていない場合、座席を予約した別のトランザクションとコミット）、次にコミットします。それ以外の場合は中止して、再試行してください。 これは、Postgresで分離レベルのRead Committedで実行されます。

8 postgresql  database-design  concurrency 

ターミナルでのコンテナの入口と出口を追跡する累積スナップショットファクトテーブルがあります。 コンテナーは3つの異なる方法で出入りできるので、これら3つの可能な方法（列車、船舶、またはトラック）をリストする特定のディメンションテーブルを作成することを考えました。 それから私はこのテクニックを間違っていると基本的に言っているこの記事を読みました、しかし私はその理由を理解できません。 最初の記事： ファクトテーブルに、個々の行にまばらに入力されているファクトの長いリストがある場合、ファクトテーブル行をメジャータイプディメンションで識別される単一の汎用ファクトに折りたたむメジャータイプディメンションを作成したくなることがあります。通常、この方法はお勧めしません。空のファクト列はすべて削除されますが、ファクトテーブルのサイズに各行の占有列の平均数が乗算され、列内の計算がはるかに困難になります。この手法は、潜在的なファクトの数が（数百単位で）極端な場合に許容されますが、特定のファクトテーブル行に適用できるのは一握りではありません。 「メジャータイプディメンション」がトランザクションファクトテーブルに実装されている場合、この他の記事にあるような問題が発生する可能性があることは理解していますが、スナップショットファクトの蓄積に使用してもマイナス面は見られません。 2番目の記事：（ 「メジャータイプディメンション」の実装のいくつかの欠点） [...]「メジャータイプディメンション」を使用すると、この分析能力が失われます。1つのメジャーが他のメジャーと互換性がない場合、それらを合計することはできません。 [...]レポートを作成するためにSQLが実行する必要のあるパスの数が多いほど、レポートは遅くなります。 [...] BIツールでメジャータイプフィルターを配置しない場合、ユーザーが「ゴミ情報」を取得する危険があります。使いやすさの観点から見ると、このデザインはごみです。 Mark Storey-Smithの回答への応答 とても素敵なアプローチ、私はそれについて考えたことはなかったでしょう。 もう1つ：コンテナをターミナルに持ち込む車両のすべての出入り口には一意のIDがあり、次のような情報が得られます。車両の到着予定、実際の到着、船の場合はドック、トラックの場合は料金所、他の多くの情報... これらは3つの異なるファクトテーブルであり、何らかの方法でコンテナファクトテーブルにリンクする必要があります。 航海のIDはであると思ったdegenerate dimensionので、コンテナのファクトテーブルに直接入力します。だから、私の疑問は：コンテナーファクトテーブルに6つの異なるフィールド（vessel_voyage_in_key、vessel_voyage_out_key、train_voyage_in_key、train_voyage_out_key、truck_voyage_in_key、truck_voyage_out_key）または他の2つのフィールド（voyage_in、voyage_outに動的にリンクするvoyage_out）を追加する必要があるかどうかです。 私の疑問が明確になれば幸いです、ありがとう。

8 database-design  data-warehouse 

私のデータの構造は次のとおりです： date: <timestamp> filter_a: <integer> -> range [0, 1000] filter_b: <integer> -> range [0, 1000] filter_c: <integer> -> range [0, 86400] filter_d: <integer> -> range [0, 6] group: <string> second_group: <integer> variable_a: <float> variable_b: <float> variable_c: <float> a couple more no very important 次のクエリを実行する必要があります。 最初： フィルターデータによってdate、filter_a、filter_b、filter_c、その他 次に、フィルタリングされたデータを使用します。 すべてのレコードを数える 取得平均のvariable_a、variable_bおよびvariable_c 取得標準偏差のをvariable_a、variable_bそしてvariable_c …

8 database-design  query-performance  mongodb  performance-tuning 

私が理解しているように、第3正規形（3NF）は基本的に、キーが1つだけであることを意味します。 たとえば自動インクリメントid列があるテーブルに、一意であり、nullではないことがわかっている列（社会保障番号など）もある場合、この他の列をキーとして使用できます。 厳密にスキーマ設計の観点から、実用的/ビジネス上の問題（SSNをキー/ FKとして渡す場合のセキュリティ/プライバシーリスクなど）を無視すると、そのようなテーブルは実質的に2つのキーがあるため3NFに含まれませんか？ 他の列に一意のキーがあったかどうかによって、答えは異なりますか？もしそうなら、なぜですか？

8 database-design  relational-theory