複数のテーブル名と特異なテーブル名

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

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

あなた次第。ただ一貫してください。

個人的には、各* row "が格納するものに基づいて、注文、製品、ユーザー、アイテムなどの単数形を好む

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

編集：

1つの理由は、リンクテーブルがあるときに複数形が失敗することです：
Orders、またはProductsを与える。どちらも聞こえないOrderProductsOrdersProducts

または履歴テーブル（もちろん、このためにスキーマを使用できます）：
Orders-> OrdersHistoryまたは（いいえ！）OrdersHistories？Order-> OrderHistory良くなりませんか？

単数のテーブル名と複数のテーブル名に関して、主題は議論の余地があるようですが、そうすべきではありません。

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

データを使用するオブジェクト指向プログラムでは、1つのレコードを記述するために使用するクラスの名前と一致するため、レコードタイプの名前（および拡張によりテーブル名）が単数のままである場合、物事はより論理的に機能します。

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

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

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

@gbnの答えと同じように、これは好みの問題だと思うので、彼と同じように、あなたが行った選択はどこにでも（少なくともそのDBでは）適用することをお勧めします。一貫性には価値があります。

私の好みは、しかし、複数形はSELECT声明でより良いことです：

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

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

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

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

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

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

「相対」は予約語です。「相対」は

...

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

SQLテーブルには複数の名前が必要だと思います。読みやすくなります。

本の記録の表は本と呼ばれるべきです。ORMは同じ規則を使用する必要があります。Booksオブジェクトはコレクションであり、Booksテーブルのすべてのレコードを管理します。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

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

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

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

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

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

複数（「ユーザー」）
テーブル名と、それがコンテナを表すという事実との間に相関関係を持たない人。もちろん、彼らはそれがコンテナであることを知っていますが、名前にはありません。

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

これは、長年にわたる複数の慣習が一般的な慣習であり、ほとんどのオンライン教材にもあると思います。

これはすべて、技術的に言えば、単一のコンテナに名前を付けており、コンテナには複数の（または単一の）行を含めることができるため、単数形はより正確だと思います。
名前付きのコンテナをコンテンツに精神的にリンクするのではなく、複数の行が複数の名前を必要とするため、人々はテーブル名をコンテンツに精神的にリンクするため、人々には間違っているようです。

いつものように、多くの場合、善悪は存在せず、シナリオに適したものであり、重要なことは選択したものと一貫性があるということです。

あなたがプロジェクトを単独で行っており、あなたが最高だと思うものを何でもするか、単に好みをするかのどちらかの道を行く本当の理由がない場合。開発チームにいるときに同じことを適用し、全員一致の決定を下してください。