database - データベースとプレーンテキスト

Question

小規模なプロジェクトを扱う場合、データを単純なテキストファイルやハッシュテーブルなどに保存する場合と、実際のデータベースを使用する場合の損益分岐点はどこだと思いますか? シンプルなデータ管理要件を持つ小規模なプロジェクトの場合、実際のデータベースは不要な複雑さであり、YAGNI に違反します。ただし、ある時点で、データベースの複雑さに見合うだけの価値があることは明らかです。問題が単純なアドホック手法には複雑すぎて、実際のデータベースが必要であることを示す兆候は何ですか?

注: エンタープライズ環境に慣れている人にとって、これはおそらく奇妙な質問のように聞こえるでしょう。しかし、私の問題領域はバイオインフォマティクスです。私のプログラミングのほとんどはプロトタイプであり、製品コードではありません。私は主にドメインの専門家であり、副次的にプログラマーです。私のコードのほとんどはアルゴリズム中心であり、データ管理中心ではありません。この質問の主な目的は、通常使用するアドホックな手法ではなく、コードで適切なデータベースを使用することを学ぶと、長期的にどれだけの作業を節約できるかを把握することです。

score 20 · Accepted Answer

1) 並行性。複数の人が同じデータセットにアクセスしていますか? 次に、独自のシステムを展開する場合、スケーラブルな方法でさまざまなリーダーとライターのすべてを仲介するためにかなり関与することになります。

2) フォーマットと関係: データがテーブル構造にうまく収まっていませんか? 長い塩基配列とかそういうの？それは本当に便利な表形式のデータではありません。

別の例: PSD をリレーショナル形式で保存するために Photoshop のようなソフトウェアを実装することを検討する人は誰もいないでしょう。データ構造がそのタイプのストレージやクエリパターンに実際には向いていないからです。

3) ACID (#1 の当然の結果): 原子性、一貫性、整合性、および耐久性がフラットファイルで問題にならない場合は、フラットファイルを使用します。

score 15 · Accepted Answer

私にとっては、複数の関係を含む方法でデータをクエリする必要がある場合、一線を越えています。ディスク上の 2 つのフラットなデータ構造を関連付けるのは非常に簡単ですが、それを超えると、SQL のようなセットベースの言語と正式なデータベースの関係によって実際に複雑さが軽減されます。

score 15 · Accepted Answer

ある時点で、データベースのクエリ機能を見逃してしまうと思いますが、最小限のデータベースの代替手段を検討できます。

SQLite (素晴らしい、ほぼ SQL-92 標準準拠)
shsql
SQL Server コンパクト

score 5 · Accepted Answer

小規模なプロジェクトの問題は、知らない間に大きくなってしまうことです。そして、それらが完了すると、SQL機能が不足し始めます。

アプリケーションの半分を切り離すことなく、必要に応じてデータベースを後で利用できるように常に設計してください。

score 4 · Accepted Answer

ドメイン固有のアプリケーションのニーズに完全に依存します。多くの場合、テキストファイル/バイナリファイルへの直接アクセスは、OS のファイルシステムのすべてのファイルアクセス機能を提供するだけでなく、非常に高速で効率的です。

さらに、プログラミング言語には、特定の解析用の組み込みモジュールが既にある (または簡単に作成できる) 可能性が高いです。

必要なものが多くの追加 (INSERTS?) であり、シーケンシャルアクセスが少ない/並行性がほとんどない/まったくない場合は、ファイルが最適です。

一方、並行性、非順次読み取り/書き込み、原子性、原子権限、データが本質的にリレーショナルであるなどの要件がある場合は、リレーショナルデータベースまたは OO データベースを使用する方が適切です。

非常に軽量 (300kb 未満)、ACID 準拠、C/C++ で記述され、非常にユビキタスなSQLite3で実現できることはたくさんあります (プログラミング言語 (たとえば Python など) にまだ含まれていない場合)。確かに利用可能なものがあります）。1GB 程度の db ファイルでも役に立ちます。

要件がより大きく、議論すらできない場合は、本格的な RDBMS を選択してください。

score 2 · Accepted Answer

バイオインフォマティクスで開発している種類のアプリケーションでは、特定の質問に答えるワンショットアプリケーション（多くの場合、計算のワークフローを定義するスクリプト）を実行していることが多く、質問に答えた後にこれらのアプリケーションを再利用することはほとんどありません。。
したがって、多くの場合、結果を保存するためのデータベースの作成は避ける必要があります。結局のところ、データベースの機能をあまり使用しないからです。

おそらく、いくつかのWebサービス、ファイル、またはデータベースにクエリを実行し、さまざまなソースから収集されたデータに対していくつかのローカルアルゴリズムを実行し、表形式または構造化された出力形式（xml、jsonなど）を生成します。

そのためには、Knime（またはInforsense KDE、AccelrysのPipelineパイロット、 Snaplogicなどの商用ソリューション）などのワークフローツールを使用することをお勧めします。これらのツールを使用すると、さまざまな形式と場所（rdbms、フラットファイル、Webサービス）でデータをクエリできます。）、アルゴリズムを実行し、ワークフローをユーザーに簡単に公開して特定のポイントで対話できるようにする強力なWebアプリを構築します）。

プロトタイプが「成長」し、ワークフローが出力するデータに基づいてより多くの機能を構築する必要があり、プロトタイプの出力が毎日変更される可能性が低い場合は、結果のサブセットをに保存することをお勧めします。データベース。これにより、BusinessObjects、Crystalレポート、jasperレポート、その他の利用可能なレポートソリューションなどの強力なレポートツールをプラグインして、スプレッドシートやcsvファイルよりも優れた形でデータをユーザーに表示できます。

最後に、一部の開発フレームワークでは、選択がより明確になります。MVCフレームワークを使用してWebアプリケーションを構築する場合、データはRDBMSに存在する可能性があります（ただし、ゲノムシーケンスをテーブル列に配置しないでください：- ））。

全体として、特定のアプリケーションごとのニーズに応じて、ケースバイケースで選択できます。

score 1 · Accepted Answer

まず、次のことを検討します。

データベースの初期サイズ: テーブル数、行数
どのくらいの速さで成長しますか？
データは頻繁にクエリされますか?

たとえば、個人用のレシピアプリを作成する場合、お気に入りのレシピを 50 個追加して開始し、年間 5 個以下のレシピを追加する可能性があることを知っています。そうは言っても、データストアのサイズがクエリに与える影響は最小限であるため、データベースがなくても簡単にやっていけます。

とはいえ、データ入力とクエリが発生するアプリケーションには、おそらくデータベースを使用するでしょう (小さな個人用レシピアプリであっても)。特に、フレームワーク (Rails など) でデータベース (主にテーブル、インデックス、および制約) をダムのままにしておくことができる場合は、多くのオーバーヘッドが追加されるとは思いません。スケールアップすることにした場合に、最終的にデータベースに移植しなければならない可能性が軽減されます。

score 1 · Accepted Answer

ソフトウェアでは、通常、XML 構成ファイルまたはレジストリ (ソフトウェアオプションなど) に値を格納することで問題を解決できます。オブジェクトを永続化する必要が生じたら、データベースに移動します。これは、リレーションとレポートが提供できる長期的な効果に比べて初期費用がそれほど高くないためです。

score 1 · Accepted Answer

SQL クエリが必要ですか、または必要ですか?

複数の人がデータにアクセスしたいですか?

データはリレーショナルですか?

これらの質問に「いいえ」と答えた場合、(おそらく) 完全なデータベースは必要ありません。

score 1 · Accepted Answer

バイオインフォマティクスについては、 Blast on DBに興味があるかもしれません。これに取り組んでいる人物は私の友人で、高速類似配列検索に取り組んでおり、この時点でデータベースを使用するよりも優れた独自のバイナリストレージを作成することを発見しました。

彼の解決策についての具体的な詳細はわかりませんが、コードを共有することでさえ、1つか2つのアイデアを彼にメールで交換できるでしょう。

score 1 · Accepted Answer

データの形式がわかっている場合は、開発がより高速/簡単であれば、フラットファイルで問題ありません。開発中にレコード形式が頻繁に変更されることが予想される場合は、ALTER TABLE を使用することをお勧めします。ファイルの多くの組み合わせに相当する結合を実装することを期待しない限り、(速度を重視する場合) フラットファイルも高速になる傾向があります。

開発中に RDBMS を使用する本当の利点は、データスキーマを柔軟に変更できることと、クエリを介してデータに簡単にアクセスできることです。

優れた設計では、データアクセスレイヤーを比較的分離した状態に保つことができます (懸念事項が分離されているため)。そのため、後でデータベースを再作成することは (面倒ではありますが) かなり簡単です。または、もちろん、データベースを使用して構造を開発する場合は、パフォーマンスを向上させるために、それらの構造が結晶化されたら、アプリをフラット/インデックスファイルに戻すことができます。

score 0 · Accepted Answer

バイオインフォマティクスの研究も行っている人として、データベースが必要であることが確実でない限り、この種のプロトタイププロジェクトにはデータベースを使用しないことをお勧めします。迷っている場合は、データベースレスソリューションを使用し、フラットファイルを使用してください。従来、バイオインフォマティクスの研究者はフラットファイルルートを使用してきたことに注意することも重要です。つまり、フィールド内のほとんどの種類のデータに対して明確に定義されたファイル形式があります。データベースソリューションを使用することにした場合、既存の研究プロジェクトとの互換性が損なわれる可能性があります。

score 0 · Accepted Answer

最も使い慣れた永続化テクノロジを使用し、十分にスケーリングします。

YAGNI は少なくとも、「既にあるもので生産性を発揮できない場合を除き、個人のスタックに新しいテクノロジを追加しないでください」という意味です。

私たちの多く (ほとんど?) にとって、データ永続化のコンフォートゾーンは SQL です。一部の人にとっては、それは XML かもしれません。それまでは自分で書かないでください（段落2を参照）。

database - データベースとプレーンテキスト

14 に答える 14

Related

Reference