5

私のデータベースにはバージョン番号が保存されています。ただし、メジャー.マイナー.ビルド (8.2.0、12.0.1 など) と日付 (YY-MM-DD など) の 2 つの形式があります。私は2つの解決策を考えていました：

+---+---+-----+-----------+ +-----+-----+-----+-----+ +-----+--------+
|...|...|id   |versionType| |id   |major|minor|build| |id   |date    |
|---+---+-----+-----------| |-----+-----+-----+-----| |-----+--------|
|...|...|12345|0          | |12345|0    |1    |2    | |21432|12-04-05|
|---+---+-----+-----------| +-----+-----+-----+-----+ +-----+--------+
|...|...|21432|1          |
+---+---+-----+-----------+

また

+---+---+-----+-----+-----+-----+--------+
|...|...|id   |major|minor|build|date    |
|---+---+-----+-----+-----+-----+--------|
|...|...|12345|0    |1    |2    |null    |
|---+---+-----+-----+-----+-----+--------+
|...|...|21432|null |null |null |12-04-05|
+---+---+-----+-----+-----+-----+--------+

これらはどちらも特に効率的ではないようです。最初の例では、バージョン番号を取得するためだけに 2 つのテーブルを結合する必要がありますが、2 番目の例では、最初の例に比べてバージョン エントリごとに 2 倍のスペースが浪費されています。別の方法として、値を列にビット単位で格納し、それをクライアント側で解釈することもできますが、この状況で見落としていた標準的な方法があることを願っています。

リレーショナル データベースの同じ「列」に対して 2 つの異なる種類のデータを格納する適切な方法はありますか?

4

6 に答える 6

1

異なる種類のバージョン管理されたオブジェクトがあり、ある種類のバージョン管理では日付が使用され、別の種類のバージョン管理ではバージョン番号が使用されている状況ですか、それとも同じ種類のオブジェクトのバージョンが両方とも日付を使用して参照されている状況ですか?バージョン番号を使用していますか？

最初のケースでは、何の役にも立たない人工的なテーブルをわざわざ作成しないでください。実際に存在するビジネス上の問題を解決する場合にのみテーブルを作成する必要があり、バージョン日付からバージョン番号への変換、またはその逆の変換は、この状況では存在しません。そして、それが後で発生したとしても、あなたはまだできます...

2 番目のケースでは、2 番目のオプションのようなテーブルを定義しますが、次のようになります。

それらすべてのばかげた無意味な ID なしで。maj/min/bld/date の 4 つの列はそのままにしておきます。そして、それらのいずれかをNULL可能にしないでください。maj/min/bld と date の 2 つのキーを定義します。新しいビルドごとに行を登録し、ビルドの作成日 (/activation/whatever ...) を記録します。管理しているバージョン管理されたオブジェクトを説明する表のバージョン インジケーターとして maj/min/bld 構造を使用し、日付を使用してバージョン参照が行われる要求が来るたびに、クエリを使用してこれをバージョン番号に解決します。あなたの4列のテーブル。

于 2012-05-05T21:57:55.657 に答える
0

データを 1 つの int/bigint フィールドに格納できる可能性があります。ただし、この場合、すべての値を変換する必要があります: 日付 - ある日付から始まる日数に変換するか、場合によっては unixtimestamp を使用できます バージョン - ビルドの値に制限を与えます (最大 1000 にします)、マイナー (1000) ）。= メジャー*1000*1000 + マイナー*1000 + ビルド

于 2012-05-04T20:50:35.770 に答える
0

このバージョン番号をクエリでどのように使用するかによって異なります。バージョン番号をラベルとして扱うだけで十分な場合は、それを varchar 列に格納することを検討してください。

それだけでは不十分で、バージョン番号でソートできるようにしたい場合、物事はより複雑になります。なぜなら、自然なソート順序を維持するデータ型でバージョン番号を格納する方が便利だからです。私はおそらくあなたのソリューションに行きます 2.効率を心配する理由はありますか? 何百万行も期待していますか？そうでない場合は、あまり心配する必要はありません。

スペース、速度、ボリュームが明確な考慮事項である場合は、実際のバージョン番号をテキスト ラベルとして格納し、ソート目的で使用する別の列に格納する代理バージョン番号 (単一の整数) を取得することを検討できます。

一方、一部のオブジェクトにバージョン日付、一部のバージョン番号、および場合によっては両方があることが判明した場合でも、2番目の解決策を検討します. 完全に正規化されたモデルが本当に必要な場合は、オブジェクト テーブルと 1 対 1 の関係を持つ個別の version_date テーブルと version_number テーブルを作成することを検討できます。そして、あなたはまだそれらの結合を必要とします. 繰り返しますが、それについて心配する必要はありません。データベースは結合が得意です。

于 2012-05-04T21:12:46.257 に答える
0

ここに特効薬はないと思います。単一の列を持つことに固執している場合は、単純に両方を CHAR(10) に平手打ちすることができますが、これには独自の問題があります (たとえば、無効な日付や不正なビルド番号文字列など)。

重要な質問は、実際にどのような種類のクエリを実行することを想定しているか、何行あると予想されるかということだと思います。

予想されるクエリの必要性に応じて、DB 設計を推進します。

于 2012-05-04T20:41:47.607 に答える
0

テーブルの粒度はバージョンであるため、それがどのように入ってきても、2番目のオプションを使用します.3つの数値列と1つの日付列に格納する場合、行ごとに16バイトのみにする必要があります（数値と日付の列ごとに4バイト） ) Oracle などのデータベースで。データベースが仮想 (計算された) 列を処理する場合、nvl(to_char(date),major||'.'||minor||'.'||build) のようなものを追加し、常にデータを使用して選択することができますvarchar としてフォーマットするか、ビューを配置できます。

于 2012-05-04T21:01:11.880 に答える
0

最初のものはより良いです。結合を行うたびに頭が痛いと感じる場合は、テーブルを直接使用する (または毎回結合する) のではなく、(結合を使用して) ビューを作成し、そのビューを使用できます。

于 2012-05-04T20:38:01.973 に答える