私のアプリケーションは、格納する必要がある本当に小さなイベントを受け取り続けています。私はそれを処理するための最良の方法を考えていました。私は行として各イベントを格納しておく場合は、ブロブ圧縮/治療のいくつかの種類と実装に対するいくつかの欠点があるでしょうFirebird 2.1は、DBのテーブルに大量の行を格納するのに効率的ですか？
EVENT
id
timestamp
some_data (integer)
fk_to_some_holder_table
：このイベントの表には、このようなものになるだろうか？それとも私はあまりにも遠くに行っていますか？
私はFirebird 2.1を使用しています。必要に応じて、Firebird 2.5にアップグレードすることができます。
ありがとうございます。
私は、あなたが「伝統的な行ベースの記録」との方がいいでしょう確信している：あなたが正しい、レコードを照会する
「」によると、1つのテーブルの最大サイズは32TBまたは16G行です。
この特定のケースで2.1と2.5の間に違いはないと思いますが、他の/一般的な改善のために2.5を使用します。行が塊よりもはるかに良い理にかなっているよう
しかし、小さなレコードがたくさんある場合、それらをBLOBに入れてBLOBを圧縮することができます。私はいくつかのテストを行い、ここに結果を掲載します。 – ivarec
まあ、あなたはそれがもたらす追加の作品を楽しむように見えます。
@haole AFAIK、Firebirdはデータを格納するときに内部的にRLE圧縮を使用します。それは外部から行うほど効率的かもしれませんが、圧縮がすでに行われていることに注意するのは良いことです。 – Harriv
の理由のため、保管はすでに2.5が
2.5のバグは？最新のスナップショットビルドを試しましたか？ –
あなたの質問は本当にない私の好みのためにあまりにも多くのバグを持って、私は今のところ2.1に固執したい
を述べました明らかです。データベースは大量のデータを格納するように設計されており、あなたが提供した定義にはブロブや圧縮を必要とせず、不要なオーバーヘッドを不必要に追加することもあります。あなたは何を求めているのかを明確にすることはできますか？ –
正しい方法でやっています。データベースシステムは、大量の行を格納するために設計されています。圧縮について心配しないで、あなたの時間を無駄にするでしょう。そして、どんな状況においても、ブロブを使うことを間違えてはいけません！ –
あなたは正しいです。私の質問は、Firebird 2.1の実装に関するものです。私はその質問を編集した。ありがとう – ivarec