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

1日あたり約400万件のレコードがあり、オンラインで7年間の価値を維持する必要があるため、検索できるようにする必要がある102億件のレコードを調べています。ユーザーは、検索がUIに十分な速さで、3〜5秒になることを期待しています 私の制御が及ばないため、既製のデータベースソリューションを使用することはできません。これは、データベースを別のチームに渡して管理する必要があるためです（質問しないでください）。つまり、ハードウェアを最適化する機能を失い、彼らはデータベースのための万能サービスを提供し、GBによって（内部で）課金されるソフトウェア。私は私がポイントを作ることを示唆するコメントを受け取るつもりだと確信しています、私はすでに持っており、経営陣は彼らが私に何をするように求めているかはばかげています。 私はソリューションの要としてLuceneを使用することを検討してきました。タイプ別および日別にパーティション化された実際のデータをフラットファイルに保存します。次に、Luceneドキュメントを使用して、検索対象のいくつかのフィールドにインデックスを付けます。唯一の「Stored」フィールドはレコードのIDです（そのため、フラットファイルから読み取ることができます）。 私は正確にLuceneまたはハードドライブにこだわっていませんが、私の理解によれば、インデックスを検索するための最初のIO /シーク時間があります。その後、すべてのLuceneドキュメントIDがあるとき、さらにIOが発生するドキュメントを読みます/ seeking時間、それから私はフラットフラットから実際のレコードを読みます...データセットのサイズを考えると、これは非常に速くなるとは想像できませんが、これは少し心配ですか？ Luceneの最大ドキュメントサイズはインデックスあたり21億です。そのため、ここでは複数のインデックスが必要になります。 このアプローチは、一見すると、うまくいくように見えますか？ 保存しているデータはイベントアクションデータです。ほとんどのクエリは、イベントIDでグループ化し、特定のイベントの最後のイベントアクションの詳細を取得します。一部のクエリは、大規模なセットイベントとそれらの個々のイベントアクションを分析します。

8 design  database-design 

データベースの内部を知っている人にとって、これは簡単な質問かもしれませんが、データベースに大きなBLOB（たとえば、400 MBの映画）を格納するとパフォーマンスが低下することになっている理由を明確に説明できますか？これはインターネット全体でよく見られる申し立てですが、実際に説明されたことはありません。 具体的には、SharePoint / MSSQLのパフォーマンス、つまりファイルアップロードのパフォーマンス、サイトの閲覧、リストの表示、ドキュメントのオープンなどについて言及しています。データベースが大きくなりすぎると、動作が遅くなると言われています。ファイルシステムへのBlobの外部化（SharePointではリモートBlobストレージと呼ばれ、データベースからファイルを移動し、参照のみを残します）はこれをある程度解決するはずですが、正確には-最下位レベルで-違いは何ですか？データベースに巨大なファイルが保存されている場合、バックアップに時間がかかることは明らかです...しかし、どの操作が正確に影響を受け、その基本的なメカニズムは何ですか（つまり、データベースの外部のファイルシステムに保存されているファイルは、どのようにアクセスまたは保存されますか？） 列を含む単純なテーブルをID(guid, PK), FileName(string), Data(varbinary(max))考えてみてください-大きなData列は、Webサイトにファイルのリストを表示する（内部的には実行することを意味しますSELECT FileName FROM table）、または新しい行を挿入するなどの操作を本当に遅くしますか？実際のバイナリコンテンツの列にインデックスが付けられるのとは異なります。 このような質問が既に出されていることは知っていますが、十分な説明が見つかりません。

8 database  database-design  sql-server  file-systems  sharepoint 

バックグラウンド 「すべて-PK-必須被サロゲート」のアプローチは、中には存在しないコッドのリレーショナル・モデルまたは任意のSQL標準（ANSI、ISOまたは他）。 正規の本もこの制限を回避しているようです。 Oracle独自のデータディクショナリ方式では、一部のテーブルでは自然キーを使用し、他のテーブルでは代理キーを使用します。これらの人々はRDBMSの設計について1つか2つ知っている必要があるので、これについて触れます。 PPDM（Professional Petroleum Data Management Association）は、同じ標準的な本が推奨する次のことを推奨しています。 次の場合は、代理キーを主キーとして使用します。 自然キーやビジネスキーはありません 自然キーまたはビジネスキーが不適切（頻繁に変更） レコードを挿入する時点では、自然キーまたはビジネスキーの値は不明です。 複数列の自然キー（通常はいくつかのFK）が3列を超えるため、結合が冗長になります。 また、自然なキーは不変である必要があると述べている正規のソースを見つけていません。私が見つけたのは、それらが非常にエスタブルである必要があるということです。 これらの人々はRDBMSの設計についてもある程度知っている必要があるため、PPDMについて触れます。 「全代理」アプローチの起源は、いくつかのORMフレームワークからの推奨に由来するようです。 このアプローチでは、多くのビジネス分析を行う必要がなく、SQLコードの保守性と読みやすさを犠牲にして、迅速なデータベースモデリングが可能になるのは事実です。すべてのテーブルを結合する必要があるなどの日常的なタスクを犠牲にして、将来発生する可能性のあるものや発生しない可能性があるもの（自然なPKが変更されたため、RDBMSカスケード更新機能を使用する必要があります）クエリを実行し、データベース間でデータをインポートするためのコードを記述する必要があります。それ以外の点では非常に順調な手順です（PK衝突を回避する必要があり、事前にステージ/同等テーブルを作成する必要があるため）。 他の議論は、整数に基づくインデックスはより高速ですが、それはベンチマークでサポートされなければならないということです。明らかに、長く変化するvarcharはPKには適していません。しかし、短い固定長のvarcharに基づくインデックスは、整数とほぼ同じくらい高速です。 質問 -「all-PK-must-be-surrogates」アプローチをサポートする正規のソースはありますか？ -Coddのリレーショナルモデルは新しいリレーショナルモデルに置き換えられましたか？

8 database-design  client-relations  rdbms  surrogate-keys 

（電気）部品を扱うツールを開発しています。パーツは、作成、表示、変更、削除、グループ化などができます... この質問を将来の訪問者に役立つようにするために、DBのパーツを管理することは、DBのどのパーツ（CD、車、食べ物、学生など）に関係なく非常に一般的であるため、この質問を普遍的にします。 3つの異なるDB設計を考えています。 特殊なパーツ属性にパーツテーブルと派生テーブルを使用する。 Parts (id, part_type_id, name) PartTypes (id, name) Wires (id, part_id, lenght, diameter, material) Contacts (id, part_id, description, picture) 専用のパーツテーブルのみを使用します。 Wires (id, name, lenght, diameter, material) Contacts (id, name, description, picture) すべての値を含むParts-、PartTypes-、ValueTypes-、PartValuesテーブルを使用する。 PartTypes (id, name) ValueTypes (id, part_type_id, name) Parts (id, part_type_id, name) PartValues (part_id, value_type_id, value) …

8 database-design 

次の属性を持つItemクラスがあります。 itemId,name,weight,volume,price,required_skills,required_items。 最後の2つの属性は複数値になるため、それらを削除して次のような新しいスキームを作成します。 itemID,required_skill（itemIDは外部キー、itemID and required_skillは主キーです。） 今、私はこの新しいテーブルを作成/使用する方法に困惑しています。私が思いついたオプションは次のとおりです。 1）ItemsとRequired_skillsの関係は1対多であるため、requiredSkillクラスを作成することができます。これは、one_to Itemにn個のRequiredSkillが含まれています。その後、私は行うことができますItem.get(1).requiredskills。これは私にとって最も論理的に聞こえ、次のようなメソッドとクエリを提供します。 sugar.components.create :raw_material => water.name sugar.components.create :raw_material => sugarcane.name sugar.components sugar.components.count 2）required_skillsは（ルールに似ているため）定数と考えることができるため、ハッシュデータベース、gdbmデータベース、または別のsqlテーブルに入れて、そこからクエリを実行することもできます。 私の質問は：データマッパーのモデルレステーブルのようなものはありますか？データマッパーはテーブルの作成と整合性に責任があり、データマッパーの方法でそれをクエリすることができますが、SQLで行うようにクラスを必要としません？ 最初の方法を使用して問題を解決しました。正規化プロセスごとに新しいクラスを作成しました（上記の1対多の関連付けのように見えます）。しかし、私はオブジェクト指向プログラミングに不慣れであり、そのような正規化ごとに新しいクラスを作成することが、データマッパーでそれを行う通常の方法であるのか、それともハックであるのかわかりません。これと、これを行うためのより良い方法があるかどうかは、私が知りたいことです。 あずきっく 再読datamapper.org団体に数回、今私はDataMapperのは確かに参加するために別々のクラスを必要としていることがわかります。だからあなたは私の質問に答えました。しかし、ロバート・ハーベイが賞金を置いたので、私はダイナミックな方法についての応答をもう少し待つ責任を感じています。 あなたのコードは不満を述べましたCannot find the child_model Container for Item in containers。私はそれを以下のような自己参照関連付けの2番目の例でうまく動作させることができました（他のものへの参照としてここに置く）： class Item class Link include DataMapper::Resource storage_names[:default] = "requirement_links" belongs_to :require, "Item", :key => true belongs_to :required, …

8 ruby  database-design  orm 

私は常に、データベースの正規化の最高の正規形を追求するように教えられ、3NFを達成するためのバーンスタインの合成アルゴリズムを教えられました。これは非常によくできており、一貫性を維持しながらフィールドを変更できることを知って、データベースを正規化するのは良い感じです。 ただし、パフォーマンスが低下する可能性があります。ですから、非正規化時にスピードアップ/スローダウンを予測する方法があるのか​​と思います。このようにして、3NFを特徴とするFDのリストを作成し、可能な限り非正規化することができます。非正規化が多すぎると、スペースと時間が無駄になると思います。たとえば、巨大なブロブが複製されたり、トランザクションを使用して複数のフィールドを更新する必要があるために一貫性を維持することが困難になったりするためです。 概要：3NF FDセットと一連のクエリがある場合、非正規化のスピードアップ/スローダウンを予測するにはどうすればよいですか？論文へのリンクも高く評価されています。

8 database-design  relational-database  rdbms 

次の質問では、フィールドとテーブルの名前がIDを保護するために変更されています。 2つのデータベース列がある場合： MONKEY_DATE DATETIME NULL (with data e.g. 2012-05-14 00:00:00.000) MONKEY_TIME DATETIME NULL (with data e.g. 1753-01-01 16:30:53.025) 時間フィールドの日付コンポーネントは、ほとんどが1753年1月1日に設定されています...しかし、一部のデータは1899年1月1日で、一部は1900年1月1日です。 これらの列をクエリおよびレポートするコードを維持すると、私（および私たちのチーム）は2つの列をマージすることで簡単に解決できる頭痛の種を引き起こします。しかし、経験（およびTerry Goodkind）は、決して簡単なことはないことを教えてくれました。これが頭痛の原因であるいくつかの例を以下に示します。 私のアプローチ 次のアプローチには、2つの列をマージするという望ましい効果があると思います。 SQLを使用してデータを更新し、日付フィールドの値と時間フィールドの値の両方を同じ値に設定します。これは、日付フィールドの日付コンポーネントと時間フィールドの時間コンポーネントの混合です。 MONKEY_DATEフィールドのみを使用して新しいコードを記述します 最終的にMONKEY_TIMEフィールドと日付/時刻コンポーネントSQLを段階的に廃止します（例を参照） MONKEY_TIMEをドロップ これは、すぐに行ってシステム全体に遡及的な変更を加える必要がないことを意味します。既存のコードはすべて引き続き機能します...そして、正しい方法で作業を開始できます。 ＃1のSQLは（Oracle）の場合があります。 UPDATE MONKEY SET MONKEY_DATE = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') || TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), 'MM/DD/YYYY HH24:MI:SS') MONKEY_TIME = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') || TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), …

8 design-patterns  sql  database-design  decisions 

私が持っているPBFファイル国に関する以下の情報が含まれています。 それぞれ独自の経度、緯度、プロパティを持つノード。2Dスペースにポイントを格納するために使用されます。 それぞれのプロパティを持つ方法は、ノードを介して接続されます。道路、境界を保存するために使用されます。 このファイルの圧縮形式は80 MBですが、圧縮解除してDBに保存すると、592 MBになります。 ええ、それはベルギーだけの国のためのものです。フランス、ドイツ、イタリアを一緒に保管することを想像してください。 たとえば、アントワープからブリュッセルを通ってシャルルロワまでの単一の高速道路を見てみましょう。これは、高速道路のすべてのターンを格納するための大量のノードで構成されますが、これらすべてのターンが必要ですか？疑わしい。 私が何ができるようになりたいのか教えてみましょう： さまざまなズームレベルで地図を表示したい。少なくとも大都市、小都市、街路レベル。 2点間のルーティング情報を取得できるようにしたい。 GPS位置に最も近い道路を計算できるようにしたい。 データベース内のインデックスを使用して、場所を検索します。 ただし、最も重要なのは、データベースがモバイルデバイスに保存されるため、データベースが大きくなりすぎないことです。 そこで、2つの手法の組み合わせについて考えました。 すべての個々のノードの保存/処理を回避するための、表示目的の画像タイル。 道路に関する情報とともに、ルート情報の道路の端点を保存します。 この問題は、この情報だけではGPS位置に最も近い道路を計算できないことです。高速道路の曲がりを想像すると、2つの端点だけで高速道路にいると判断できません。エンドポイント間で中間ノードを保存することを考えていましたが、生成には非常にコストがかかると思います。また、道路の端点（Tスプリットのようなもの）を決定することは、T字型スプリットの上部に中点を保存する必要があるかどうかを理解する必要があるため、それほど簡単なことではありません。 したがって、画像タイルを使用すると表示が簡単です。しかし、ルーティングとGPS位置検索を行う簡単な方法を見つけることができません。どのようなストレージテクニックを検討する必要がありますか？80 MBファイルがのデータベースに変わるのは少し不便592 MBですが、そのサイズをできるだけ小さくしたいと思います... これをできるだけ効率的に行うにはどうすればよいですか？ディスクとCPUに関して。WP7をターゲットにしています...

8 algorithms  database-design  storage  map  indexing 

現在、このIDの使用状況（たとえば、MxNテーブル）が表示されない場合でも、データベースのすべてのテーブルにデフォルトでIDフィールドを追加するのは、この設計の良し悪しですか？

8 database-design