1レコードのデータ量は控えるべき？

質問

レコード数が多くなると検索を返すのが遅くなりますが

1レコード内のデータ数が増える事で検索結果は遅くなりますか？

例えば
YESかNOの２拓を記録するデータベースがあったとします

　　　　　　　　問1　　　問2　　　問3　　　問4　　　問5
○○さん　　YES　　　NO　　　YES　　　NO　　　YES
□□さん　　NO　　　 YES　　　NO　　　NO　　　YES

と記録するか

　　　　　　　　問1　　　問2　　　問3　　　問4　　　問5
○○さん　　　Y　　　　　　　　　　Y　　　　　　　　　Y
□□さん　　　　　　　　Y　　　　　　　　　　　　　　　Y

と記録するかで迷っています。

レコード数は変わらないけど、1レコード内に記録される文字数(データ)の量がだいぶ変わります。

数万件のレコード数になった時に、検索結果の返しに変化が無いのであれば
前者の方が、CSVで出力した時とかの見栄えが良いので採用しようと思っています。

回答No.2

mitoneko · ベストアンサー

基本、言葉又は文字として意味がある場合を除いて、数値で表せるなら数値で保存する方が効率は良いです。これは、スペース・検索・集計などあらゆる場合においてそうです。
　今回がその典型例。Ｙ／Ｎでも、ＹＥＳ／ＮＯでも、Ａ／Ｂでも、定義に一貫性があれば何でも良いわけですから、１／０でも良いですよね。

　検索結果としてＹＥＳ／ＮＯで表示したければ、それは、検索の時にＳＱＬ文でそう作れば良いだけのこと。後でなんとでもなります。

　次に、ＮＵＬＬ（何も入れない）というのは、できる限り避けるべきです。
　検索・集計時に、ＮＵＬＬと言うのはとかくやっかいで、後々まで後悔することになります。元々、ＮＵＬＬというのは、「不定」とか「未定義」を表します。この意味で使うのであれば、ＯＫです。
　今回の場合であれば、「回答無し」であれば、ＮＵＬＬとしても良いかもしれないです。
　間違っても、Ｎｏの代わりに使うことだけは避けましょう。
　ちなみに、ＮＵＬＬを入れた場合も、ＨＤＤの領域としては、「Ｎ」を入れた場合と同じだけ使うと考えてください。
　しかも、検索時にＮＵＬＬを考えたＳＱＬを組む必要があります。とかくＳＱＬ文が複雑になり、結果として、検索の速度も遅くなります。

　私なら、

create table test(
namae varchar(50),
qnum tinyint,
ans tinyint,
primary key (namae));

　としておくでしょうか。実は、こうすると、質問に書かれた表を再構築するのは少し難しくなるんですけど、領域としては最低限に抑えられますし、問い毎の集計がとても楽になります。また、突然「問６」が出現した時の被害も最小限ですみます。

せめて、
create table test2(
namae varchar(50),
q1 tinyint,
q2 tinyint,
q3 tinyint,
q4 tinyint,
q5 tinyint,
primary key (namae));
ですね。

　後者のテーブルで、質問の一つ目に書かれた表示を復元したければ、

select namae,
case q1 when 1 then 'YES' when 0 then 'NO' else '?',
case q2 when 1 then 'YES' when 0 then 'NO' else '?',
case q3 when 1 then 'YES' when 0 then 'NO' else '?',
case q4 when 1 then 'YES' when 0 then 'NO' else '?',
case q5 when 1 then 'YES' when 0 then 'NO' else '?'
from test2
where ・・・・・・・;

　とでも書けば、ＯＫです。もっというと、この数字からＹＥＳ／ＮＯへの変換は、ＳＱＬでやるより、アプリケーションプログラムでやった方が普通は楽です。

お礼

ご回答ありがとうございます！

お礼が遅れました・・・

まだまだ勉強不足なのを凄く痛感しました。

とても参考になりました！

回答No.3

korocorogoro

正規化の考えで行くとそのテーブル設計自体が問題歩きがするけど
やるなら
・ユーザマスターテーブル
ユーザID,ユーザ名
・成績テーブル
ユーザID,問いNo,正誤
ってテーブル設計にしますけどね。

回答No.1

yambejp

二者択一でかならずどちらかが選ばれるなら
ENUMなどで持つのが妥当かと