web-dev-qa-db-ja.com

複数と単数のテーブル名

新しいデータベースを作成するとき、どのようにテーブルに名前を付ける必要がありますか？

単数形：Clientまたは複数形：Clients？

database-designnaming-convention
43
John Isaiah Carmona

あなた次第。ただし、一貫している必要があります。

個人的に注文、製品、ユーザー、アイテムなど、各「行」が何を格納するかに基づいて、単数を好む.

これは、単一のエンティティ/タイプを使用するモデリング（オブジェクトロールモデリングによる）と一致します。

編集：

1つの理由は、リンクテーブルがある場合、複数が失敗することです。
Orders、ProductsはOrderProductsまたはOrdersProductsを返します。どちらも正しく聞こえない

または履歴テーブル（もちろんこれにはスキーマを使用できます）：
Orders-> OrdersHistoryまたは（いいえ！）OrdersHistories？ Order-> OrderHistoryのほうがいいと思いませんか？

44
gbn

単数形と複数形のテーブル名に関して、件名は物議を醸すようですが、そうすべきではありません。

テーブルは複数のレコードのコレクションですが、テーブルには、それに含まれる1つのタイプのレコードの定義に基づいて名前が付けられます。テーブルに含まれるレコードのタイプとは異なる名前を付けることが許可されている場合は、テーブルに複数形の名前を付けて、たとえば、複数のEmployeeレコードを含むEmployeesテーブルを作成できます。しかし、SQLの設計者は、テーブルとレコードタイプに個別の名前を提供していませんでした。

1つのレコードを記述するために使用するクラスの名前に対応するので、レコードタイプの名前（および拡張によりテーブル名）が単数である場合、データを使用するオブジェクト指向プログラムのほうが論理的にうまくいきます。 。

プログラムでコレクションを識別したい場合は、複数形を使用するか、またはEmployeeListやEmployeeArrayなどの適切な修飾子を使用できます。

自動コード生成や、言語の背景が異なるプログラマやプログラムでの複数形の形成についての考え方を持つプログラマにとっては、不規則な複数形の問題もあります。

英語は、適切で適切なプログラミング言語ではありません。データベースやプログラムのステートメントを英語に準拠させようとすることは、それらのステートメントの1つを読むほうが良いように聞こえるのは間違いです。

8
Bruce Patin

@gbnの answer と同様に、これは好みの問題であると思います。彼と同様に、選択したすべての場所に（少なくともDB内で）適用することをお勧めします。一貫性はそれだけの価値があります。

ただし、SELECTステートメントの方が複数形の方がいいようです。

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

この場合、少なくとも、テーブルには何人かの人がいて、その数人がクライアントに返されます。

5
Andrei Rînea

「注文」は予約語です。 「注文」は

「ユーザー」は予約語です。 「ユーザー」は

「セッション」は予約語です。 「セッション」は

「結果」は予約語です。 「結果」ではない

「相対」は予約語です。 「親戚」ではない

...

これらは、基幹業務データベースに入る一般的な単語のように見えます。複数の単語は、単数の単語よりもキーワードとして一般的ではないようです。したがって、SQLキーワードとの競合を回避するために、複数のテーブル名を使用することが有益な場合があります。

5
Neil McGuigan

SQLテーブルには複数の名前を付ける必要があると思います。それは単にはるかによく読みます。

本の記録の表は、本と呼ばれるべきです。 ORMも同じ規則を使用する必要があります。 Booksオブジェクトはコレクションであり、Books Tableのすべてのレコードを管理します。 Bookオブジェクトは、単一のレコードを管理します。

これにより、コーディングがより自然になります。

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name
1
dlink

数年間プログラミングを扱った後、私は複数形化は不必要な複雑化であると結論づけました。 KISS哲学によると、プログラマーは時間と効率の理由からすべての問題に対して最も遅延して最も簡単な解決策を模索する必要があります。したがって、単数形ではすべてのシナリオで必要な作業が少なくてすみます。

1
ColacX

私たちは物事を異なる視点から見ており、私は2つの陣営が次のように識別されると思います。

単数形（ "ユーザー"）
テーブル名と、それが複数の行を含むことができるコンテナを表すという事実との間の相関関係を作成する人。

したがって、「ユーザーコンテナ」には複数の行を含めることができます。

複数形（ "ユーザー"）
テーブル名とそれがコンテナを表すという事実を関連付けない人。もちろん、彼らはそれがコンテナであることを知っていますが、名前にはありません。

例えば.
「卵のカートン」には複数の卵を入れることができますが、コンテナー参照が名前に含まれているため、複数の卵の可能性があるため、それは明らかです。ただし、単一のテーブル名「user」では、コンテナ参照は名前にありません。たとえば、「user_container」は、複数の名前を好む人には受け入れられるでしょう。

これは、何年にもわたって複数の言語が一般的に行われており、ほとんどのオンライン教材にあるためだと思います。

以上のことから、技術的に言えば、単一のコンテナーに名前を付け、複数の（または単一の）行をコンテナーに含めることができる場合、単数形の方がより正確であると思います。
名前付きコンテナをコンテンツに精神的にリンクするのではなく、複数の行に複数の名前が必要です。

いつものように、多くの場合、善悪はありませんが、それはシナリオに適したものに関するものであり、重要なことに、選択したものと一貫していることが重要です。

あなたがプロジェクトを単独で行っており、あなたが最も良いと思うものを何でもする、または単に好みをするという本当の理由がない場合。開発チームの場合も同じように適用し、満場一致で決定します。

0
James

それはとても個人的なことです。単数形を30年間使用しています。しかし、人々が複数形を好む理由がわかります。本-著者は面白いです。私は本の著者は間違っていないと思います。本には1人または複数の著者を含めることができます。また、著者は1冊以上の本を執筆している場合があります（例：共同執筆）。また、複数の著者が書いた本をどのように扱うかにも依存します。私は他の答えに同意します。 1つを選択し、一貫性を保つ。予約語の問題に関して。回避策の名前を考え出すのは難しくないと思います。ユーザー-> app_user、セッション-> app_session、注文-> customer_order

0
Ray