sql-server - SQL Server がフラットファイルよりもはるかに優れている理由を説明するために使用する引数

Question

私の会社の上層部は、親しい友人から、フラットファイルが進むべき道であり、私たちが行うすべてのことを SQL Server からフラットファイルに切り替える必要があると言われました。300 以上のサーバーと数百の異なるデータベースがあります。私が関与しているほんの数件から、かなりの数のレコードに 100 億を超えるレコードがあり、1 日あたり 100,000 件以上の新しいレコードがあり、更新の数は誰にもわかりません... 私と他の数人が応答を考え出す必要がありますなぜこれをしてはいけないのかを述べています。私たちのもののほとんどは、いくつかのレガシー ASP を含む ASP.NET です。フラットファイル (ネットワークに保存されている) とネットワーク経由の SQL との間の同じやり取りをテスト/計測する単純なコンソールアプリを作成し、大量の挿入、検索、更新などを行い、ネットワークのランダムな切断などを行うことを考えました。これは、フラットファイルがいかに悪いかを彼らに示します。

応答にはどのようなものを使用すればよいですか? これを説明するには、デモコードをどうすればよいですか?

これまでの私のソートリスト：

安全
同時アクセス
大量のデータでのパフォーマンス
そのような大規模な書き換え/切り替えと莫大な費用を行うのにかかる時間
取引の欠如
リレーショナルデータをフラットファイルにマップするための PITA
NTFS は、ディレクトリ内の大量のファイルを適切にサポートしていません
アドホックなデータ検索/操作の欠如
データの整合性の強化
ネットワーク停止からの復旧
他のクライアントの変更がコミットされるのを待っている間のクライアントの遅延
ほとんどの人は、正当な理由により、このタイプのストレージにフラットファイルを使用するのをかなり前にやめました。
ロードバランシング/レプリケーション

今すぐ止めることができなければ、いつかデイリー WTF の素晴らしい投稿になるのではないかと心配しています。

さらに

この戦いで HIPPA に関する何かを使用できるかどうか知っている人はいますか? 私たちの記録の多くは患者の記録です...

score 13 · Accepted Answer

データの整合性。まず、データベースで強制することができますが、フラットファイルでは強制できません。次に、行の孤立を防ぐために、異なるエンティティ間で参照整合性を確保できます。
データの性質に応じたストレージの効率。データが自然にエンティティに分割される場合、データを結合するためにフラットファイルの場合に書き込む必要がある追加のコードの観点から、データベースは多くのフラットファイルよりも効率的です。
ネイティブクエリ機能。フラットファイルではできないのに対し、データベースに対してネイティブにクエリを実行できます。フラットファイルの場合、ファイルを他の環境（C＃アプリケーションなど）にロードし、その機能を使用してファイルに対してクエリを実行する必要があります。
フォーマットの整合性。データベース形式はより厳格であり、より一貫性があることを意味します。フラットファイルは、フラットファイルを読み取るコードが破損するように簡単に変更できます。違いは＃3に関連しています。データベースでは、スキーマが変更された場合でも、ネイティブツールを使用してスキーマに対してクエリを実行できます。フラットファイル形式が変更された場合、それを読み取るコードが壊れている可能性があるため、効果的に検索を行う必要があります。
「普遍的な」言語。SQLはどこにでもありますが、フラットファイルの構造ははるかに順応性があります。

score 9 · Accepted Answer

データの破損についても言及します。最近のほとんどの SQL データベースでは、サーバーの電源が切られたり、サーバーインスタンスがクラッシュしたりして、データが失われることはありません (すべきではありません)。フラットファイルは実際にはそうではありません。

また、検索時間についても言及します。おそらく、1mil のエントリを持つ単純なフラットファイルデータベースを作成し、MS SQL と比較して検索時間を表示することさえできます。インデックスを使用すると、SQL データベースを何千倍も速く検索できるはずです。

また、フラットファイルをどれだけ迅速に書き留めるかにも注意してください。「多くの場合、それは良い考えですが、私たちの場合は....」とまで言えます。こうすれば、他のビューを聞いていないように聞こえることはありません。このような状況でのタクトは、考慮すべき重要なことです。彼らはひどく間違っているかもしれませんが、上司にそのことを納得させなければなりません.

score 5 · Accepted Answer

フラットファイルを使用することで、彼らは何を得ますか? 変換プロセスには何百時間もかかります。フラットファイルは、その投資に対してどれくらいの速さでプラスの利益を生み出すことができますか? 大まかな費用の見積もりを提供します。技術的な考慮事項をお金 (コスト) に変換すると、問題が彼らの視点に置かれます。

データ変換だけでなく、データベースの機能を複製するための隠れたコストを追加します...

索引付け
取引処理
ロギング
アクセス制御
パフォーマンス
安全

score 4 · Accepted Answer

データベースを使用すると、任意の数の異なる列を検索して、データを簡単にインデックス付けして、特定のレコードまたはレコードのグループを作成できます。

フラットファイルでは、独自のインデックス作成メカニズムを作成する必要があります。データベースがすでに行っている場合は、すべての作業を再度行う必要はありません。

score 4 · Accepted Answer

「テキストファイル」を使用する場合は、その上にインターフェイスを構築する必要があります。これは、Microsoft が既に作成しており、SQL Server と呼んでいます。

これらすべてのリソースを自作のデータベースシステムの構築に費やすことが会社にとって理にかなっているのか (それが実際にそうであるため)、またはこれらのリソースをビジネスに集中して費やす方がよいかどうか、マネージャーに尋ねてください。

パフォーマンス: SQL Server は、便利に検索可能なデータを格納するように構築されています。検索/挿入/削除を念頭に置いて構築されたメモリ内のデータ構造が最適化されています。定期的にクエリされるデータがメモリに保持されるため、ディスクの使用率が低下します。
ビジネスパートナー: サードパーティ企業との B2B を計画している場合、SQL Server にはリンクサーバーと呼ばれる機能が組み込まれています。ファイルがたくさんしかない場合、データの相互接続が不可能なため、ビジネスパートナーはあきらめてしまいます。もう一度車輪を再発明し、ビジネスパートナーごとにインターフェイスを構築する場合を除きます。
クラスタリング: SQL Server でサーバーを簡単にクラスタ化して、高可用性と速度を実現できます。これは、テキストベースのソリューションで可能なことよりもはるかに優れています。

score 2 · Accepted Answer

理由を挙げ始めることすらできないと思います。頭が爆発するのではないかと思います。私はあなたを助けるためにしかし危険を冒します...

ネットワークの停止をシミュレートし、その時点でファイルの1つに何が起こるかを示します
テキストファイルがACIDテストに合格しないため、半分コミットされたトランザクションの恐怖をデモします
マルチユーザーアプリケーションの場合は、500の接続がすべて同じテキストファイルを更新しようとしているときにクライアントが待機する必要がある時間を示します
ビジネス上の意思決定を行うための最善のアプローチが、お金を払っていてドメインを知っている専門家（この場合はIT）に耳を傾けることであり、手がかりがない仲間（おそらく除外する）ではない理由を丁寧に説明するようにしてくださいその最後のビット）
ビジネスの世界の99％（構成された数）がテキストファイルではなく重要なデータにリレーショナルデータベースを使用しているという事実に言及してください。おそらくその理由があります。
誰かがテキストファイルにアクセスして「haha！」と入力すると、アプリケーションがどうなるかを示します。整数であるはずの列の場合

score 2 · Accepted Answer

あなたのリストは良いスタートを切っています。追加する項目は次のとおりです。

データの整合性 - SQL エンジンには組み込みのメカニズム (関係、制約、トリガーなど) が用意されており、システム内の「不良」データの量を非常に簡単に減らすことができます。フラットファイルを使用する場合は、すべてのデータ制約を個別にハンドコードする必要があります。
アドホックデータ取得 - SQL エンジンは、SELECT ステートメントを使用して、ごくわずかなコードでデータをフィルタリングおよび要約する手段を提供します。フラットファイルを使用している場合、同じ結果を得るにはかなり多くのコードが必要です。

時間をかけてデータエンジンを構築したい場合は、これらのアイテムを複製できますが、ポイントは何でしょうか? SQL エンジンは、これらの利点をすでに提供しています。

score 2 · Accepted Answer

あなたが上場企業である場合、株主はこれが真剣に検討されていることを知っていれば十分です。「私たち」は皆、あなたの作戦の規模と範囲を考えると、これがばかげた提案であることを知っています。 患者の記録は、セキュリティ侵害からだけでなく、 損失への無責任な暴露からも保護する必要が あります。エグゼクティブが患者のことを少しでも気遣っているなら、これが彼らの最大の関心事であるべきです。

私は 1974 年から IBM 370 メインフレームを使用しており、DB2 が単純な古いフラットファイルである VSAM と ISAM を引き継いだ日は画期的な日でした。私は 25 年間、4 つのフレーバーの RDBMS を使用してきましたが、ストリーミングデータを除いて、フラットファイルストレージを振り返ることはありませんでした。

もし私が「あなた」の株を持っていたら、プロジェクトが軌道に乗った瞬間に急いでそれを捨てるのが適切だと思われます...

score 2 · Accepted Answer

あなたのリストは、データベースにこだわる理由の素晴らしい出発点です。

ただし、技術者と話している場合は、偏見があると思われる可能性があるため、推奨事項で技術的な理由を避けることをお勧めします。

フラットファイルデータストレージに対する私の2つのポイントは次のとおりです。

1) セキュリティ - HIPPA 監査では、患者データを安全な環境に保管する必要があります。一般的なデータベースシステム (Oracle、Microsoft SQL、MySQL) には、HIPPA 準拠のセキュリティアクセスを実装する方法があります。フラットファイルでこれを行うのは、せいぜい難しいでしょう。

補足: データベース内の患者名を暗号化して保護とコンプライアンスの層を追加し、DB が侵害された場合でも患者の記録が危険にさらされないようにする医療行為も見てきました。

2) レポート - 構造化されたデータベースシステムからのレポートは、シンプルで一般的です。このタスクを実行できる開発者は何十万人もいます。フラットファイルからのレポートには、平均以上の開発者が必要です。また、フラットファイルデータベースからレポートを作成するための一般的に受け入れられている方法がないため、ある開発者は別の開発者とは異なることを行う可能性があります。これは、自家製のフラットファイルシステムで作業できる人材プールに影響を与える可能性があり、最終的にはそのタイプのシステムをサポートする必要があるため、コストが上昇する可能性があります。

それが役立つことを願っています。

score 1 · Accepted Answer

プレーンテキストファイルを使用してリレーショナルモデルを作成するにはどうすればよいですか?

または、エンティティごとに異なるファイルを使用する予定ですか?

score 1 · Accepted Answer

プロファイルシステム:

安定 (コード行が少ない = バグが少なく、理解しやすく、信頼性が高い)
巨大なデータブロブで高速化
検索/並べ替えがやや遅い (ただし、SQL よりも高速になるsort 可能性order byがあります)

たとえば、ログファイルを作成するためにファイルシステムを選択したとします。データの複雑な分析を行う必要がない限り、DB にログインしても意味がありません。

プロ DB:

トランザクション (同時アクセスを含む)
膨大な量のレコードを検索できます (ただし、大量のデータは検索できません)。
クエリを使用してあらゆる種類の方法でデータを切り刻むのは簡単です (まあ、SQL と DB の特別な「奇妙さ」を知っていれば)

したがって、データをめったに追加する必要はなく、頻繁に検索する必要がある場合、特定の基準または集計値によってデータの一部を選択する場合は、DB が最適です。

score 1 · Accepted Answer

NTFS は大量の .txt ファイルを適切にサポートしません。フラットファイルシステムの開発方法によっては、ハードドライブの状態が問題になる場合があります。古いファイルシステムの多くは、大量の小さな .txt ファイルを使用してデータを保存します。これは悪い設計ですが、フラットファイルシステムが古くなるにつれて発生する傾向があります。

断片化が問題になり、あちこちでテキストファイルが失われ、少量のデータが失われます。データベースの設計に関しては、ハードドライブの状態が問題になることはありません。

score 1 · Accepted Answer

これは確かに、あなたの雇用主の側では、彼がすべてのフラットファイルを真剣に提案している場合、大したことです...

あなたはすでにその理由を知っています (ああ - レプリケーション / ロードバランシングをリストに追加してください) - あなたが今しなければならないことは、彼にその理由を納得させることです。これに対する私のアプローチは 2 つあります。

まず、SQL を使用して基本的な操作を実行するために現在使用しているツールでスクリプトを作成し、時間を計ります。次に、フラットテキストソリューションを機能させようとする別のスクリプトを作成し、パフォーマンスの違いを強調します。彼に両方のコードを渡して、あなたが不正行為をしていないことを彼に知らせてください。

テクノロジーは進化しており、20 年前に成功したからといって、現在その人が自動的に信頼できる意見を得る資格があるわけではないことを指摘してください。

また、テキストファイルの情報をデコード/エンコードする際のエラーの範囲、誰かがそれらを盗むのは些細なことであり、テキストファイルを使用するために現在のコードベースを適応させるコスト (見積もりを正当化する) について言及することもできます。

それから私は経営陣に深刻な質問をします - その中で最も重要なのは、他の個人の意見に基づいて「技術的な問題について技術スタッフを却下する準備ができているのはなぜですか」ということです - 特にその個人があまりよく知らない場合私たちのセットアップで...

また、「あなたを軽視するつもりはありませんが、会社の利益のためにこの時点で介入しなければならないと真剣に感じています...」というフレーズを使用します。

別のアプローチ - 立場を逆転させる - ワンダフル氏は、なぜテキストファイルが前進するのかについて議論を展開します。次に、a）何かを学ぶ（可能性は低い）か、b）彼の議論を完全に破壊する立場に立つ.

これで頑張ってください-私はあなたの痛みを感じます...

マーティン

score 1 · Accepted Answer

この議論に反論する最も簡単な方法は、フラットファイルを使用してこの規模のデータを処理するフォーチュン 500 企業を挙げてください。

リレーショナルデータベースを使用していないフォーチュン 500 企業の名前を挙げてください...

ケースを閉じました。

score 1 · Accepted Answer

最初に報復を受けて、今すぐデイリー WTF に投稿することをお勧めします。

あなたの質問に関して: ビジネス上の理由は、上司がすべてのシステムを書き直したい理由です。事実上、独自のデータベースシステムを作成する必要があります。

開発上の理由から、SQL サーバーエコシステム、すべてのライブラリ、ツール、ユーティリティにアクセスできなくなります。

おそらく、これを提案した人は、実際にあなたの会社と競合することを考えています.

score 0 · Accepted Answer

•そのような大規模な書き換え/切り替えを行うための時間と莫大な費用

新しいバグが発生するのは時間だけではありません。これらのプロポーションを書き直すと、現在機能しているものが壊れる可能性があります。

たった 1 つのシステムについてこのような書き直しを行うのにかかる時間と、変更が必要なシステムの数を彼に提示することをお勧めします。コストの見積もりが得られたら、できるだけ早くそこから実行します。

マネージャーは数字が好きなので、正式な書面による意思決定分析を行います。数値と並べて、利点とリスクによって 2 つの提案を比較します。維持費が0で、変換に100,000,000の費用がかかるようになると、彼らはポイントを獲得します.

score 0 · Accepted Answer

フラットファイルとSQLを区別しない人は、あなたが以前に言ったすべての議論を理解していません.

説明は、次のようにできるだけ単純にする必要があり
ます。SQL は、フラットファイルのある種の検索/同時実行ラッパーです。
現在存在するすべての問題は、会社がゼロからラッパーを作成しようとしても残ります。

また、現在の問題を解決するには、高度な BLL やインストール/アンインストールスクリプト環境などのスマートワードを使用する他の方法を提供する必要があります。:)

score 0 · Accepted Answer

あなたはエグゼクティブを話さなければなりません。言わずに、彼らがここで頭を悩ませていることを認識させてください. ここにいくつかの弾薬があります：

データベース理論は筋金入りのコンピューターサイエンスです。私たちは、何百万ものレコードを処理でき、誰もが倒産することなく災害に耐えられるスケーラブルなシステムを構築することについて話しています。

これは博士レベルの専門家の仕事です。彼らは 20 年間にわたってこの分野を改良してきましたが、その優れた点は、ビジネスシステムの構築に特化できることです。

必要に応じて、率直に言って、これは企業内で行われていないことを伝えてください。費用もかかりますし、仕上がりも悪くなります。これはまさに、開発者が再発明するのが好きな車輪のようなものであり、私の意見では、結果が販売可能な製品またはサービスになる場合にのみ行う必要があります。そして、そうではありません。

score 0 · Accepted Answer

ここで何かが本当に怪しいです。誰かが正しい用語 (「フラットファイル」) を理解しているとしても、それがどれほど馬鹿げたアイデアであるかを理解していない場合、それは単に足し合わされません。私は喜んであなたのマネージャーになりたいと思っていますが、あなたのマネージャーが話している相手は技術者ではありません。これは、翻訳の問題で失われたように聞こえます。

ドキュメント中心の環境にいる場合、リレーショナルデータベースから離れることは、実際にはいくつかの点で理にかなっていますが、従来のRDBMSの多くの利点は残っています。

したがって、SQL がフラットファイルよりも優れている理由を正当化する代わりに、問題を逆にして、フラットファイルが解決しようとしている問題は何かを尋ねます。私は、これがコミュニケーションの問題であるというオッズをお金に置きます.

そうではなく、あなたの会社が実際に「友人」の勧めに基づいて自社開発のフラットファイルシステムに DB を置き換えることを検討している場合、マネージャーになぜ彼が間違っているのかを納得させることは、あなたの心配のほとんどではありません。代わりに、ほこりを払い、履歴書を回覧し始めます。

sql-server - SQL Server がフラット ファイルよりもはるかに優れている理由を説明するために使用する引数

19 に答える 19

Related

Reference

sql-server - SQL Server がフラットファイルよりもはるかに優れている理由を説明するために使用する引数