エイリアスをつけること自体は実行速度的に良いことらしいので命名していきたいところです。, ◎ テーブルhogeに列fugaという名前をつけたいとき、 随時更新予定です。 一覧. you can read useful information later efficiently. ・長い, ◎ 主キーにたくさんの列を使わないといけないとき(複合主キーのとき) 概要 . 画一的な略語の規約を見つけたり設定するのってなかなか難しいのですが、 かつ原則的にUPDATE, INSERTのとき指定しない列をテーブルの左端にCREATEして主キーにします。, ・WHERE句で指定しなければならない条件が少なくてすむ場合がある What is going on with this article? この方法は、従来のSQLスキーマ設計では一般的ですが、ActiveRecordを使用する場合は面倒です。 (例えばWHERE hoge.fuga = foo.barではなくテーブル名を省略してWHERE fuga = barとしてしまう書き方は) どうしても DB スキーマを変更できない場合は、少なくとも、Yii のモデル・クラスの名前を単数形に変更します。ただし、コード中に追加のコメントを記して、この不整合に対する注意を喚起しておきましょう。 フィールド名にテーブル名を追加しない 排除すべきなのだろうから、重複しないことをメリットとして挙げるのも間違っているのかもしれません。, テーブル名.列名で指定するのと、テーブル名つき列名で指定するんじゃ、  ワーク系ならw_を頭につけてw_hogeなどと命名する, ⇒イベント系ならe_を頭につけてe_hoge、 ・問題3 だけどアンダーバーだけでしか区切れないと、やっぱわかりづらい。

ほとんどのArm IPが試し放題でスタートアップは年会費無料!?Arm Flexible Access, you can read useful information later efficiently. 仕様が変わったんだから設計を見直すべきだとなるべきなのかは難しいところです。, 『関係モデルに存在しない概念を導入することになる』ことによるデメリットは、 ⇒ NOT NULL制約をつけてDEFAULT ''にする, ・NULLの扱いで悩まずに済む ⇒ とりあえず小数点以下の桁数を大きめに定義する 略語を用いる場合、その規約に従えば誰もが同じ略記をするような、明瞭な規約を掲げることができるのか? ⇒『予備1』みたいな列をつくる ほとんどのArm IPが試し放題でスタートアップは年会費無料!?Arm Flexible Access, 定数で定義 'GENDERS' => ['1' => '男性', '2' => '女性', '3' => 'その他'], 定数で定義 'BLOOD_TYPES' => ['1' => 'A', '2' => 'B', '3' => 'O'], 定数で定義 'COUNTRIES' => ['1' => 'アメリカ', '2' => '日本'], you can read useful information later efficiently. データベースやらSQLとかやらで、わからないなりに実装するかどうか悩んだことを書き連ねてみます。, ◎ 併せて読み返したい書籍 ・別のRDBMSに移植するとき少しだけ手間が増えるかもしれない. この記事は、2011年頃に書かれた Yii framework サイトの wiki 記事 Guidelines for good schema design の翻訳です。, もともとは Yii 1.1 のために書かれたものですが、Yii 2, Yii 3 にもそのまま適用可能ですし、もっと広く、アクティブ・レコードのような ORM 一般に通用する内容であろうと思われます。つまり、以下の文章中の "Yii" という名前は、あなたが使っている任意のフレームワークの名前に置き換えてもよい筈です。, 事実上すべての Yii アプリケーションはデータベースの上に構築されます。Yii はデータベースの取り扱いにおいて非常に柔軟ではありますが、以下に述べる設計上の選択をすれば、そうでない場合に比べて、ものごとがより一層都合良く進みます。, 最初に、ごく大まかに言うと、Yii アプリケーションではアクティブ・レコードを多用しますので、設計上の考慮では、複雑な SQL クエリを構築しようとする人間のことよりも、アクティブ・レコードを使う上での最適化を中心に置くべきです。実際、以下に述べる設計のガイドラインの多くは、SQL フレンドリーなスキーマを作成するための良い習慣とは真っ向から対立するものです。, しかし、このガイドラインのほとんどは、他人が読んで理解できるコードを書けるようにすることを目的としています。コードにおいては名前は 意味を持つ ものであり、一貫性に欠ける命名規約はコードを追うことを非常に難しくするのです。, このことはフォーラムやチャットの #yii チャンネルで助力を求める場合に特に当てはまります。正しい意味を反映しない変な名前を使っていると、コードが何をやっているのかを明確にするための逆質問ばかりを沢山もらって、実際の問題に対してはあまり助力を得られないということになりかねません。, とは言え、以下はガイドラインに過ぎず、規則ではありません。これらのガイドラインに従わなくても、コードは動きます。しかし、これらのガイドラインを採用する方が、楽な道を歩むことが出来ます。, SQL テーブル は複数の事物を保持するものと考えられますが、モデル はその中のたった一つの事物です。$model = new Comments() という記述は何か変です。この違和感が、リレーションを定義するときをはじめとして、どこまでも付いて回ることになります。, テーブルは comments でなく comment, invoices でなく invoice としましょう。そして対応するモデル名も単数形 (Comment, Invoice) にします。, どうしても DB スキーマを変更できない場合は、少なくとも、Yii のモデル・クラスの名前を単数形に変更します。ただし、コード中に追加のコメントを記して、この不整合に対する注意を喚起しておきましょう。, これは伝統的な SQL スキーマ設計では当り前の習慣ですが、アクティブ・レコードを使う場合には、鬱陶しいものになります。たとえば、category テーブルでは、こうです。, 長い名前のやり方は、手作業で SQL クエリを組む場合にちょっとだけ読みやすくなるのは事実ですが、アクティブ・レコードで使うのには向いていません。, Yii はテーブル・プレフィックスの考え方をサポートしています。これは共有ホスト環境で すべての アプリケーションが単一のデータベースを共有する場合に有用なものです。例えば、ブログのテーブル名の頭には blog_ を付ける、時間管理のテーブル名の頭には time_ を付けるなどすると、同じデータベースの中でお互いに干渉することなく動作させることが出来ます。, しかし、クラス名 にはこれらのプレフィックスを決して含めるべきではありません。なぜなら、干渉を回避する必要が無いからです。ブログのアプリケーションは、時間管理のアプリケーションとは全くの別物です。, たいがいのテーブルは、それ自体の独立した単一カラムのユニークなプライマリ・キーを持っています(int NOT NULL AUTO_INCREMENT PRIMARY KEY というのがよくある例です)。これが id という名前 (commentid とか postid とかではなく) を持っている方が、物事がほんの少しスムーズに動くようになります。, 名前が何であっても、Yii はデータベース・スキーマを読んでプライマリ・キーが何であるかを正しく判断します。しかし、システムの他の部分ではそれに従うことが出来ず、キーが id であることを明らかに前提としている場合もあります。, 例 : CArrayDataProvider はキーが id であると見なしています。これは keyField 属性によってオーバーライド出来るものではありますが、そもそも、そういう事をする必要が無い方が好都合です。, ただし、この規則が当てはまらない場合もいくつかあります。例えば、テーブルがマルチ・カラムのプライマリ・キーを持っている場合や、テーブルのプライマリ・キーが他のテーブルの ID への外部キーである場合などです。, 古典的な設計上の失敗の一つとして、実際の意味を持つプライマリ・キー、というのがあります。以下の例では、username が user テーブルのプライマリ・キーになっています。, 整数のプライマリ・キーを作って、name をユニークにする方が断然すぐれています。, たいていのデータベースでは、このフィールドは別のテーブルのプライマリ・キーを指し示す ID を保持している、というような、テーブル間の関係を定義することが出来ます。これが外部キー制約と呼ばれるもので、他から参照されている行が削除されるのを防止するなどして、参照一貫性を保持する上で役に立ちます。, MySQL の InnoDB は外部キー制約をサポートしています。MyISAM では、外部キー制約は 定義 することは出来ますが、強制 することは出来ません。Yii はスキーマからこういう関係を読み取る方法を知っており、Gii/Giix ツールが適切なリレーションを自動的に作成してくれます。, しかし、たとえ Yii が外部キー制約を考慮しないとしても、外部キー制約はデータベースの参照一貫性を維持するための不可欠な要素です。これについて学ぶためには、ウェブ上に沢山のチュートリアルがありますので参照して下さい。, 前項と関連しますが、他のテーブル、例えば user の ID を保持するフィールドには user ではなく userid という名前を付けます。と言うのは、まず間違いなく、テーブルに含まれるすべての外部キーについて、それに対応する リレーション を定義する必要があるからです。, Yii では、クラス変数、DB フィールド、仮想属性、リレーションは単一の名前空間を共有します。従って、$model->user をテーブルの外部キー および リレーションの 両方 を示すものとして定義することは出来ません。, 外部キーを userid という名前にすれば、BELONGS_TO リレーションである $model->user が自然で分りやすい名前になります。, メモ : id でなく Id や _id を好む人もいます。これは純然たる好みの問題です。ただし一貫性を失わないようにしましょう。, 一貫性と他人にとってのコードの読みやすさというテーマに沿って、リレーションもそれぞれの性質に応じた単数形/複数形の名前を持つべきです。, 配列を返すリレーションは、モデルを一つだけ返す場合であってもそれを 配列 に入れて返します。この事実が複数形の名前の根拠となることに注意して下さい。, コードを見ただけで、リレーションが配列を返すのか単一のモデルを返すのか、区別できるようにすべきです。, 定義を見ないと分らないと言うようでは、コードの可読性と保守性を大いに低下させていると言わざるを得ません。. ・わかりやすいかもしれない, ・すべてのSQLにおいて漏れなく区切られた識別子をつけるのは地味にたいへん ・命名できる要素の種類が多いため、十全な略語の規約設定・周知にコストがかかる |Ruby|Ruby on Rails|PHP|Laravel|JavaScript|TypeScript|Vue.js|Nuxt.js|Kotlin|Go|Android|AWS|CircleCI|Stripe|Docker... Why not register and get more from Qiita? とか言い出す人が現れるかもしれない。。。そんなひとはいない?, ◎ 将来に漠然とした不安を抱いてしまうとき By following users and tags, you can catch up information on technical fields that you are interested in as a whole, By "stocking" the articles you like, you can search right away. ・代理キーは内部的な値なので、運用や仕様の変更があってもまず影響しない 『略語は使って使わなくてもいいし、使うならご自由にどうぞ』という選択肢は妥協案として存在していいのか?, ◎ 列fuga_codeという名前をつけたいとき、 ⇒ 『is_deleted』みたいな列を用意して、0か1を入れる, ・削除された列をもとに戻したい(削除を取り消したい)とき簡単に済む ・列名が絶対に重複しない 他の開発言語で既に略記の規約が制定されているのならば、それに合わせればいいのだけれど、

同じ内容を意味する語の成分(接頭語や接尾語も)は、同じ語句を使う。たとえば、日付を表す語句に、DATEならDATE、DTならDT、BI(「~日」の日本語読み)ならBIで、どれを使ってもよいが、統一させて使う。 ちなみにNATURAL JOINが使えなくなります。, ◎ テーブルhogeが存在するとき、 ・データベース設計時に徹底してNULLを排斥しておけば、運用時に空文字とNULLが混在する事態にならない, ・そのスキーマにおいて徹底的にNULLを排斥しないと、空文字とNULLが混在して混沌と化す, MySQLは`バッククォート、SQLServerは[]角括弧、 Help us understand the problem. → テーブルを作成する人の、どこまでを自然キー、どこまでを代理キーという裁量が排除される, ◎ 表面上は削除扱いするけれど、内部的にはデータを保持しておきたいとき