このために 1 つのレコードに 100 個のフィールドを含めることは、率直に言って間違っています。そうしないでください。
代わりに、独自の主キーと親テーブルにリンクする外部キーを持つ新しいテーブルを作成すると、このテーブルの各行に URL とラベルを保持できます。次に、親ごとに 100 行以下がこのテーブルに格納されるようにアプリケーションを設定できます。
はい、慣用句はあなたが今持っているものとはかなり異なりますが、はるかに優れています.
コメント用に編集:
SQL は、「物の集まり」をテーブルの行としてモデル化するのが最適です。データベース モデルの古典的な議論のポイントは、特定のデータについて話しているときです。質問は必然的に「これらの項目が 1 つあるのか、それとも複数あるのか」ということになります。
アイテムが 1 つだけの場合、これはテーブル内の行のフィールドとしてモデル化するのが最適です。多数ある場合、これらのアイテムはテーブル内の個々の行として最適にモデル化されます。
今、あなたは次のようなものを持っているかもしれません:
create table user {
id number primary key not null,
firstName varchar(30),
lastName varchar(30),
url1 varchar(1024),
url1label varchar(30),
url2 varchar(1024),
url2label varchar(30),
url3 varchar(1024),
url3label varchar(30),
url4 varchar(1024),
url4label varchar(30)
}
このような繰り返しフィールドを持つことは、原則として、SQL データベースでは「悪い」パターンです。すべてのルールには例外がありますが、原則として、始めたばかりの場合は悪い考えです。少なくとも、実際に使用する URL フィールドの数に関係なく、これらすべての URL フィールドのスペースを占有しています。
第 2 に、SQL の観点からは、これらの多数の繰り返しフィールドを扱うのは非常に困難です。たとえば、URL としてhttp://google.comを持っている人がいるかどうかをデータベースに照会するのは簡単ではありません。次のようなひどいものが必要です。
select * from user where url1 = "http://google.com" or url2 = "http://google.com" ...
したがって、より良いモデルは次のようなものになります。
create table user {
id number primary key not null,
firstName varchar(30),
lastName varchar(30),
}
create table urls {
id number primary key not null,
user_id number not null references user(id),
url varchar(1024),
label varchar(30)
}
ここでは、各 URL 行に独自の主キーと、user_id を介して URL が属するユーザーへの参照があります。
ユーザーのすべての URL を取得する場合は、次のようにします。
select * from urls where user_id = 123
現在、データベースは、ユーザーが保持できる URL の数に制限を設けていません。ユーザーは、0、1、または 100 万を持つことができます。ここでは、データベースはいかなる種類の制限も適用しません。それらを 100 個の URL に制限したい場合は、アプリケーションでそれを行う必要があります。
しかし、1 人のユーザーが 2 つの URL を持っている場合、urls テーブルには 2 行しかないのに対し、50 個の URL を持つユーザーは 50 行しかないことがわかると思います。
1 つしかない他のフィールド (名と姓など) の場合、それらはすべてプライマリ ユーザー テーブルのフィールドである可能性があります。
ただし、繰り返されるフィールドは、親への外部キーを持つ独自のテーブルとしてより適切に表現されます。