0

ほとんどの主キーと他のフィールドもchar（n）を使用して、パディング付きの数値を格納するデータベースを使用するように求められました。次に例を示します。

product_id: char(8) [00005677]
user_id: char(6) [000043]
category_id: char(2) [05]

彼らがそのようにそれを使いたい理由は、彼らが望むなら（遠い将来に）キャラクターを使うことができるようにするためです。ただし、番号に基づく多くのルールがあります。たとえば、01から79までのcategory_idは一般的なカテゴリに対応し、80から89までは特別なカテゴリであり、90から99まではユーザー定義のカテゴリです。

個人的には、char（n）を使用して数値を格納することは悪い習慣だと思います。私の理由は次のとおりです。

  1. char、 ""！= 0、0！= 00、05！= 5、00043！=00043などを使用します。そのため、（データの破損を防ぐために）値を常にチェックする必要があります。
  2. 数字を埋める場合：0-> 00、文字を埋めないように注意する必要があります（A-> 0A）
  3. 文字を使用すると、範囲が奇妙になります。たとえば、01から79、ABとRX、TZとSなどです。
  4. 文字の代わりに数値にインデックスを付けると、パフォーマンスが向上します

この情報はさまざまなソース（Web、Windowsクライアント、アップロードcsv）によって変更されるため、ゼロフィルを使用してdecimal（n）に変更し、より「エラー防止」にすることを提案しています。たとえば、カテゴリをさらに追加したい場合は、decimal（2）からdecimal（3）への更新が簡単になります。

私の質問は次のとおりです。私は間違っていますか？char（n）はこのタスクで信頼できますか？「chars」が数字で邪悪な場合、上記のリストに欠けている他の欠点はどれですか（私の場合に勝ちたい場合は、より良い理由が必要になる可能性があります）？

TIA（コメント/回答をいただければ幸いです）。

4

2 に答える 2

1

これがSQLServer、Oracle、またはその他のRDBMSの場合は、データが常に列の全容量と一致するように、これらの列にチェック制約を適用することをお勧めします。これにより、識別子が均一になります。

残念ながら、MySQLはこれをサポートしていません。

データベースや検索ルーチン、クライアント、またはデータベース内のprocに入るものを埋める必要があるという煩わしさを止めることはできませんが、フィールドが最低レベルでクリーンであることを保証します。

このような制約を使用すると、物事がひどく手に負えなくなるのを防ぐのに役立ちます。

数字を使用した最適化に関しては、将来、数字以外の文字に対応する必要がある場合、それはオプションにはなりません。

varchar / charデータで自然キー（主キーの候補になる可能性があります）を持つことは非常に一般的ですが、代わりに代理キー（通常は単に内部参照であるある種の自動番号付け整数であり、多くの場合、クラスタ化されたインデックスと主キー）。

于 2011-08-24T03:12:51.020 に答える
1

あなたの質問を引用する：

...パディング付きの数値を格納...

数値データの例は示さず、たまたま数値で構成される文字データのみを示しました。彼らのOrderTotal列が char(10) であると言っていたら、私は心配し始めます。

これを文字データとして扱うだけで問題ありません。データベースを変更するビジネス上または技術上のケースは見当たりません (ほぼ完全な書き直しを開始しない限り)。

パフォーマンスについて...これが実際に懸念事項である場合は、対処する必要があるはるかに大きな問題がある可能性があります。MySQL は高速で正確です。

--

クエリの目的で、ユーザーが入力した ID をゼロフィルする関数をどこかに記述します。この関数は、ユーザー入力を受け入れる必要があるすべての場所で使用してください。数値データ型を使用してデータを保存しないでください (PHP の場合は、 を使用しない+、常に.連結に使用するなど...)。

これは、遭遇する可能性のある他の文字列 ID と同じであることに注意してください。Item_Number = "SHIRT123"

気をつけて

于 2011-08-24T03:02:42.743 に答える