Rails モデルへのユニークキーやNOT NULLの付け方

    >

プログラミングは、進む時は面白いぐらいに進むのに、詰まる時はとことん詰まる。そしてそのままフェードアウト…といったことはよく聞く話です。僕もHTMLから始めて、長いことプログラミングを続けてきましたが、どうしても自分の思い通りにいかない、実装ができない、エラーが続く、といった状況に悩まされ、うつ状態になり、もういっそプログラミングなんて辞めてしまおうか…と挫折しそうになった経験が、幾度となくあります。

プログラミングを6年続けてきて、プログラミングは自分一人で完結できるものではない、ということは痛いほど分かっています。"スタックオーバーフロー"だけではどうしようもないことも、中にはあります。 特に、新しい技術や言語に挑戦しようとする時は、難関が数多くあります。JavaとPHPは違いますし、スマホアプリが作れるからと言ってPythonができるとは限りません。多くの場合、多くの障壁に立ち塞がることでしょう。

実際、僕も多くのプログラミングをしている友人から、あらゆる相談を受けます。既存の回答や僕の知識から、最適な答えを返してあげられることもありますが、答えられないことや上手く説明できないことも多くあります。
そのような場合、僕が彼らに勧めているのが、『TechAcademy [テックアカデミー]』です。

同サービスは短期間から登録できるオンライン完結のプログラミングスクールで、他社と比較しても、そのコストパフォマンスは圧倒的です。
例えば、A社は148,000円〜のところ、同サービスは99,000円〜でコースが受講できます。( ※はじめてのプログラミングコース4週間の料金 )
また、一言に現役のプロと言っても、エンジニア歴20年以上、プログラム歴35年以上といった、まさにプロ中のプロの方たちが対応してくれるのも、『techacademy』の魅力の一つ。

国内外どこからでもチャット相談が可能で、毎日8時間、1週間あたり57時間の間、メンターが常時待機しています。
受講生限定の転職サポートで、コース受講終了後、企業やコンサルタントからスカウトが届く"TechAcademyキャリア"も、ぜひ活用したいところです。

  • オリジナルアプリをAppStoreにリリースするまで徹底サポート「iPhoneアプリコース」
  • 職業を問わず身につけたい、教養としてのプログラミングが学べる「はじめてのプログラミングコース」
  • 仮想通貨を支えるブロックチェーン技術の仕組みを学べる「ブロックチェーンコース」
  • Pythonと機械学習が学べる「Pythonコース」

『techacademy』では、上記コースをはじめとした、数多くの特化したコースが受講受付中です。プログラミングの進捗に真剣に悩んでいる方は、ぜひご活用ください。

TechAcademy [テックアカデミー]

さて、おまたせしました。

今回の記事は『Rails モデルへのユニークキーやNOT NULLの付け方』です。この記事が役に立った、と思ったらぜひ、コメントまたはTwitterやLINEでシェアしてくださいね。


プライマリーキーとユニークキーの違い

PRIMARY KEY 制約は、あるテーブルの 1つの列または複数の列に1度だけ使用できるが、UNIQUE 制約は何度でも使用できる。
PRIMARY KEY 制約を持つ列には NULL が含まれないが、UNIQUE 制約を持つ列には NULL が含まれる可能性がある。


僕もそうですが、フリーのプログラマの仕事内容は様々です。ソフトウェアを受注製作することもあれば、企業ホームページを作ることもあるでしょう。
どういったビジネスを展開するにせよ、事業を成功させるには、正しいマーケティングを行うことは必須事項です。

ミツモア』は、Googleのリスティング広告やマーケティング広告管理に煩わされることなく、狙った顧客を獲得できる、マーケティングプラットフォームです。
僕のプログラマの友人がいるのですが、彼にも『ミツモア』を紹介し、彼は現在、成功したプログラマの一人です。
どうしても疎かになってしまいがちなマーケティングですが、『ミツモア』を上手く活用し、新たな新規顧客を獲得していきたいところですね。

ミツモア

一意のユーザーIDを実装する

ユーザー登録を実装する上で出てくる課題が、「ユーザーID」です。
twitterでいう、@fumiya_jaみたいなのですね。
プライマリーキーの付属したテーブルのIDをそもままユーザーIDをにしてしまってもいいのですが、(e.g.@832748 みたいなIDになる)
そうすると、テーブルのレコードの数、つまりユーザー数が丸見えになってしまうとか、単純にユーザビリティが悪いっていうようなデメリットがあります。
なので、ちょっと面倒でも、ユーザーIDは一意のデータとしてユニークキーをつけて、実装するのが良いかと思います。

ユーザーIDをどう実装するか

ユニークキーはNULLが許可されているので、NOT NULL制約を付加します。

  • ユニークキー制約をする
# 1つのカラムに
add_index  :keywords, :site_id , unique: true

# 複数のカラムに
add_index  :keywords, [:site_id, :name, :date], unique: true
  • NOT NULL制約をする
t.string :address, :null => false
  • NOT NULL+デフォルト設定
t.string :address, :null => false, :default => 'Tokyo'

migrateファイルの一例:

class CreateDevs < ActiveRecord::Migration[5.2]
  def change
    create_table :devs do |t|
      t.string :name , :default => 'NAMELESS'
      t.string :userid , :null => false

      t.timestamps
    end
    add_index  :devs, [:userid], unique: true
  end
end

できたら、rake db:migrate

では、defaultとかNOT NULL、ユニークキーの確認をしていきます。

# テーブルのカラムの確認
Dev.column_names
=> ["id", "name", "userid", "created_at", "updated_at"]

# 最初のユーザー作成。
irb(main):004:0> Dev.create(name: 'yuis', userid: 'yuis')
   (0.0ms)  begin transaction
  Dev Create (1.0ms)  INSERT INTO "devs" ("name", "userid", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", "yuis"], ["userid", "yuis"], ["created_at", "2018-04-28 14:05:28.582549"], ["updated_at", "2018-04-28 14:05:28.582549"]]
   (61.7ms)  commit transaction
+----+------+--------+-------------------------+-------------------------+
| id | name | userid | created_at              | updated_at              |
+----+------+--------+-------------------------+-------------------------+
| 1  | yuis | yuis   | 2018-04-28 14:05:28 UTC | 2018-04-28 14:05:28 UTC |
+----+------+--------+-------------------------+-------------------------+
1 row in set


# 全く同一のユーザー名でやってみる。
irb(main):005:0> Dev.create(name: 'yuis', userid: 'yuis')
   (0.0ms)  begin transaction
  Dev Create (0.0ms)  INSERT INTO "devs" ("name", "userid", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", "yuis"], ["userid", "yuis"], ["created_at", "2018-04-28 14:05:31.971999"], ["updated_at", "2018-04-28 14:05:31.971999"]]
   (0.0ms)  rollback transaction
ActiveRecord::RecordNotUnique: SQLite3::ConstraintException: UNIQUE constraint failed: devs.userid: INSERT INTO "devs" ("name", "userid", "created_at", "updated_at") VALUES (?, ?, ?, ?)
        from (irb):5

#=> ユニークキー制約によるエラー。ちゃんと機能してますね。

# useridを別の値にして再検証。
irb(main):006:0> Dev.create(name: 'yuis', userid: 'yuis_2')
   (0.0ms)  begin transaction
  Dev Create (1.0ms)  INSERT INTO "devs" ("name", "userid", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", "yuis"], ["userid", "yuis_2"], ["created_at", "2018-04-28 14:05:47.363096"], ["updated_at", "2018-04-28 14:05:47.363096"]]
   (60.3ms)  commit transaction
+----+------+--------+-------------------------+-------------------------+
| id | name | userid | created_at              | updated_at              |
+----+------+--------+-------------------------+-------------------------+
| 2  | yuis | yuis_2 | 2018-04-28 14:05:47 UTC | 2018-04-28 14:05:47 UTC |
+----+------+--------+-------------------------+-------------------------+
1 row in set

# nameにNULLが通るか検証。
irb(main):007:0> Dev.create(name: '', userid: 'yuis_3')
   (0.0ms)  begin transaction
  Dev Create (2.0ms)  INSERT INTO "devs" ("name", "userid", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", ""], ["userid", "yuis_3"], ["created_at", "2018-04-28 14:06:01.369127"], ["updated_at", "2018-04-28 14:06:01.369127"]]
   (58.2ms)  commit transaction
+----+------+--------+-------------------------+-------------------------+
| id | name | userid | created_at              | updated_at              |
+----+------+--------+-------------------------+-------------------------+
| 3  |      | yuis_3 | 2018-04-28 14:06:01 UTC | 2018-04-28 14:06:01 UTC |
+----+------+--------+-------------------------+-------------------------+
1 row in set

# 間違えました。NULLという定数はRubyにはありませんね。
irb(main):008:0> Dev.create(name: NULL, userid: 'yuis_4')
NameError: uninitialized constant NULL
        from (irb):8

# nilにするとdefaultが発動するのか検証。
irb(main):009:0> Dev.create(name: nil, userid: 'yuis_4')
   (0.0ms)  begin transaction
  Dev Create (1.0ms)  INSERT INTO "devs" ("name", "userid", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", nil], ["userid", "yuis_4"], ["created_at", "2018-04-28 14:06:24.069276"], ["updated_at", "2018-04-28 14:06:24.069276"]]
   (75.2ms)  commit transaction
+----+------+--------+-------------------------+-------------------------+
| id | name | userid | created_at              | updated_at              |
+----+------+--------+-------------------------+-------------------------+
| 4  |      | yuis_4 | 2018-04-28 14:06:24 UTC | 2018-04-28 14:06:24 UTC |
+----+------+--------+-------------------------+-------------------------+
1 row in set

#=> 発動しませんね。やっぱりnameにも`NOT NULL`制約が必要そうです。

# nameに値自体を指定しない。
irb(main):010:0> Dev.create(userid: 'yuis_5')
   (0.0ms)  begin transaction
  Dev Create (2.0ms)  INSERT INTO "devs" ("userid", "created_at", "updated_at") VALUES (?, ?, ?)  [["userid", "yuis_5"], ["created_at", "2018-04-28 14:06:41.119073"], ["updated_at", "2018-04-28 14:06:41.119073"]]
   (82.2ms)  commit transaction
+----+----------+--------+-------------------------+-------------------------+
| id | name     | userid | created_at              | updated_at              |
+----+----------+--------+-------------------------+-------------------------+
| 5  | NAMELESS | yuis_5 | 2018-04-28 14:06:41 UTC | 2018-04-28 14:06:41 UTC |
+----+----------+--------+-------------------------+-------------------------+
1 row in set

#=> これはdefaultが発動します。

こんな感じで、制約のかけ方と検証でした。


2020年の東京五輪を間近に控え、来日外国人の数は年々増加しています。ただでさえ、あらゆる職種で"英語力"が求められる時代ですが、その中でも特筆してプログラマ、システムエンジニアには、英語力は必須であると言われています。

僕は現在、英検1級に着手し、英語力が一定水準に達した今でも、日々新しい表現や単語を学んでいます。しかし僕も最初から英語が出来たわけではありません。中学生の頃の英語の成績は、学年でほぼビリでしたし、そもそも英語なんて必要ない(若者の常套句ですね)、今後一生やることはない、と思っていたくらいです。

確かに、英語を使わずとも年収600万以上の仕事に就くことは出来ますし、生活する上で困ることもないでしょう。しかしそれは、英語を知っている世界を知らないからでしかありません。
英語に興味関心がない多くの方は、こういうことを言うと反発するのですが、プログラミング経験者の皆さんなら、そうでもないのではないでしょうか。

プログラミングをやっていて、英語が出来たらなぁと思ったこと、あるのではないでしょうか。僕が英語を始めた動機は他にありますが、一度、二度挫折した英語学習を再開する動機となったのは、紛れもなく、"プログラミング"でした。プログラミングを続けるには、英語の壁を超える必要がある、と幾度となく痛感しました。

  • エラー文章をGoogle検索せずとも理解できる
  • ソースコードに日本語が含まれる場合に起こる特有のエラーを回避できる
  • スタックオーバーフローの回答が理解できる
  • スタックオーバーフローに質問を投稿し、良質で的を射た回答を得ることができる
  • 翻訳されていないドキュメントやリファレンスを理解できる
  • 適切なメソッド名やファイル名をスムーズに定義できる
  • 需要が高く報酬の良い海外で仕事が探せる、または海外のクライアントを相手にできる

上記をはじめとした、プログラミングにおいて英語ができることのメリットは数多く存在します。
英語学習の必要性に疑問を持っていた方も、上記の一覧を見て、何か思うことがあるかもしれません。しかし、英語を学習する意義を見つけたあと、間違っていけないのが、その学習方法です。

英語学習方法には効率的、非効率的、意味がないなど、様々な方法が乱立しています。中には悪徳なものもあり、注意が必要です。
英語学習に回り道やチートはありませんが、効率的でない学習方法を避けて学習を進めていくことは、1年後、5年後の自分の英語力に取り返しのつかない差が開いてしまうことを未然に防ぎます。

そして、僕が一番信頼を置いているのが、『スタディサプリ ENGLISH』です。『スタディサプリ ENGLISH』はこれまで様々な英語に関する相談をしてきた友人への、最も勧める頻度の高かったサービスです。

留学が間近で…、ワーキングホリデーに行ってみたくて…、やっぱり英語をまた始めようと思って…、社内公用語対策で…、英会話教室に通おうと思ってて…などなど、僕への相談は様々ですが、これら全ての方に、『スタディサプリ ENGLISH』は自信を持っておすすめできます。

スタディサプリ ENGLISH

さて、最後までお読み頂きありがとうございました。この記事が役に立った、と思ったらぜひ、コメントまたはTwitterやLINEでシェアしてくださいね。

僕は個人事業として、プログラミング6年、1日14時間パソコン業務をこなしてきました。現在もウェブサイト開発やサポート、ソフトウェア制作、レビューなどライティングをはじめとしたお仕事を承っております。気になったらぜひ、メールにてご連絡ください。いつでもお待ちしております。

現在承っているお仕事の一覧
お問い合わせ

小山はるや(こやまはるや) 東京生まれ。プログラマー。現役大学生。ウェブサイト制作の傍らメディア運営を行い、2017年に開設されたITブログ『yuipro』(https://yuis-programming.com)は2019年に月間アクセス数1万を超える。 これまで80を超えるウェブサイトを制作、小山氏自ら運営するウェブサイトは8つに上り、うち2つが月当たり数万のアクティブビジターを獲得している。


Close Menu