データを挿入するたびに 'TABLE'を作成して削除しないでください。

Question

私はDBスキーマの友達と議論しました。

私たちのアプリは一種のcsvファイルを読み込んだ後、データ（ほぼ200行）をテーブルに挿入します。 時々、アプリケーションはファイル名でデータを削除する必要があります。

だから、私は、テーブルスキーマをfolloing示唆 - > [キー]、[テキスト]、[ファイル名]

ファイル名でデータを挿入することができ、その後、（[表]から削除したファイル名でデータを削除するにはどこのファイル名= 'boolaboola'）。

しかし、私の友人 "データが挿入されるたびに 'TABLE'を作成して削除してみませんか？

彼のテーブルスキーマがある - > [キー]、[テキスト]

は彼のアイデアは、アプリケーションがファイルを読み込むと、アプリがその名をファイル名で一つのテーブルを作成し、[ です。次に、新しいテーブルにデータを挿入します。 ファイル名でデータを削除する必要がある場合は、テーブルをドロップしてください。]

テーブルには外部キーは必要ありません。

私はその考えに同意できませんでした。 私の経験では、DBスキーマが間違っていると感じました... 私は説明できず、私の友人を説得することができません。

私を助けてください。 私は間違っていますか？または私はどのように私の友人を説得することができますか？

Answer 1

一般に、私はあなたに同意します。 IMHOは、通常、ソフトウェアが更新された場合にのみ、データベースのスキーマを変更することはまれです。私はこれが非常に厳密で「Un-NoSQL」であることを知っていますが、これは結局のところ伝統的なリレーショナルデータベースです:)。

もっと具体的には、このデータをどのように使用するのかを理解するのに役立ちます。それを複数のファイルからのデータにまたがる分析を簡単に行うことができるように、それを1つのテーブル（おそらくパーティション化されているか、またはパフォーマンスのために 'filename'のインデックスを付けて）に格納する方が柔軟性があります。

また、後で何らかのO/Rマッパーやその他のツールを使用する場合は、テーブルスキーマを静的にするのに役立ちます。

Answer 2

テーブルを削除するとインデックスを再作成する必要がなくなり、他のDBエンジンのオーバーヘッドが発生するため、テーブルを削除するとパフォーマンスが向上します。大規模なデータのパフォーマンスが大幅に向上します。しかし、複数のテーブルを作成すると、クエリの複雑さが増します。クエリで正しいテーブルを見つけるために独自のインデックスを使用する必要があるからです。

Answer 3

現実世界の例です。まさに「答え」ではなく、単なる物語です。誰かがスキーマを変えると言ったので、私はそれを投稿することにしました。

私は現在、大企業向けの大きなアプリケーションに取り組んでいますが、これは80％のPL/SQL（Oracle）サーバーベースのアプリケーションで構成されています。ブラウザのGUI（JavaScriptのヤフーの優れたYUI3ライブラリをベースにしたJavaScript）を使用していますGUIは単独で140以上のモジュールを持っています

残念ながらアプリケーションの（より大きい）サーバー側部分は、これは数年前、このアーキテクチャーがうまく機能していて、バージョン2を書くための資金を得ることができない小さなアプリだったからです。0であることを意味します（つまり、1.0のコードを破棄して最初から始めることを意味します）（ただし、制約を考えると、これまでに1000以上のPL/SQL関数を超えても驚くほど優れています）

ウェブアプリケーションのミドルウェアではセッションやセッションデータを定期的に追跡していますが、このすべてをPL/SQLで手作業で行う必要がありました。このためには、一時テーブルがたくさん作成されます。たとえば、ユーザーが一定の上位レベルの「ユースケース」を入力すると、大量の非常に詳細なデータを一時テーブルに集約し、ユーザーは残りのセッションでこれらのテーブルから処理されます。これらの上位レベルのユースケースでは詳細は必要なく、集計だけが必要です。

テーブルの作成と削除...少なくとも、私たちはそれを行い、正常に動作します。これに反対する一般的な技術的な理由はなく、あなたの本当の世界の状況によって異なります。純粋主義者は、ミドルウェアが欠けていると不平を言うことがあります。たとえば、実世界では何もしないという不満があります。

大きな画像を見てみることをお勧めします。なぜ動的にテーブルを作成しないのですか？理由は本当に技術的で、できるだけ多くの力（と狡猾）であなたの立場を守ります。しかし、あまりにも頻繁に私たちは技術。みんなが宗教的にもwaaaayyyyyyyであり、それを認めることを拒否しています。

誰かが他人を説得することができずに永遠に議論していると、明らかに正当な答えがないため、問題はそれほど重要ではないという指標になるかもしれません。 ）宗教的な議論は常に技術的なもの;-)

を作成し、「合法的な」ユースケースで動的にテーブルをドロップするよりもはるかに長いです。データが一時的にのみ使用される場合（「永遠に保存」ではなく）、その一時的なデータセットに対してクエリを実行する場合。テーブル（それはクロステーブルの場合は、一時テーブルに対して重い議論がある）、それは行く - それは物事の壮大なスキーム（あなたのアプリと全体的なシナリオ）に便利な場合。

PS：ああ、ところで、ちょうど一般的に言えば、ここで与えられたシナリオについて多くのことを言うことはできませんが、議論としてのパフォーマンスは本当に問題であればこれに入るべきです。すべての状況の95％で、保守性がリスト上ではるかに高いです。すべての1つのクエリで使用されてしまう*異なる*ファイルから