1

うーん、データベース アーキテクチャについてはよくわかりませんが、CTO の考えがよくわかりませんが、使用するすべてのテーブルの主キーの列の型として文字を使用することを主張しています。しかし、主キーはまだこのように見えます-> 1、2、3 ...など。それらは数値です。したがって、合成 PK には integer + auto_increment を使用します

LIKEしかし、CTO は、PK の条件を使用してクエリを発行できないのは悪いことだと言っています。

  1. 特に PK が数値の場合、PK に文字を使用しても問題ありませんか?
  2. PKで同様の条件を使用するのは正しいですか?

PS - したがって、自動インクリメント/トリガーの代わりに、シーケンス CTO は、テーブルから最大の値を取得する選択クエリを発行し、1 を追加してから、その値を文字列に変換して格納します。

編集
ご協力ありがとうございます。しかし、それが大惨事になることを彼に納得させる必要があります。これ（このような場合はキャラクター4 PK）は悪い考えだと教えられただけです。彼の主張は…
1. PKというキャラクターはあまりスペースを取りません。
2. int 型 PK を使用した場合、データベース クエリ オプティマイザーはクエリを再読み込みする必要が
"select * from employee where name like 'somename'
あり
Select * from employee where id = 6ます。
where句が変わるからです。
私たちが使用していると彼が強く主張したのは
"select * from employee where @columnName like @value"
、彼がこのように言ったようなものでした。

どうすれば彼の考えを変える正当な理由を証明または与えることができるでしょうか?

ありがとうございました ： ）

4

3 に答える 3

4

CTOがその決定を間違えている理由はたくさんあります。いくつか取り上げさせてください。

  1. お気づきのとおり、新しい自動インクリメントの主キーを生成するには、追加の手順を実行する必要があります。これは計算コストであり、将来のある時点で一貫性のない方法で適用される可能性も高くなります。

  2. 文字が4文字を超えると、ディスク領域のコストが高くなります（つまり、12345は「12345」よりもはるかに安価に保存できます）。

  3. 主キー（一部のRDBMのデフォルト）でクラスター化インデックスを使用している場合、文字の並べ替えは整数の並べ替えとはまったく異なります。

文字：1、10、101、11、12、13、14、15 ...数値：1、2、3、4 .. ..

最大数値を文字として挿入する場合は、インデックスを細断処理します。克服できない問題ではありませんが、クリーンアップするためにより多くの無駄な計算能力があります。

主キーでLIKEを使用することについての2番目の質問については、そのようなことを行う理由を考えることはできません。LIKEの機能が必要な場合は、通常、主キーとして使用されている列に何らかの重要性を割り当てているためです。つまり、エンドユーザーに公開する必要があります。その場合は、代理の自動インクリメント数値主キーを使用して、何らかの形式のIDをユーザーに公開します。

于 2013-01-07T03:18:15.003 に答える
1

さて、あなたはこのようなことをすることができます（SQL 2008 R2 +を想定）：

create table dbo.keep_the_peace (
  pk as right(replicate('0',10)+convert(varchar(10),pk_generator),10) persisted not null
, pk_generator int not null identity(1,1) 
, name nvarchar(128) not null
, constraint pk_keep_the_peace primary key nonclustered (pk)
, constraint uc_keep_the_peace unique clustered (pk_generator)
) 
go

insert dbo.keep_the_peace (name) values ('Hello')
insert dbo.keep_the_peace (name) values ('World')

select * from dbo.keep_the_peace

長所：

  1. pkvarcharであり、CTOは使用できますLIKE
  2. pk自動生成されるため、挿入時にテーブルを再クエリする必要はありません
  3. pkパディングがゼロのおかげで、正しい順序で並べ替えられます。
  4. pk_generator外部キー制約で使用でき、参照ごとに6バイトを節約できますが、CTOは引き続き参加してpk、正しい結果を得ることができます。
  5. 上の非クラスター化インデックスkeep_the_peaceは、スキニークラスタリングキーを利用します（pk_generator）

短所：

  1. pk+pk_generator行ごとに14バイトを使用し、必要以上に10バイト使用します。
  2. pk_keep_the_peace行ごとに14バイトを使用し、必要以上に14バイトを使用します。（笑）

編集

彼が強く主張したのは、「select * from employee where @columnName like @value」のようなものでした。彼はこのように言ったので、クエリオプティマイザーの方がうまくいくでしょう。

  • そのような構文はありません。動的SQLがないと、列名をパラメーター化できません。
  • そのような利点はありません。列名が変更されるたびに、新しい実行プランが生成されます。

WHERE句の列が変更された場合、はい、クエリが再コンパイルされます。これを回避する方法はありません。列のインデックスは異なる場合があります。

たとえば、クラスター化インデックスがオンのid場合、これはクラスター化インデックスシークとして実行されます。

select * from employee where id = 6

これには高価なテーブルスキャンが必要になりますが、次のようになります。

select * from employee where name like 'somename%'

非クラスター化インデックスをnameに配置すると、同じクエリに対して、より効率的なインデックスシーク+ブックマークルックアップが得られます（通常）。

INT対CHARはそれとは何の関係もありません。なし。文字キーのフットプリントは（一般的に）大きく、フットプリントが大きいとI/Oスループットが低下します。ただし、これらのバニラクエリのパフォーマンスは、データ型よりもインデックス作成に大きく依存します。

于 2013-01-07T03:58:37.113 に答える
1

1: はい、大丈夫です。また、常に時速 10 マイルで車を運転しても問題ありません。車は故障しません。char (または varchar) はどの比較でも LOW が遅いため、同じパフォーマンスを得るにはより大きな予算が必要になります。それらはスペースを無駄にし、遅いです。ここで唯一賢明なことをすることをお勧めします - ばかではない誰かと仕事を見つけてください。

2: わからない。ほら、ここでの問題は、これはおそらく単に使用できないものだということです。のように: データベースはそれを許可しません。私は実際に試したことはありません - 私は時速 100 マイルでコンクリート ブロックを叩いて、車が損傷するかどうかを確認するためだけに試したこともありません。これはほとんど意味がありません。

CTO は明らかに休暇を取って本を読む必要があります。おそらく誰かがCEOと話をして、彼をここに送る必要があります.彼はCTOの地位にバカを入れました.

合成 (1 フィールド) プライマリ キーに対する反対意見と賛成意見がありますが、私は 25 年間、データベースを扱う仕事をしていて、誰かが DBase や Cobol 以外でそれを行っているのを見たことがありません。それは壮大な無知です。とんがり髪のボス。

于 2013-01-07T03:12:25.620 に答える