私は現在、postgresデータベースと相互作用する既存のAPIを変更しようとしています。簡単に言うと、これは基本的に記述子/メタデータを格納して、実際の「資産」（通常はある種のファイル）がサーバーのハードディスクのどこに格納されているかを判別します。
現在、これらの「アセット」に任意の数の未定義のキーと値のペア（つまり、uploadedBy、addedOn、assetTypeなど）を「タグ付け」することができます。これらのタグは、次のような構造の別のテーブルに格納されます。
+---------------+----------------+-------------+
|assetid (text) | tagid(integer) | value(text) |
|---------------+----------------+-------------|
|someStringValue| 1234 | someValue |
|---------------+----------------+-------------|
|aDiffStringKey | 1235 | a username |
|---------------+----------------+-------------|
|aDiffStrKey | 1236 | Nov 5, 1605 |
+---------------+----------------+-------------+
Assetidとtagidは、他のテーブルからの外部キーです。ファイルを表すassetidについて考えてみてください。タグIDと値のペアは、記述子のマップです。
現在、API（Javaにあります）は、これらすべてのキーと値のペアをMapオブジェクトとして作成します。これには、タイムスタンプ/日付などが含まれます。私たちがやりたいのは、キーと値のペアの値について、さまざまなタイプのデータを何らかの方法で格納できるようにすることです。または、少なくとも、データベース内に別の方法で保存して、必要に応じて、これらのタグの日付範囲などをチェックするクエリを実行できるようにします。ただし、それらがテキストアイテムとしてデータベースに保存されている場合は、a。）これが実際には日付/時刻/タイムスタンプアイテムであることを認識し、b。）実際にそのようなを実行できるものに変換する必要があります。クエリします。
データベースのレイアウトをあまり変更せずに、これまで考えられたアイデアは1つだけです。
アセットタグテーブル（上記）を展開して、さまざまなタイプ（数値、テキスト、タイムスタンプ）の追加の列を作成し、それらをnullにできるようにしてから、挿入時に、対応する「キー」をチェックして、データのタイプを特定します。本当にそうです。しかし、そのような実装には多くの問題があります。
そこにあるPostgreSQL-Ninjaは、この問題に取り組む方法についての提案を提供できますか？私は最近、データベースの相互作用の最深部に戻されたばかりなので、少し錆びていることを認めます。
基本的に2つの選択肢があります。
データ型ごとに1つの列を用意しますが、保存するデータ型に一致する列のみを使用してください。もちろん、これによりほとんどの列がnullになり、スペースが無駄になりますが、強い型付けのため、純粋主義者はそれを好みます。どのデータ型が適用されるかを判断するために、各列でnullをチェックする必要があるのは少し不格好です。また、実際にnullを格納したい場合は、残念です。「nullを意味する」特定の値を選択する必要があります。
すべてをテキストとして表現できるため、値にテキスト列を設定し、型に別の列（intまたはtext）を設定して、アプリコードが正しい型オブジェクトに正しい値を復元できるようにします。nullがあまりないのは良いことですが、重要なのは、値をjsonとして、型をクラス名として格納することで、SQLデータ型を超えてアプリケーションクラスに型を簡単に拡張できることです。
私はキャリアの中でオプション2を数回使用しましたが、それは常に非常に成功しました。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加