私は研究室のデータベースを設計しています。いくつかの製品、サンプルなどは、起源、日付、タイプ、今日のIDなどの異なる値を示す複数の部分を持つ合成数によって識別されます。合成数の例には、運転免許証番号（X44-555-3434）が含まれる場合があります。 、ロット番号（XBR-A26-500-2）。
合成数はどのようにデータベースに保存する必要がありますか？それらは文字列として保存する必要がありますか、それとも合成数の各コンポーネントを個別に保存（または派生）する必要がありますか？
注：質問に一般的に答えられない場合は、Oracleを使用してください。
私の経験では、意味のある文字列の要素がある場合は、それらを独自のフィールドに配置するのが最善です。私たちが意味を引き出すために経験する体操は複雑でエラーが発生しやすいです。また、各フィールドを明示的に処理すると、データ検証を行うのが簡単になります。複合文字列の作成は簡単で、作成された文字列の検索も簡単です（ただし、インデックスを作成するのが難しい場合もあります）。きめ細かいストレージは常に私にとって最適です。
それはあなたが最終的に何を照会したいかによります。文字列の一部を個別に検索する場合は、個別に保存してください。コード全体（ダッシュの有無にかかわらず、処理可能）を検索する場合は、単一の文字列として格納します。
合成数のコード化された各部分を個別に保存します。おそらく、コードが表す実際の値として（つまり、「XBR」ストア「2007年1月12日」をタイムスタンプとして保存する代わりに）。ただし、それは、コード化された合成数でアイテムを検索する頻度が高いか、実際のセマンティクスでアイテムを検索するかによって異なります。
次に、コードと実際の値の間のマッピングをデータベースのどこかに保持します。したがって、それぞれ2つの列を格納するいくつかの小さなテーブルがあります。1つはコードを表し、もう1つはタイムスタンプなどを表します。
また、それらを別々の列に格納する場合は、それらから一意のキー（すべての列を含む一意のキー）を作成することをお勧めします。
これらの数値の導出は変更される可能性があり、それがアプリケーションにどのように影響するかを予想しますか？
たとえば、数年前、英国の自動車のナンバープレートは、3文字（地域を示していると思います）で始まり、3桁の数字が続き、その後に登録年を示す別の文字が続きました。
結局、接尾辞の文字が足りなくなり、順番を入れ替えたので、「ABC 123 A」ではなく、「A 123 ABC」になり、2台の車を同時に登録することができたはずですが、 1つは「ABC123A」、もう1つは「A123ABC」です。ああ、それから彼らは一文字の年インジケーターの使用を「スピードアップ」したので（多くの人が車を買う前に新しい文字が発効するまで待っていたので）、それはもはや年を示していませんでした。
ナンバープレートに興味があるだけなら、ナンバープレートを1つの値として保存するのが最善でしょう。ただし、番号の発行を担当するアプリケーションでは、おそらく番号をコンポーネントに分解する必要がありました。