Help us understand the problem. What is going on with this article?

テーブルの名前って複数形?単数形?

More than 1 year has passed since last update.

この記事、何?

長年、「テーブル名は単数形で書くものだ」と考えていた人が自分の考えを書いた記事。
読んでもらうとわかるけど、決して「複数形で書くのはおかしい」とは言ってない。
ただ、あたしとしては「単数形で書くものだ」という考えは変えない。(変わらなかった)

自分なりに一長一短考えてみたので・・・「なるほど」とか、「おかしい」とか、意見いただけると嬉しいです。はい。
いただいた意見で考え変えてこの投稿のタイトルを変えたくなるならそれはそれでありかな、と。

経緯

いや、少し前の話なんだけど、これから作るDBのテーブル名やコード規約とかどうしようという話が上がった際、

後輩(新人):「テーブル名は英語で複数形ですね」
自分:「えっ?英語はいいけど、なんで複数形?」
後輩:「普通2件以上のレコードを入れるから」

って会話があって、それから30分以上かけて説得して納得してもらったの。。。

まあ、それが長いことくすぶってたんだけど、別件調べごとしてたら「普通複数形で書くよね!」って書いてあって、「えっ?」と。。。
はい。これまで一度もそういうプロジェクトにかかわってこなかったのでそういう考え方があることを知りませんでした。

というわけで、自分なりに検討してみようかと。

本文

まずは比較しようと。まずは自分の考えから。
このメリットを上回るメリットが理解できれば考えを変えるつもり・・・だった。

単数形で書く派 [自分の考え]

「テーブル」自体が「複数」そのものではない

あたし的にはこれに限る。
「テーブル」は「複数のレコード」を入れる「箱」であって、「レコードの集まり」以外の情報を含む。
例えば、作成日とか、Index(への参照)とか。
C#でDataTableというクラスがあるけど、その「箱」に含まれる「行たち」はDataTatble.Rowsだしね。
だから、こうは書くけど、こうは書かない。

//これはOK
foreach (var row in table.Rows){
    //...
}

//これはNG
foreach (var row in table){
    //...
}

<参考>
■C#手遊び(Linq少しまじめに書いてみた)
https://qiita.com/siinai/items/6708fde50691def99b7a

英語の複数形って結構ムズイ

いや、学がないだけといわれればそれまでなんだけどね。
一応英語多少しゃべれるし、日常使っている私物のPCやスマホは英語モードにしてる人なんだけど、「あっ、そうだった」っていう、複数形の変化って結構ある。
datum -> data とか、有名どころだと、child -> children とか、fish -> fish とか、foot -> feet とか。
Nativeじゃない日本人としては無意識に見落とすことがあるような気がするの。

<参考>
■RailsとPHP各フレームワークの「複数形」変換処理を比較してみる
https://techracho.bpsinc.jp/wingdoor/2019_04_26/73731

単数形で書く派 [引用]

■DB スキーマ設計のガイドライン
https://qiita.com/softark/items/63e68a0172a1d2f92b5c

(引用)
テーブル は事物の複数のインスタンスを保持するものですが、モデル は単数形の事物です。
$model = new Comments() という記述は何か変です。
この違和感が、リレーションを定義するときをはじめとして、どこまでも付いて回ることになります。

本題の参考資料を漁って見つけた記事で斜め読みしていて意訳しているかもだけど、MVCとかのモデル理論で考えた時の話(と解釈した)。

根本的にはあたしの上げた最初の理由に通じることかな、と。

複数形で書く派 [引用]

(引用)
基本系 は 〜s(複数形)

■データベースオブジェクトの命名規約
https://qiita.com/genzouw/items/35022fa96c120e67c637

・・・あれっ?理由は明示されてない?

■データベース設計の命名規約について主流なものやおすすめがあればご教示ください。
http://q.hatena.ne.jp/1444110110

(引用)
テーブル名は複数形がいいっぽい(慣例、railsなど主流フレームワークの規約)

規約ならしょうがない・・・

事例参照

大きなDBソフトの公式ドキュメントを参考にしてみた。

PostgreSQL

■5.1. テーブルの基本
https://www.postgresql.jp/document/11/html/ddl-basics.html

DROP TABLE my_first_table;
DROP TABLE products;

SQL Server

■CREATE TABLE (Transact-SQL)
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql?view=sql-server-2017

CREATE TABLE Department
(
    DepartmentNumber char(10) NOT NULL PRIMARY KEY CLUSTERED,
    DepartmentName varchar(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber char(10) NULL,
    SysStartTime datetime2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    SysEndTime datetime2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (SysStartTime,SysEndTime)
)
SELECT * FROM tempdb.sys.objects
SELECT * FROM tempdb.sys.columns
SELECT * FROM tempdb.sys.database_files

Oracle Database

■データベースPL/SQL言語リファレンス
https://docs.oracle.com/cd/E82638_01/lnpls/plsql-packages.html#GUID-C285EC5A-BE50-4192-A88E-48C0778B34E0

CREATE PACKAGE emp_stuff AS
  CURSOR c1 RETURN employees%ROWTYPE;  -- Declare cursor
END emp_stuff;
/
CREATE PACKAGE BODY emp_stuff AS
  CURSOR c1 RETURN employees%ROWTYPE IS
    SELECT * FROM employees WHERE salary > 2500;  -- Define cursor
END emp_stuff;
/

・・・大きなDBソフトは複数形のほうが好きみたい。

まとめ

冒頭に記載した通り、あたしの判断としては、「テーブル名は単数形にするべき」、が現状の最適解。

局所最適解の可能性は否定しないので、固執する気はない。
だけど、恣意的な検索したつもりもないのに、複数形のメリットが「慣習」以上の解が見つけられないから意見を変えるには及ばないというのが現状。

(いや、まあ、そもそもそこを語った意見自体を見つけられなかったんだけどね・・・もしかして検索力弱い?)

なので一言ある方、コメントいただけると幸いです♪
あと、安易に意見を変えたくないので、賛同する方もコメントいただけるとありがたいです。

・・・というか、「単数なのは○○という理由があるからだ!」とかを、是非お願いします。

siinai
環境の変化があったのでちょっと方針変換。 もう少ししたら再開します。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした