リレーショナル データベースとスプレッドシートの使用について、いくつかの正当な議論を聞いたことがあります。リレーショナル データベースは、高速なレポートと (比較的言えば) 信頼性の高いデータ ウェアハウジングを提供します。スプレッドシートは軽量で高速に複製でき、組織内をさまざまなユーザーに簡単に移動できます。どちらの利点にも気付きますが、どのシナリオでどちらが優れているかを区別することはほとんどできず、常にデータベースを使用することになります。
開発中、データベースに構成設定を配置できる場合、他のオプションを考慮することを忘れがちです。私は、ユーザー メニュー、ワークフローとその順序、および定数がデータベース レベルで定義されているかなりの数のアプリに出くわしました。これらのエンティティがアプリケーション レベルからエンド ユーザーによって変更される可能性がある場合、これは良いことですが、そうではありませんでした。
では、データベース、構成ファイル、スプレッドシートの役割についてどうお考えですか?
古い格言はこれです。
スプレッドシートを使用して問題を解決すると、2 つの問題が発生します。
データベースはビジネスの記録です。長持ちする。永続。
他の構成ファイルは、他の構成情報用であり、長期的なビジネス記録ではありません。現在の設定などは永続的なビジネス レコードではなく、ビジネス レコードを処理する特定のソフトウェア構成の一部です。
スプレッドシートは -- まあ -- そのままです。複雑すぎて単純な構成ファイルにはなりません。単純すぎて実際のデータベースにはなりません。
それらを制御することは (ほとんど) 不可能であるため、データベースには 1 つの標準的で正確な冪等の結果が必要です。その管理されたソースからスプレッドシートを再構築できるはずです。
同様に、スプレッドシートのアップロードを受け入れる場合は、データを抽出する必要があり、(ほとんど制御不能な) ソース ドキュメントを再度参照する必要はありません。
私にとっては、すべてのコア データをデータベースに保存したいと考えています。2 つの理由:
データベースには、すべてのドメイン データと、場合によってはオンザフライ データ (ユーザー設定など) が含まれている必要があります。リレーショナル データベースが最も一般的ですが、一部のアプリには他のオプションがあります。
一方、構成ファイルには、システムで変更するすべての「パラメーター」が含まれている必要があります。急速に (オンザフライで) 変更されないもの。構成項目は柔軟ですが、簡単ではなく、通常はインターフェイスからではありません。コーダーだけが変更できるようにしたいパラメーターの場合、それはコード内にある必要があります（他の誰もアクセスできません）。
データ マイニングをいじる場合は、SQL クエリの結果を含む CSV ファイルを Excel に直接ダウンロードするための一般的なメカニズムを提供します。そうすれば、アプリケーションのスキーマを変更することなく、ピボット テーブルをいじることができます。
スプレッドシートはドキュメント、データベースは情報のリポジトリ、構成ファイルはアプリケーションの特定のインスタンスがどのように動作するかに関するルールを格納します。そのように考えれば、通常、電話をかけることは難しくありません。