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

MySQLデータベースに質量分析計からのスキャンを保存することを計画していますが、この量のデータの保存と分析がリモートで実行可能かどうかを知りたいです。パフォーマンスは環境によって大きく異なることがわかっていますが、大まかな順序を探しています：クエリには5日または5ミリ秒かかりますか？ 入力形式 各入力ファイルには、分光器の単一の実行が含まれています。各実行は一連のスキャンで構成され、各スキャンには順序付けられたデータポイントの配列があります。少しのメタデータがありますが、ファイルの大部分は32ビットまたは64ビットのintまたはfloatの配列で構成されています。 ホストシステム | ---------------- + ------------------------------- | | OS | Windows 2008 64ビット| | MySQLバージョン| 5.5.24（x86_64）| | CPU | Xeon E5420 x 2（合計8コア）| | RAM | 8GB | | SSDファイルシステム| 500 GiB | | HDD RAID | 12 TiB | | ---------------- + ------------------------------- | 無視できるプロセッサー時間を使用して、サーバーで実行されている他のサービスがいくつかあります。 ファイル統計 | …

283 mysql  database-design  performance 

データベース設計に関するこの1つの記事を読んだことを覚えています。また、NOT NULLのフィールドプロパティを持つべきだと言ったことを覚えています。しかし、なぜそうなのかは覚えていません。 私が考えることができるのは、アプリケーション開発者として、NULL および存在しないデータ値（たとえば、文字列の空の文字列）をテストする必要がないということだけです。 しかし、日付、日時、および時刻の場合はどうしますか（SQL Server 2008）。あなたは、いくつかの歴史的な日付またはボトムアウト日付を使用する必要があります。 これに関するアイデアはありますか？

125 database-design  null 

データベース内のデータに関連するバイナリファイルを保存するのに最適な場所は何ですか？あなたは： BLOBを使用してデータベースに保存する データベース内のリンクを使用してファイルシステムに保存する ファイルシステムに保存しますが、コンテンツのハッシュに名前を変更し、データベースにハッシュを保存します 私が考えていないこと （1）の利点は（とりわけ）トランザクションの原子性が保持されることです。コストは、ストレージ（および関連するストリーミング/バックアップ）要件を劇的に増加させる可能性があることです （3）の目標は、ある程度まで原子性を保持することです。書き込み先のファイルシステムでファイルの変更や削除を許可せず、ファイル名として常に正しいハッシュを持つことを強制できる場合。ハッシュを参照する挿入/更新を許可する前にファイルシステムにファイルを書き込むことが考えられます-ファイルシステムの書き込み後、データベースDMLの前にこのトランザクションが失敗した場合、ファイルシステムはすべてのリポジトリであるため、問題ありません可能性のあるファイルとハッシュ-そこにポイントされていないファイルがあるかどうかは関係ありません（注意すれば定期的にクリーンアップできます） 編集： 一部のRDBMSはこれを個別の方法でカバーしているようです-他の人がそれをどのように行うのか知りたいと思います-特にpostgresのソリューション

123 database-design  blob 

ランダムなテーブルにstatusという名前の列があるとします。実際の値は、有効または無効になります。 この列のデータ型がint / bool（1または0）であるか、またはand ENUMの値で使用する方が良いでしょうか？長所と短所は何ですか？enableddisabled 有効なステータスが2つだけではなく、4または10以上あるとしますか？必要な値の数が増えると、長所と短所はどちらか一方に左右されますか？

110 mysql  database-design  datatypes 

集計値を保存するタイミングと、その場でそれらを計算するタイミングを決定するためのガイドラインまたは経験則はありますか？ たとえば、ユーザーが評価できるウィジェットがあるとします（下のスキーマを参照）。ウィジェットを表示するたびに、Ratingsテーブルから平均ユーザー評価を計算できました。または、Widgetテーブルに平均評価を保存できます。これにより、ウィジェットを表示するたびに評価を計算する必要がなくなりますが、ユーザーがウィジェットを評価するたびに平均評価を再計算する必要があります。 Ratings Widgets --------- ------- widget_id widget_id user_id name rating avg_rating <--- The column in question

96 mysql  database-design  aggregate 

フィールドAとを持つテーブルがあるとしましょうB。A+ Bで定期的にクエリを作成するため、で複合インデックスを作成しました(A,B)。クエリAも複合インデックスによって完全に最適化されますか？ さらに、にインデックスを作成しましたAが、Postgresはでのみクエリに複合インデックスを使用していAます。前の答えが正の場合、それは実際には重要ではないと思いますが、単一のAインデックスが利用可能な場合、デフォルトで複合インデックスを選択するのはなぜですか？

86 postgresql  database-design  performance  index  index-tuning 

列がある表がある場合： id | name | created_date 列を追加したい場合、私は使用します： alter table my_table add column email varchar(255) 次に、列は列の後に追加されcreated_dateます。 新しい列の位置を指定する方法はありますか？たとえば、次のように追加して、次のnameようなテーブルを取得できます。 id | name | email | created_date

74 postgresql  database-design 

注 Programmers.seとdba.seの対象者は異なり、異なる視点を持つため、この場合、データベースレイヤーにアプリケーションロジックを配置したり、配置したりするための議論は何ですか？Programmers.seで。 これに関するdbaについての議論はすでに見つかりませんでした。元の投稿にはそれがすべて記載されています。 ほとんどのソフトウェア開発者は、アプリケーションロジックをアプリケーションレイヤーに保持することを望んでおり、おそらくここに保持するのが自然であると感じるでしょう。データベース開発者は、トリガーおよびストアドプロシージャとして、アプリケーションロジックをデータベース層に配置したいと考えているようです。 個人的には、アプリケーション層にできるだけ多くの層を残して、層のデバッグを容易にし、層の責任を分離しておくことを好みます。 これについてどう思われますか。また、データベースレイヤーに実装しても問題ない、またはすべきでないものは何ですか？ NB私はその質問のOPではありませんが、元の文言はそのまま残しました。

74 database-design 

大量の電気データと温度データを保存および分析する必要があるアプリケーションを作成しています。 基本的には、過去数年間および数万の場所について今後数年間にわたって大量の時間ごとの電力使用量の測定値を保存し、それほど複雑ではない方法でデータを分析する必要があります。 （今のところ）保存する必要がある情報は、ロケーションID、タイムスタンプ（日付と時刻）、温度と電気使用量です。 格納する必要があるデータの量については、これは概算ですが、これらの行に沿ったもの： 20 000以上の場所、1か月あたり720レコード（1時間あたりの測定、1か月あたり約720時間）、120か月（10年前） ）そして何年も先。簡単な計算により、次の結果が得られます。 20の000の位置は、720のレコード（10年前）×120ヶ月= X 1つの728 000 000レコード。 これらは過去のレコードです。新しいレコードは毎月インポートされるため、1か月あたり約20 000 x 720 = 14 400 000の新しいレコードになります。 合計ロケーションも着実に成長します。 そのすべてのデータで、次の操作を実行する必要があります。 特定の日付および期間のデータを取得します。日付01.01.2013から01.01.2017の間、および07:00から13:00の間の特定のロケーションIDのすべてのレコード。 特定の日付と時間範囲に対する簡単な数学演算、たとえば、07：00から13:00までの5年間の特定のロケーションIDのMIN、MAX、およびAVG温度と電力使用量。 データは毎月書き込まれますが、何百ものユーザーによって（少なくとも）常に読み取られるため、読み取り速度は非常に重要です。 NoSQLデータベースの経験はありませんが、私が収集したものから、ここで使用するのに最適なソリューションです。最も人気のあるNoSQLデータベースについて読んだことがありますが、それらは非常に異なっており、非常に異なるテーブルアーキテクチャを可能にするため、使用するのに最適なデータベースを決定することができませんでした。 主な選択肢はCassandraとMongoDBでしたが、私は非常に限られた知識しかなく、大きなデータとNoSQLに関しては実際の経験がないため、あまり確信がありません。また、PostreSQLはそのような量のデータを適切に処理することも読みました。 私の質問は次のとおりです。 このような大量のデータにNoSQLデータベースを使用する必要があります。そうでなければ、MySQLに固執できますか？ どのデータベースを使用すればよいですか？ 特定の期間のデータをすばやく取得および処理するために、日付と時刻を別々のインデックス付き（可能な場合）列に保持する必要がありますか、またはタイムスタンプを単一の列に保持することでこれを実行できますか？ ここで時系列データモデリングアプローチは適切ですか？そうでない場合は、適切なテーブル設計のためのポインターを教えてもらえますか？ ありがとうございました。

74 database-design  database-recommendation  nosql 

慣れていると思われる形式（エンティティごとに1行、属性ごとに1列）からデータベースをリファクタリングしたクライアントからの日常的なデータフィードを処理します。 変更前：属性ごとに1列 ID Ht_cm wt_kg Age_yr ... 1 190 82 43 ... 2 170 60 22 ... 3 205 90 51 ... 後：すべての属性に1つの列 ID Metric Value 1 Ht_cm 190 1 Wt_kg 82 1 Age_yr 43 1 ... 2 Ht_cm 170 2 Wt_kg 60 2 Age_yr 22 2 ... 3 Ht_cm …

68 database-design  schema  eav  ontology 

データベースを設計する最も簡単で効率的な方法は何ですか？私の観点から、アプリケーションのデータストア設計にはいくつかのオプションがあります。 アプリケーションコードを記述する前に、できる限りデータベースを最適に設計します。これにより、基本的なデータ構造を利用できるという利点が得られます。私の意見では、この欠点は、アプリケーションの開発サイクル全体でデータの内容/場所/方法が変化するため、アプリケーションの仕様として多くの変更が加えられることです。 アプリケーションが実を結ぶようにデータベースを設計します。アプリケーションの作成時にデータベースオブジェクトが必要な場合は、アプリケーションと並行して（年代順に）データベースを開発します。利点は、データベース構造の変更が少ないことです。欠点は、アプリケーションコードとデータベース開発の間で時間と開発の労力が分割されることです。 あなたの経験では、最も生産的で効率的な方法は何だと思いますか？

57 database-design 

単純な銀行データベースのスキーマを書いています。基本的な仕様は次のとおりです。 データベースは、ユーザーと通貨に対するトランザクションを保存します。 すべてのユーザーは通貨ごとに1つの残高を持っているため、各残高は特定のユーザーと通貨に対するすべてのトランザクションの合計です。 残高をマイナスにすることはできません。 銀行のアプリケーションは、ストアドプロシージャを介してデータベースとのみ通信します。 このデータベースは、1日に数十万件の新しいトランザクションを受け入れ、さらに高いレベルでクエリのバランスを取ることを期待しています。残高を非常に迅速に提供するには、事前に集計する必要があります。同時に、残高が取引履歴と矛盾しないことを保証する必要があります。 私のオプションは次のとおりです。 別のbalancesテーブルを用意して、次のいずれかを実行します。 トランザクションをテーブルtransactionsとbalancesテーブルの両方に適用します。TRANSACTIONストアドプロシージャレイヤーのロジックを使用して、残高とトランザクションが常に同期されるようにします。（Jackによるサポート。） transactionsテーブルにトランザクションを適用balancesし、トランザクション量でテーブルを更新するトリガーを使用します。 balancesテーブルにトランザクションを適用transactionsし、トランザクション量とともにテーブルに新しいエントリを追加するトリガーを使用します。 ストアドプロシージャの外部で変更が行われないようにするには、セキュリティベースのアプローチに頼る必要があります。そうしないと、たとえば、一部のプロセスがtransactionsテーブルにトランザクションを直接挿入し、スキーム1.3の下で関連するバランスが同期しなくなる可能性があります。 balancesトランザクションを適切に集約するインデックス付きビューを用意します。残高はトランザクションと同期するようにストレージエンジンによって保証されているため、これを保証するためにセキュリティベースのアプローチに依存する必要はありません。一方、ビュー（インデックス付きビューでも）にCHECK制約を設定することはできないため、バランスを負以外に強制することはできません。（Dennyによるサポート。） transactionsテーブルだけがありますが、そのトランザクションの実行直後に有効な残高を保存するための追加の列があります。したがって、ユーザーと通貨の最新のトランザクションレコードには、現在の残高も含まれます。（Andrewが以下に提案。garikが提案したバリアント。） この問題に最初に取り組んだとき、私はこれら 2つの議論を読み、オプションを決定しました2。参考のために、ここでそれのベアボーン実装を見ることができます。 このようなデータベースを高負荷プロファイルで設計または管理しましたか？この問題の解決策は何ですか？ 私が正しいデザインを選んだと思いますか？留意すべきことはありますか？ たとえば、transactionsテーブルのスキーマを変更するには、balancesビューを再構築する必要があることを知っています。データベースを小さく保つためにトランザクションをアーカイブしている場合でも（たとえば、他の場所に移動してサマリートランザクションに置き換えることで）、スキーマの更新ごとに数千万のトランザクションからビューを再構築する必要がある場合、展開ごとのダウンタイムが大幅に長くなる可能性があります。 インデックス付きビューを使用する方法がある場合、マイナスの残高がないことをどのように保証できますか？ トランザクションのアーカイブ： アーカイブトランザクションと上記の「サマリートランザクション」について少し詳しく説明します。まず、このような高負荷システムでは定期的なアーカイブが必要になります。古い取引を別の場所に移動できるようにしながら、残高と取引履歴の間の一貫性を維持したいと思います。これを行うには、アーカイブされたトランザクションのすべてのバッチを、ユーザーと通貨ごとの金額のサマリーに置き換えます。 したがって、たとえば、このトランザクションのリスト： user_id currency_id amount is_summary ------------------------------------------------ 3 1 10.60 0 3 1 -55.00 0 3 1 -12.12 0 アーカイブされ、これに置き換えられます： user_id currency_id amount is_summary ------------------------------------------------ 3 1 -56.52 1 …

57 sql-server  sql-server-2008  database-design  aggregate  materialized-view 

stackoverflowポッドキャストから、Fog CreekはFogbugzの顧客ごとにデータベースを使用していることを覚えています。これは、Fogbugz On Demandサーバーに何万ものデータベースがあることを意味すると思います。 Webアプリの開発を始めたばかりで、同様の問題を解決する必要があります（独自の分離データを持つ多くの顧客）。 顧客ごとにデータベースを使用する場合、どのような問題が予想されますか？どうすれば解決できますか？ 私の最初の考え 顧客ごとのデータベースの利点 よりシンプルなデータベーススキーマ シンプルなバックアップ-他の顧客に実際に影響を与えることなく、各顧客を順番にバックアップできます。 特定の顧客データを簡単にエクスポートできます。 キャッシュパフォーマンスの向上-よりアクティブなテーブルの1つへの書き込みは、書き込みを実行した単一の顧客にのみ影響します。 ハードウェア全体で簡単に拡張できます。たとえば、1台から2台のサーバーに移動する必要がある場合、顧客の半分を新しいサーバーに移動するだけです。 欠点 MySQLは5,000個のデータベースに対応できますか？パフォーマンスは低下しますか？ スキーマへの変更は、すべてのデータベースに複製するのが難しい場合があります。スキーマのバージョン管理や、データベースをあるバージョンから別のバージョンに移行する方法を理解するスクリプトなど、このための自動化された計画が本当に必要になります。 すべてのお客様に共通することを行うことは、厄介または不可能かもしれません 上記と似ていますが、すべてのお客様に対して実行したい分析は不可能かもしれません。たとえば、すべての顧客の使用状況をどのように追跡する必要がありますか？

49 mysql  database-design  database-recommendation 

私は、SQLite3からPostgreSQL 9.3にかなりシンプルな内部データベース駆動型アプリケーションを移行し、DBのアクセス許可を強化したいと思っています。 アプリケーションは現在、データを更新するコマンドで構成されています。そして、それをクエリするもの。当然、他の方法でデータベースを維持する必要もあります（新しいテーブル、ビュー、トリガーなどを作成します）。 このアプリケーションは、最初はサーバーでホストされる唯一のアプリケーションですが、将来的に他のデータベースを備えたサーバーでホストされる可能性があると仮定して、それが必要になった場合に後でスクランブルする必要はありません未来。 これらはかなり一般的な一連の要件になると思いますが、この種のユーザー/特権の分離を使用して、PostgreSQLで新しいデータベースをセットアップする方法を説明する簡単なチュートリアルを見つけるのに苦労しています。参照は、グループ、ユーザー、ロール、データベース、スキーマ、およびドメインに関する詳細に続きます。しかし、私はそれらを混乱させます。 これは私がこれまでに試したものです（psql「postgres」として）： CREATE DATABASE hostdb; REVOKE ALL ON DATABASE hostdb FROM public; \connect hostdb CREATE SCHEMA hostdb; CREATE USER hostdb_admin WITH PASSWORD 'youwish'; CREATE USER hostdb_mgr WITH PASSWORD 'youwish2'; CREATE USER hostdb_usr WITH PASSWORD 'youwish3'; GRANT ALL PRIVILEGES ON DATABASE hostdb TO hostdb_admin; GRANT CONNECT ON …

48 postgresql  database-design  permissions 

「データベースレイヤーにアプリケーションロジックを配置することに対する、またはそれに対する引数は何ですか？」という質問のdba.seバージョンとProgrammers.seバージョンに関する回答とコメント 一部の職場のDBAとプログラマーの格差について非常に明らかにしています。 このような問題に関してプログラマーとより良く働くために、DBAはどのように異なってできるでしょうか？ 我々がすべき： 特に適切に設計されたデータベースを使用する場合、プログラマーが直面する困難を理解するために使用しているツールと言語を学習しますか？ データベースと、データベースレベルでビジネスロジックを持つことの利点について、プログラマーの教育を強化することをお勧めしますか？ よりプログラマーにとって使いやすいトランザクションAPIを使用するなどして、データへのインターフェイスを定義する方法を変更します（たとえば、後方互換性などの問題のために）。

46 database-design  best-practices