0

以下に2つのテーブルを定義します。

Create table tickets (id long not null,
reseller long not null,
constraint pk_lock primary key (id)); 

Create table ticketRegistrations (id long not null,
customer long not null,
constraint fkTicketRegistrationTicket 
  foreign key (id) references tickets (id) on update cascade);

クライアントはチケットを入力できます（したがって、主キーの自動インクリメントはありません）。idはticketregistrationsテーブルの主キーと外部キーであるため、整合性制約とそのすべてのジャズがあります。私が遭遇した問題は、チケットID（つまり、00007）でゼロパディングを許可する機能要求です。私の知る限りでは、整数をゼロパディングで格納することはできません。

私が思いついた解決策は、チケットテーブルにnullではないticketID varchar（8）列を追加し、両方のテーブルの実際のIDを代理キーとして使用することです。次に、ticketregistrationテーブルの外部キーはticketidを指します。

私が持っている質問は、効率と速度に関するものです。以前は、システム内にチケット登録を追加できましたが、データベースは、同じIDのチケットがデータベース内にあるかどうかを確認するために、追加時に整合性制約を実行していました。これで、インデックスが作成されるIDのvarchar文字列ができました。
顧客が「チケットを登録」するとき、ticketid varcharをチケットテーブルに保持し、ticketidの外部キーをticketregistrationテーブル（varchar（8））内で使用する方が簡単ですか？

または、ticketregistrations内にticketid varchar（8）を持たず、ticketsテーブルへの外部キーをticketregistrationsテーブルの主キーとして保持し、最初にチケットテーブル内のticketidを確認し、値を取得して入力する方が簡単ですか。チケット登録内の行に？

これにより、ticketsregistrationsテーブルに挿入する前に、ticketsテーブルにインデックス付きvarchar検索が作成されます。

参照整合性が問題を処理したので、私の最初のソリューションはこれを必要としませんでした。

シーク時間が心配です。

4

2 に答える 2

1

私には2つの解決策があります。

1 つ目は、チケット テーブルに識別子用の 2 つの列を用意することです。1 つは、参照に使用される内部専用の識別子である必要があります (つまり、自動インクリメントできます)。重要な点は、この列が入力データに関連付けられていないことです。2 番目の列には、ユーザーが入力した ID の文字列表現が含まれます。次に、検索目的で 2 番目の列に一意のインデックスを追加できます。

2 つ目は、テーブルをそのままにして、指定された長さまでゼロを埋め込んで ID のみを表示することです (つまり、ユーザーは 6 桁しか入力できません)。したがって、ID を表示する必要がある場合はどこでも、ID を埋め込む関数を呼び出します。チケット番号が入力されると、パディングを取り除き、整数に変換します。このソリューションは、質問のデータベース構造を中心に書かれたアプリケーション全体を既に持っている場合、実装が簡単になります。また、アプリケーションの存続期間中に桁数が変数になると考える場合は、より柔軟です。

可能であれば、両方のソリューションを実装して、テーブルに 2 番目の数値列を追加し、ゼロ パディング表示を行うことができます。

最終的にどちらのソリューションを使用するにしても、数字だけでなく文字も含むチケット ID のサポートを追加するように求められた場合、何を変更する必要があるかを考えてください。

于 2009-09-14T16:17:27.983 に答える