0

私が取り組んでいる現在のプロジェクトでは、Oracle DBMS を使用してデータを格納しています。開発中に、Date 情報が Date フィールドではなく、奇妙なフォーマットの VARCHAR2 列に格納されていることがわかりました。たとえば、次の表を見てください。

CREATE TABLE "A_TABLE"
  (    
    "OSERC_FEC_INICIO_OS"            VARCHAR2(14 BYTE),
    "OSERC_FEC_FIN_OS"               VARCHAR2(14 BYTE),
    "OSERC_FEC_REGISTRO_PETICION"    VARCHAR2(14 BYTE),
    "OSERC_FEC_APROBACION_PETICION"  VARCHAR2(14 BYTE),
    "OSERC_FEC_LIQUIDACION_OS"       VARCHAR2(14 BYTE),
    "OSERC_FEC_EJECUCION_OS"         VARCHAR2(14 BYTE),
)

フィールドOSERC_FEC_REGISTRO_PETICION, OSERC_FEC_APROBACION_PETICION, OSERC_FEC_LIQUIDACION_OSとOSERC_FEC_EJECUCION_OSストアは日付情報を格納しますが、VARCHAR2 列として宣言されています。YYYYMMDDHHMMSSデータを確認すると、この形式を使用してその情報が保存されていることがわかります。

WHERE 句でこの日付を使用するクエリを作成する必要があるため、心配していますが、そのアプローチでインデックスのパフォーマンスがどうなるかわかりません。では、私が言及した設計に含まれる問題は何ですか? VARCHAR2ではなくNUMBERの日付フィールドの方が良いでしょうか?

4

2 に答える 2

5

日付が日付として保存されていると、はるかに良いでしょう。それらを文字列ではなく数値として保存すると、別の一連の問題が発生します。

文字列として保存された日付に完全に固執している場合、列のインデックスを使用できるようにするには、パラメータとして使用している日付を適切な形式の文字列として変換し、次の事実に依存する必要があります。その特定の形式での文字列の並べ替えは、実際の日付の予想される並べ替え順序と一致します。文字列を現在または数値と比較すると、暗黙的なデータ型変換が発生します。これは、インデックスを使用できず、最悪の場合、誤った結果やエラーを生成するため、せいぜいパフォーマンスの問題につながります。

データ型の変換を回避すると仮定すると、パフォーマンスの問題は、間違ったデータ型を使用した場合にオプティマイザがカーディナリティを推定するのが非常に困難であるという事実から発生する可能性があります。たとえば、Oracleは、2012年1月1日から2013年1月1日までの間に365日（または8760時間または525600分）があることを認識しています。一方、「20120101000000」と「20130101000000」の間には数十億の可能な文字列があります。これにより、オプティマイザが必要なときにインデックスを使用しない（またはその逆）、間違った種類の結合を使用するなどの原因になる可能性があります。

于 2012-05-23T17:36:32.373 に答える
1

一般的には、日付として保存する方が良いでしょう。次を使用して変換できます。

to_char(<field>, <format string>)

そして、フォーマット文字列'YYYYMMDDHHMISS'は機能すると思いますが、私は肯定的ではありません。

ただし、この形式を選択した理由があるかもしれません。Oracleは、日付/時刻を数値として格納します。年、月、日、時、分、秒を抽出するには、少し数学的な操作が必要です。処理環境によっては、部分文字列操作を使用して日付コンポーネントを抽出する方がはるかに簡単な場合があります。

私の推測では、コードがこれらのフィールドを使用している場合、文字列操作が使用されている例は複数あります。これは意図的な設計上の決定のように思われるので、変更する前に注意深くチェックしてください（より良い解決策に）。

于 2012-05-23T17:36:15.810 に答える