• このエントリーをはてなブックマークに追加
しっかりと設計しよう。業務で使えるオープンソース(142)「データベース設計」
閉じる
閉じる

新しい記事を投稿しました。シェアして読者に伝えましょう

×

しっかりと設計しよう。業務で使えるオープンソース(142)「データベース設計」

2014-11-07 11:36

    今回のテーマはデータベース設計です。O/Rマッパー、マイグレーションなどの仕組みによってデータベースとプログラミングの垣根はどんどん低くなっています。とはいえサービスを継続運用する中でデータベースの再設計をしたくなる気持ちは高まるものです。

    そうならない、またはデータベースの寿命を延ばすためには最初の設計が肝心です。ということで今回はデータベース設計に関するオープンソース・ソフトウェアを紹介します。

    マイグレーション

    Rails辺りからデータベーススキーマの差分管理をプログラマブルに行う流れができています。インデックス含め、スキーマの管理でマイグレーションを使わない手はありません。フレームワークに限らず、各言語向けにマイグレーション管理用のライブラリが存在します。

    NoSQL

    設計の手を離れ、もうNoSQLに移行してしまうと言う手もあります。とはいえ一気にMongoDBやCouchDBに移行するという話ではなく、MySQLやPostgreSQLでNoSQLを実現するライブラリを使うという方法です。

    MySQLであればTransactdを使ったり、MySQL Clusterがあります。MySQL 5.6ではNoSQL APIが提供されています。PostgreSQLでもJSON/JSONB型のカラムが用意されており、NoSQLのように使えます。

    差分管理

    マイグレーションのようなツールを入れていない場合、スキーマを変更した開発用データベースと、本番環境の差分を保存するという手があります。そうすることで少なくとも変更点を把握しておき、差し戻しもできるようになるでしょう。

    ただしこの手のツールはスキーマのみ対応していることが多く、ビューやプロシージャは対応していないことがあるので移行時には十分注意が必要です。

    Excel/Access利用

    なんだかんだ言いつつもExcelは便利なツールで、データベース設計書を書き、それをマクロを使ってSQLにするのはさほど難しくありません。問題があるとすればマイグレーションでしょう。

    Accessを使ってテーブルをビジュアル的に設計する方法もあります。こちらもスクリプトによる変換はさほど難しくありません。メリットはソフトウェアの敷居が低いので、誰でも使えることです。

    画像出力

    データベースの全体像を把握するのに画像を使うのは良いのですが、自動出力系はすべてを出力するために大きなデータベースだと非常に分かりづらくなることが多いです。せめてリレーションが張られているものだけに限定すると言った区切りは必要だと思います。

    見やすい画像さえ作れれば、後は自動で定期的に画像化すれば良いでしょう。必要になってから準備すると煩わしいので、あらかじめ組み込んでおくと便利です。

     
    この記事は有料です。記事を購読すると、続きをお読みいただけます。
    ニコニコポイントで購入

    続きを読みたい方は、ニコニコポイントで記事を購入できます。

    入会して購読

    この記事は過去記事の為、今入会しても読めません。ニコニコポイントでご購入下さい。

    コメントを書く
    コメントをするにはログインして下さい。