Rails と Django 比較 ~テーブル作成~
今回は，データベース作成についてチョロっと書いていきます． それぞれのフレームワークは，もちろん自分でSQLを書いてテーブルを作成することはもちろん可能ですが，SQLを書かずに，またデータベースの方言なんてーのも意識しないで，大幅に少ない記述でテーブルを作成できるようになってます． てことで，それぞれのフレームワークで掲示板(BBS)のテーブル作成をしてみようと思います．
CREATE TABLE test (
id int not null auto_increment primary key,
user_id int not null,
title varchar(30),
message text not null,
create_time datetime not null
update_time datetime not null
delete_flag tinyint(1) default 0
);
- ※ create_timeは，メッセージを新規で投稿された日時を(自動)記録．
- update_timeは，メッセージの最終更新日時(新規の時は投稿日時)を(自動)記録．
- ■ Rails
- Railsでは，マイグレーション(migration)機能を利用してテーブルを作成することができます． ※ 既にプロジェクト(ここではdemoプロジェクトとする)が作成されており，データベースの設定(database.yml)が完了しているとする．
まずジェネレータを使ってマイグレーションの雛形とモデルの雛形を作成する．
migrationの雛形だけを作成してくれるジェネレータオプション(./script/generate migration)もあるのですが，同時にモデルを作成してくれた方が便利なのでこちらを使用した．
ジェネレータによって作成されたマイグレーションの雛形を編集する．
$ vi db/migrate/001_create_bbs.rb
class CreateBbs < ActiveRecord::Migration
def self.up
create_table :bbs do |t|
t.column :user_id, :integer, :null => false
t.column :title, :string, :limit => 30
t.column :message, :text, :null => false
t.column :created_at, :datetime, :null => false
t.column :updated_at, :datetime, :null => false
t.column :delete_flag,:boolean, :null => false, :default => false
end
end
def self.down
drop_table :bbs
end
end
作成日時(create_at)と最終更新日時(update_at)は，上記のCREATE SQLでいうcreate_timeとupdate_timeです． これは，railsが用意してくれている特殊なフィールド名でこのフィールド名にすると目的の自動記録というのが可能となる． ちなみに，特殊なフィールドには他に下記のようなものがある． created_at, created_on, updated_at, updated_on, lock_version, type, id, #{table_name}_count, position, parent_id, lft, rgt
では，実際にテーブル作成を実行する．
$ rake migrate
こうして出来上がったテーブルを参照すると
> use demo_development // demo開発プロジェクト
> describe bbss //
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| user_id | int(11) | NO | | | |
| title | varchar(30) | YES | | NULL | |
| message | text | NO | | | |
| created_at | datetime | NO | | | |
| updated_at | datetime | NO | | | |
| delete_flag | tinyint(1) | NO | | 0 | |
+-------------+--------------+------+-----+---------+----------------+
- ■ Django
- Djangoでは，モデルにテーブルの情報を書いて，それをデータベースに反映させることで作成する．
railsのようにテーブル作成部分とモデルという部分を分けていない．
※ 既にプロジェクト(ここではdemoプロジェクトとする)が作成されており，データベースの設定(settings.py)が完了しているとする．そこにbbsというアプリケーションを作成するという形にする． まずbbsアプリケーションの作成をする
$ ./manage.py startapp bbs
これを実行することで次のようなディレクトリが作成される．
bbs/
+ __init__.py
+ models.py
+ views.py
作成されたmodels.pyの中に作成したいテーブル情報を記述していく．Djangoではアプリケーション単位でモデルが1つ用意され，そのファイル内にアプリケーションで使用するテーブル(クラス)を複数書いていく．さらに，作成したbbsアプリケーションを有効にするためにsettings.py のINSTALLED_APPSにdemo.bbsを追記しておく．
$ vi models.py
from django.db import models
class Bbs(models.Model):
user_id = models.IntegerField()
title = models.CharField(null=True, maxlength=30)
message = models.TextField()
create_time = models.DateTimeField(auto_now_add=True, editable=False)
update_time = models.DateTimeField(auto_now=True, editable=False)
delete_flag = models.BooleanField(editable=False, default=False)
auto_now_addは，オブジェクトを生成した時の時刻を自動的に設定します． auto_nowは，オブジェクトを保存する度にその時の時刻を自動的に設定します． editable=Falseは，今回の仕様で自動ということで，フォームと関連させないようにした．
また，Djangoはフィールドの定義に色々と変わったものが用意されている． たとえば，EmailField，IPAddressField，PhoneNumberField，などなどこれは直接バリデート，フォームと関連しているのでこんなのがあるのかなぁ〜．
次のコマンドを実行することで，発行するSQLが確認できる．個人的にこれ便利で好き．
$ ./manage.py sql bbs
BEGIN;
CREATE TABLE `test_bbs` (
`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
`user_id` integer NOT NULL,
`title` varchar(30) NULL,
`message` longtext NOT NULL,
`create_time` datetime NOT NULL,
`update_time` datetime NOT NULL,
`delete_flag` bool NOT NULL
);
COMMIT;
では，実際にテーブル作成を実行する．
$ ./manage.py syncdb
こうして出来上がったテーブルを参照すると
> use demo // 今回このプロジェクトで用意したデータベース
> describe bbs_bbs // アプリケーション名がプレフィックスとなる
+-------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| user_id | int(11) | NO | | | |
| title | varchar(30) | YES | | NULL | |
| message | longtext | NO | | | |
| create_time | datetime | NO | | | |
| update_time | datetime | NO | | | |
| delete_flag | tinyint(1) | NO | | | |
+-------------+-------------+------+-----+---------+----------------+
∞ ENDLESS THINK ∞ まぁ〜フレームワークとしての構造が元々違うってーのもありますがーこうやって同時平行して2つのフレームワークを勉強してみるとーもちろん頭はこんがらがりますがー1つのフレームワークずつやっているとー気付き難い部分がー気付けて面白いなぁ〜と思いますね． たとえば，railsとDjangoのどちらが個人的にテーブル作成しやすかったかというとrailsです． それは，僕自身がSQLを書けるからだと思います．マイグレーションに書くフィールドの型の指定の仕方は CREATE文から想像がつくでしょう!? さらに最大文字数の指定方法もlimitオプションというのがーなんともクエリを知っている感じ．ところが，Djangoは型の指定の仕方もー ○○Field なんて面倒なことを書き，最大文字数もmaxlengthというオプションを使う．
ここで気付くのがープログラマーではないデザイナー(HTMLを知っている人)だったらーどちらがわかりやすいかというとDjangoになるのだろう．だもんでーDjangoの場合は独特なフィールドの型指定なんてーのもあるんだろうね（バリデートも関わってくるのでしょうけど）．
開発者達のどんな考えて，フレームワークを作成したのかなぁ〜と勝手な想像をするとまた面白い. テーブル作成というのも，どこのポディションに立ってデータベースを見つめているのかってねぇ〜
Comments
Wisdom alone is the science of others sciences.
Quotation of Plato