回答:
レコードは、名前と住所の情報を収集するフォームから取得したとしましょう。ユーザーがアパートに住んでいない場合、住所の2行目は通常空白です。この場合の空の文字列は完全に有効です。NULLを使用して、値が不明または指定されていないことを意味する傾向があります。
物理的なストレージの違いは実際には心配する価値がないと思います。データベース管理者として、もっと大きな魚を揚げる必要があります!
私はMySQLとPostgreSQLについては知りませんが、これを少し一般的に扱いましょう。
NULLと ''の間でユーザーを選択できないOracleという1つのDBMSがあります。これは、両方を区別する必要がないことを明確に示しています。いくつかの迷惑な結果があります:
次のように、varchar2を空の文字列に設定します。
Update mytable set varchar_col = '';
以下は同じ結果につながります
Update mytable set varchar_col = NULL;
ただし、値が空またはNULLの列を選択するには、使用する必要があります
select * from mytable where varchar_col is NULL;
を使用して
select * from mytable where varchar_col = '';
構文的には正しいですが、行を返すことはありません。
一方、Oracleで文字列を連結する場合。NULL varcharは空の文字列として扱われます。
select NULL || 'abc' from DUAL;
abcを生成します。これらの場合、他のDBMSはNULLを返します。
値が割り当てられていることを明示的に表現したい場合は、「」などを使用する必要があります。
そして、空ではないトリムがNULLになるかどうか心配する必要があります
select case when ltrim(' ') is null then 'null' else 'not null' end from dual
します。
''がNULLと同一ではないDBMS(SQL-Serverなど)を見る
''での作業は一般に簡単で、ほとんどの場合、両方を区別する必要はありません。私が知っている例外の1つは、列が設定を表し、それらの空のデフォルトがない場合です。''とNULLを区別できる場合、設定が空であることを表現し、デフォルトが適用されることを回避できます。
作業しているドメインによって異なります。NULL
値が存在しない(つまり、値がない)ことを意味し、空の文字列は長さがゼロの文字列値があることを意味します。
たとえば、人のデータを保存するテーブルがあり、Gender
列が含まれているとします。値を「男性」または「女性」として保存できます。ユーザーが性別のデータを提供しないことを選択することができる場合、あなたにすることを保存する必要がありますNULL
(つまり、ユーザーが値を提供しなかった)といない空の文字列(値とは性別がないので「」)。
覚えておく価値のあることの1つは、必須ではないフィールドがあり、存在する値が一意でなければならない場合、空の値をNULLとして格納する必要があることです。それ以外の場合、そのフィールドに空の値を持つタプルを1つだけ持つことができます。
また、リレーショナル代数とNULL値にはいくつかの違いがあります。たとえば、NULL!= NULLです。
UNIQUE
制約に違反します。幸いなことに、2008年からは、フィルター処理されたインデックスを使用して適切な動作を取得できます。
また、DateのNULLの批判と、SQLおよびリレーショナル理論の 3VLの問題(およびRubinson のDateの批判、Nulls、Three-Valued Logic、およびSQLのあいまいさの批判:Date of Critiqueの批判)を考慮することもできます。
両方は、関連するSOスレッド、DBモデルからNULL可能列を削除するためのオプションで詳細に参照および説明されています。
フレームワークを使用している場合、新しい思考、NULL
/の選択に対する大きな影響がありますNOT NULL
。symfony alotを使用し、許可NULL
フィールドを使用すると、データを操作する際のコードとデータのチェックの一部が簡素化されます。
フレームワークを使用していない場合、または単純なsqlステートメントと処理を使用している場合は、追跡する方が簡単だと思う方を選択します。INSERT
空のフィールドをに設定するのを忘れて文を実行するのが面倒にならないように、私は通常NULLを好みますNULL
。
オラクルと仕事をしなければならなかったので(差別化することはできません)、私は次の結論に達しました。
論理的なPOVからは問題ではありません。NULLと長さゼロの文字列を区別することでDBMSに値が追加されるような説得力のある例を考えることはできません。
以下から:NULL
zero-lenを許可しない列''
(Oracleのようなソリューション)またはNOT NULL
zero-lenを許可する列があります。
そして、私の経験から、データを処理するとき、空の文字列として文字列の不在を処理したい''
ので、はるかに理にかなっています:連結、比較など。
注:私のOracleエクスペリエンスに戻るには、検索リクエストのクエリを生成するとします。使用する''
場合は、生成するだけでWHERE columnX = <searchvalue>
、等価検索で機能します。あなたが使うならあなたはしNULL
なければなりませんWHERE columnX=<searchvalue> or (columnX is NULL and serchvalue is NULL)
。ああ!:-)
また、設計の観点からも異なります。
例えば
CREATE TABLE t (
id INTEGER NOT NULL,
name CHARACTER(40),
CONSTRAINT t_PK PRIMARY KEY (id)
);
CREATE UNIQUE INDEX t_AK1 ON t (name);
次のようになります:
\d t
Table "public.t"
Column | Type | Modifiers
--------+---------------+-----------
id | integer | not null
name | character(40) |
Indexes:
"t_pk" PRIMARY KEY, btree (id)
"t_ak1" UNIQUE, btree (name)
いくつかのデータを挿入しましょう:
op=# insert into t(id, name ) values ( 1, 'Hello');
INSERT 0 1
op=# insert into t( id, name) values ( 2, '');
INSERT 0 1
op=# insert into t( id, name) values ( 3, '');
ERROR: duplicate key value violates unique constraint "t_ak1"
次に、nullを試してみましょう。
op=# insert into t( id, name) values (4, null );
INSERT 0 1
op=# insert into t( id, name) values (5, null);
INSERT 0 1
これは許可されています。
Soooooo:nullは単純な文字列でもその逆でもありません。
乾杯
NULL
かどうかの速度/サイズの違いを心配する必要があるdbaはごくわずかです