22

現在、postgres データベースとやり取りする既存の API を変更しようとしています。簡単に言うと、実際の「アセット」（通常、これは何らかのファイル）がサーバーのハードディスクのどこに保存されているかを判断するために、記述子/メタデータを保存します。

現在、これらの「アセット」に任意の数の未定義のキーと値のペア (つまり、uploadBy、addedOn、assetType など) を「タグ付け」することができます。これらのタグは、次のような構造を持つ別のテーブルに保存されます。

+---------------+----------------+-------------+
|assetid (text) | tagid(integer) | value(text) |
|---------------+----------------+-------------|
|someStringValue| 1234           | someValue   |
|---------------+----------------+-------------|
|aDiffStringKey | 1235           | a username  |
|---------------+----------------+-------------|
|aDiffStrKey    | 1236           | Nov 5, 1605 |
+---------------+----------------+-------------+

assetid と tagid は、他のテーブルからの外部キーです。ファイルを表すアセット ID と、タグ ID/値のペアが記述子のマップであると考えてください。

現在、API (Java にある) は、これらすべてのキーと値のペアを Map オブジェクトとして作成します。これには、タイムスタンプ/日付などが含まれます。私たちがやりたいことは、キーと値のペアの値に対して何らかの形でさまざまなタイプのデータを格納できるようにすることです。または、少なくとも、必要に応じて、これらのタグの日付範囲などをチェックするクエリを実行できるように、データベース内に別の方法で保存します。ただし、データベースにテキスト項目として保存されている場合は、a.) これが実際には日付/時刻/タイムスタンプ項目であることを認識し、b.) 実際に実行できるものに変換する必要があります。クエリします。

これまでのところ、データベースのレイアウトをあまり変更せずに完全に変更することなく、私が考えることができるアイデアは1つだけです。

assettag テーブル (上に表示) を拡張して、さまざまなタイプ (数値、テキスト、タイムスタンプ) の列を追加し、それらを null にできるようにしてから、挿入時に、対応する「キー」をチェックしてデータのタイプを特定します。本当にそうです。ただし、この種の実装には多くの問題が見られます。

PostgreSQL-Ninjas は、この問題へのアプローチ方法について提案を提供できますか? 私はつい最近、データベース インタラクションの深いところに引き戻されるようになったばかりなので、少し錆びていることを認めます。

4

4 に答える 4

33

You've basically got two choices:

Option 1: A sparse table

Have one column for each data type, but only use the column that matches that data type you want to store. Of course this leads to most columns being null - a waste of space, but the purists like it because of the strong typing. It's a bit clunky having to check each column for null to figure out which datatype applies. Also, too bad if you actually want to store a null - then you must chose a specific value that "means null" - more clunkiness.

Option 2: Two columns - one for content, one for type

Everything can be expressed as text, so have a text column for the value, and another column (int or text) for the type, so your app code can restore the correct value in the correct type object. Good things are you don't have lots of nulls, but importantly you can easily extend the types to something beyond SQL data types to application classes by storing their value as json and their type as the class name.

I have used option 2 several times in my career and it was always very successful.

于 2013-08-14T13:59:10.993 に答える
3

私は決して PostgreSQL 忍者ではありませんが、2 つの列 (名前用と型用) の代わりにhstore データ型を見ることができると思います:

単一の PostgreSQL 値内にキーと値のペアのセットを格納するためのデータ型。これは、めったに検査されない多くの属性を持つ行や半構造化データなど、さまざまなシナリオで役立ちます。キーと値は単なるテキスト文字列です。

もちろん、日付/タイムスタンプがこの型との間でどのように変換されるかを確認し、それが適切かどうかを確認する必要があります。

于 2013-08-14T14:41:16.467 に答える