ラベル MySQL の投稿を表示しています。 すべての投稿を表示
ラベル MySQL の投稿を表示しています。 すべての投稿を表示

2016年6月6日月曜日

MySQL Workbenchを使うとJSON型の編集が楽になる

中国地方DB勉強会 in 米子で梶山さんがデモでJSON型のcolumnを簡単に編集してたのでその話。



つまりはこの事。
超便利なので皆にも知って欲しいのでまとめます！

1 事前準備


まずJSON型を使うためにMySQL 5.7を用意します。
そして次にMySQL Workbenchをインストールします。
既にMySQL Workbenchを使ってる人への注意点として6.3.5以降を使ってください。
そしてデフォルトの対象が5.6になってるので5.7に変更します。



あとはtableを作ってデータを登録します。
今回は下記のようなtableを作ってます。

CREATE TABLE `demo_json` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `doc` json DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4;

テストデータは婚活と言えばオミカレがAPIあるのでそこのデータを利用しました。
（xmlなんでJSONに変換してから登録しました）

お見合いパーティーAPI


2 JSONの表示

さて入ったデータがこちらです。


当たり前ですがJSONが1行になっているのでこれを編集しようと思うと辛すぎます…
そこで今回のViewerの出番です！
まず編集したい行で右クリックします。
そこでOpen Value in Editorを選択してください。


するとなんということでしょう！
JSONのタブをクリックすると整形済みで表示されます！


更に下部のタブのTreeをクリックするとフィルタリングも出来ます。



3 JSONの編集

でも本題は編集が辛いことです。
見るだけならCUIでjqなど使うことでも対応できます。
任意の要素を選択してF2を押してください（ダブルクリックでもOK）


なんと要素ごとに編集できます！！


保存後、再度確認するとちゃんと変更されています。


これでちょっとした編集の時にSQLを書く辛さは不要です！
またデータの中身が見たいのに整形用のワンライナー書いたりしなくても大丈夫です！
非常に便利なのでJSON型を使う人は是非合わせてMySQL Workbenchを使ってみてください。

やっぱこういうこと教えて貰えるから中国地方DB勉強会は最高なんだよな（ステマ
投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年4月18日月曜日

PHPerに知ってほしいRDBの事について話した - PHPカンファレンス北海道 2016

4/16に開催されたPHPカンファレンス北海道 2016に遊びに行ってきました。

#phpcondo2016 まとめ


初めてのPHPカンファレンスで緊張もしましたが色々と刺激的ですごく楽しい一日でした！！
その中で30分のセッションをやらせていただきました。
その時の資料がこちらです。



30分のセッションに対し140枚以上というなかなかハードな感じでした。
駆け足になったので聴衆の人には優しくなかっなぁとも思いつつ、伝えたい事は伝えれたかなと思ってます。
あと懇親会で聞かれた質問の回答も載せときます。

質問：PostgreSQLに対するMySQLのメリットってなんですか？

最新版同士で比べた時のメリットは僕は兎にも角にもSSDと相性が良い事だと思います。
金の弾丸で殴った時の費用対効果が凄くいい。
クラウドなら例えばRDSとかSSDだしスケールアップで有る一定のところまですぐ早くなります。
オンプレならFusion-ioを使えばそれこそ数十倍と言う速度が手に入る可能性もかなり高いです。
PostgreSQLはdisk-ioがヘビーなケースは苦手なのでMySQLはSSDの相性の良さと相まってそんなケースではMySQLかNOSQLになると思います。
この辺はLinkBenchでPostgreSQLをベンチマーク取った時の話が凄く面白いので興味がある人は見てみてください。


MyNA・JPUG 合同勉強会

※このまとめの「MySQLメインの人がPostgreSQLのベンチマークをしてみた話」です。
他の話も面白いので興味があればぜひ。


あと商用ライセンスを買った時に使えるOracleのサポートメンバーが誰か？っての想像できる事も大きなメリットです。
あの漢らしい人とかに1台30万くらいでSQLレベルからサポートしてもらえる。
これって普通に凄いことですよね。

質問：ORM使ってるとMySQLで何も困らないんですけど？

仰るとおりでございます。
ORMのオブジェクトをRDBで上手く表現（テーブル設計）してる時はORMめっちゃ便利です。
その場合ってMySQLと相性良いと思いますしMySQLで困らないです。
強いて言えばINDEXの設計がちょっとむずかしいかもなぁってくらい。
MySQLからPostgreSQLに行くメリットよりデメリットが勝る場合も多々あるので既存でMySQLで問題ないならそのままで良いです。
ただ新規案件の時とかはPostgreSQLを新たに採用するメリットが結構あるので検討していただければと思います。


といった感じで次は5/21にPHPカンファレンス福岡 2016です！
北海道のネタをベースにまたPHPerの皆様に知ってほしいことをお伝えしようと思います。
INDEXの話は評判が良かったのでそのままに他の部分をチューニングしようと思います。
ということでPHPカンファレンス北海道 2016、本当に最高でした！！




おまけ

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2016年3月17日木曜日

MySQLに絵文字を保存しようとしたら文字列が消える問題

最近、すっかりPostgreSQLの匂いがしなくなったと噂の私です。
最近MySQLで新たな気付き（問題）があったのでメモとして残します。

まずMySQLは🍣🍻問題があることは知っていました。

MySQL と寿司ビール問題


ではutf8mb4以外で保存していた場合どうなるのでしょう？

・latin1の場合


絵文字は文字化けします。
そして非常に残念な事にALTER文で変更した場合はどうでしょう？
Slackで質問したらみんな大好き@yoku0825さんが試してくれました。

mysql57> create table t2 (val varchar(32) charset latin1);
Query OK, 0 rows affected (0.02 sec)

mysql57> INSERT INTO t2 SET val= x'F09F8DA3';
Query OK, 1 row affected (0.01 sec)

mysql57> SELECT HEX(val) FROM t2;
+----------+
| HEX(val) |
+----------+
| F09F8DA3 |
+----------+
1 row in set (0.00 sec)

mysql57> ALTER TABLE t2 CONVERT TO CHARACTER SET utf8mb4;
Query OK, 1 row affected (0.06 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql57> SELECT HEX(val) FROM t2;
+------------------+
| HEX(val)         |
+------------------+
| C3B0C5B8C28DC2A3 |
+------------------+
1 row in set (0.00 sec)

…壊れてますね。
この場合は@tmtmsさんのアドバイスを引用すると

latin1 に utf8mb 文字を入れてしまった場合は、データを HEX ダンプして、テーブルを utf8mb4 で作り直して、ダンプデータをリストアって感じで、復旧したことはあります。

とのことです。
辛いやつですね。

ちなみに@yoku0825さんがこちらで詳しく検証してくれてます。

latin1からutf8mb4_binへの変換:yoku0825さんのGist

・unicode*_ciな場合


例えばutf8_general_ciの場合ですね。
この場合は

絵文字を含めた以降の文字が全部捨てられて保存されます


つまり何も残りません。
これが今回のタイトルの現象ですね。
僕はこれに遭遇しました。
MySQL5.6でSQL_MODE=""とかしてた場合Errorも吐きません。
すーっと切り捨ててINSERTされました。
絵文字を使わせないって方針の場合は

sql_mode= STRICT_TRANS_TABLES

とかしとくとErrorで弾いてくれるそうです。



ということで4バイト文字関連ですが
|                    | utf8mb4_bin | utf8mb4_general_ci | utf8mb4_unicode_ci | utf8mb4_unicode_520_ci|
|--------------------|-------------|--------------------|--------------------|-----------------------|
| Hiragana-Katakana  | cs (unkind) | cs (unkind)        | ci (good)          | ci(good)              |
| Youon              | cs (good)   | cs (good)          | ci (critical)      | ci(critical)          |
| Dakuten-Handakuten | cs (good)   | cs (good)          | ci (critical)      | ci(critical)          |
| Wide-Narrow        | cs (unkind) | cs (unkind)        | ci (good)          | ci(good)              |
| Sushi-Beer         | cs          | ci                 | ci                 | cs                    |

https://bugs.mysql.com/bug.php?id=79977

なので


  • 文字コード　utf8mb4
  • collation　 utf8mb4_bin　または　utf8mb4_general_ci


とするという結論です。
既存環境でいきなり絵文字が消える場合や化ける場合は上記の環境をチェックしてみてください。
下記の通りになってれば🍻も🍣も登録出来るはずです。

mysql> show variables like '%character\_set\_%';
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| character_set_client     | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database   | utf8mb4 |
| character_set_filesystem | binary  |
| character_set_results    | utf8mb4 |
| character_set_server     | utf8mb4 |
| character_set_system     | utf8    |
+--------------------------+---------+
7 rows in set (0.00 sec)

# おまけ

さっきのバグチケットですがMySQL5.8でutf8mb4_unicode_520_ciがデフォルトになりそうって噂です。
見ての通りutf8mb4_unicode_520_ciだとクリティカルな問題があるので是非

右上くらいに有るボタンのAffects meポチって

ください！！

投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年3月3日木曜日

第2回 MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会 in 東京を開催してきた

先月の話ですが半年ぶりくらいに合同勉強会してきました。
資料のリンク等はポータルサイトにまとめたので下記のリンクから辿ってください。


第2回 MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会 in 東京


■登壇資料など
中国地方DB勉強会のポータルサイトにまとめました。

中国地方DB勉強会


※今回は動画の配信があります

■メーリングリスト
次回の告知についてはMLやDoorKeeperを使います。
興味がある方はチェックしてみてください。

・中国地方DB勉強会ML Google Group

・DoorKeeper

■関連slack

MySQLCasualのSlackはこちら

PostgreSQLのSlackはこちら

■twitterのまとめ

・ぬこさんバージョン
http://togetter.com/li/940915


・yokuさんバージョン
http://togetter.com/li/940891


大変素晴らしいセッションばかりで本当に楽しい会でした。
今回も例に漏れず関東の洗礼を受け、ドタキャン率は高めでしたが来てない人は本当に勿体無い内容だったと思います。
次回があるかはわかりませんが次回の中国地方DB勉強会は4月に福山を予定してます。
皆様のご参加お待ちしております。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2015年12月18日金曜日

MySQLの暗黙の型変換の話

この記事はMySQL Casual Advent Calendar 2015の18日目です。
昨日はwinebarrelさんの「binlog_cache_sizeにメモリを食われた話」でした。
こういった実践の話は非常に貴重なので勉強になりました。

さて「PostgreSQLと比べてMySQLのいいところ書く！」を書こうと思ってたのですが昨日こんなツイートを見かけました。





公式ドキュメントを見てみると…

NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます。

SELECT * FROM tbl_name WHERE date_column IS NULL
ODBC では '0000-00-00' 日付値がサポートされていないため、一部の ODBC アプリケーションを取得する際に、これが必要になります。


なるほど。
一部のODBCに対する優しさなんですね！！

そして僕もつい先日、MySQLの暗黙の型変換の罠優しさを味わったのでご紹介します。

-- テーブルの構造 `hoge`

CREATE TABLE IF NOT EXISTS `hoge` (
  `id` int(11) NOT NULL,
  `val` varchar(255) NOT NULL
);

mysql> SELECT * FROM hoge;
+----+--------+
| id | val    |
+----+--------+
|  1 | ONE    |
|  2 | 2      |
|  3 | Three3 |
|  4 | 4Four  |
+----+--------+
4 rows in set (0,00 sec)

こんなtableがあったとします。
そこで次のように検索してみましょう。

mysql> SELECT * FROM hoge WHERE val = "0";
Empty set (0,00 sec)

mysql> SELECT * FROM hoge WHERE val = 2;
+----+-----+
| id | val |
+----+-----+
|  2 | 2   |
+----+-----+
1 row in set, 3 warnings (0,00 sec)

想定した感じですね。

mysql> SELECT * FROM hoge WHERE val = 4;
+----+-------+
| id | val   |
+----+-------+
|  4 | 4Four |
+----+-------+
1 row in set, 3 warnings (0,00 sec)

あれ？文字列がマッチしましたね…
あっ！これPHPの文字列からintにキャストした時と一緒か！？

mysql> SELECT * FROM hoge WHERE val = 3;
Empty set, 3 warnings (0,00 sec)

あれ？Three3が出ない…

SELECT * FROM hoge WHERE val = 0;
+----+--------+
| id | val    |
+----+--------+
|  1 | ONE    |
|  3 | Three3 |
+----+--------+
2 rows in set, 3 warnings (0,00 sec)

Why,MySQL People！！

そしたら我らが@yoku0825さんが次のように教えてくれました。

val = 0の場合、0を文字列にキャストするのではなく、valをDOUBLEにキャストして0と比較しています。
英字で始まるSTRINGはDOUBLEにキャストできずにキャスト後の値が0になりますが、123abcのような文字列は「できるところまでキャストする」ので、キャスト後の値は123になります。
つまり123 <> 0です
ってことで、「数字で始まらないval」のものだけが検索に引っかかるわけです。
そして逆に数字から始まらない文字列はWHERE val=0に該当するわけです。

勉強になりますね！！
ちなみに僕が暗黙の型変換僕がハマったのはPHPのSESSIONをDBに保存している場合に検索しようとすると引っかかりました。
DBにSESSIONを保存することは多々あって例えばEC-CUBEやMagic3などのCMSも保存してるのでみなさんも検索の時はご注意ください。

ということで僕のMySQLエキスパートへの道は遠いようですｗ
それでは最後はとみたさんのお言葉で締めあせていただきます。



みなさんも良いMySQLライフを！！
投稿者 時刻: 0 件のコメント:
ラベル: ,

2015年10月12日月曜日

2大OSSデータベースのMySQLとPostgreSQLの違いについて話してきた

第32回 PostgreSQL 勉強会(2015年10月10日)で登壇してきました。
内容は前に書いたエントリーの


を元に発表してきました。
と言っても今回は参加者がPostgresSQLに詳しい前提だったのでMySQLを中心に話をしました。
実際の資料は下記のとおりです。
当日はビデオ撮影があったのでそのうち動画が上がると思います。

第32回 PostgreSQL 勉強会まとめ ~ togetter ~




流石に２時間は疲れました。
内容としては眠くならないように面白おかしく伝えようと思ったのですがなかなか難しかったです。
前半はMySQLとPostgreSQLの方向性の違いをメインにしました。
後半はMySQLは僕が実際にハマった事などをメインにしました。
個人的にはRDBの選択は適材適所以上の答えは無いと思ってます。
MySQLの並列処理性能やレプリケーションはPostgresSQLには足りないものです。
PostgresSQLの方が素晴らしいではなく住み分けだよと伝えたつもりです。
資料だけだとMySQLのDis話がメインなのですれ違いが無いようにここで補足しておきます。
実際にもっと深く知りたい人はMyNA会やPostgreSQLカンファレンスに来てもらえたらと思います。
ということでPostgreSQL勉強会デビューの話しでした。

####追記####



マサカリ訂正をいくつかいただいたので追記します。
間違った知識広がったらいけませんし。

１. トランザクションレベルのSERIALIZABLEの挙動の誤記
SERIALIZABLEの読み取りロックはNOって書いてますけどYESが正しいです。
PostgreSQLもMySQLもSERIALIZABLEにするとロックを獲得すると他トランザクションのSELECTに対してもロック待ちさせます。
SERIALIZABLEについては触れなかったので当日は誰も気づいてなかったぽいですが間違いです。

2. MySQLのInnoDBはREPEATABLE READはファントムリードしない
PostgreSQLはするのでそういうもんだと思ってました。
デフォルトのREPEATABLE READが堅いということになります。
MySQLすごい！！

3. @yoku0825さんからの指摘事項がいっぱい



















つまり、みんな@yoku0825をフォローしよう。
（いつもアドバイスありがとうございます）

#スライドの中で話題にした本並べときます







投稿者 時刻: 0 件のコメント:
ラベル: , ,

2015年8月25日火曜日

MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた

昨日書いたエントリがなかなかいい感じに拡散された。

MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと


で気付いた。
多分本当にMySQL5.7の罠が理由でPostgreSQLに移行する人は上のエントリを求めてない。
つまり本来ターゲットにすべき人は


  • SQLはORMが解決してくれるから違いなんて気にしない
  • ロジックはSQLではなくアプリケーションコード側が行う
  • DBはデータを置くストレージだ、いいね？


みたいな人だ。
前述のエントリでよしPostgreSQL使おう！！って人は多分MySQL使っても乗り越えていける人たちだ。
勿論そんな人達がPostgreSQLに来てくれるのは嬉しいし大歓迎。
それとは別にもっと窓口を拡げるために必要な移行時の罠をまとめておく。
これはMySQLと比較しながらPostgreSQLの事を書く。
だが初めてPostgreSQLを触る人は知っておいた方が良いことのまとめになるはずだ。


1. DBを作成するときの罠


一番最初にPostgreSQLをLinux等にインストールすると
service postgresql-9.4 initdb
をまずはすると思う。
その場合、PostgreSQLのデフォルトのロケールはOS側に設定されているロケールを使用する。
つまり多くの場合は

ja_JP.UTF-8

となる。
これに伴いDBが壊れるということはない。
ただしソート順に影響する。
具体的には

日本語ロケールでは辞書順（カタカナ→ひらがな, 清音→濁音→半濁音) の順にソートされる

のだ。
多くのシステムの場合、これは想定外のソート順になる。
そのためDBを作成する際には

service postgresql-9.4 initdb --locale=C

service postgresql-9.4 initdb --no-locale
を指定することになる。
どちらも同義である。
こちらを行うことにより文字のバイナリ値を基準にしたソートになる。
絵文字でソートしたい場合も安心だ。
詳しくは下記のエントリを参考にして欲しい。

ロケール(国際化と地域化)



2. アクセス制御の罠


MySQLに対するアクセス制限はmy.cnfに
bind-address = 127.0.0.1
と書いたりMySQLのuserテーブルで指定したりする。
それに対し、PostgreSQLはDBをインストールしたフォルダ内のpg_hba.confで制御する。
こちらについては先日紹介したとみたさんのエントリでも紹介されている。

MySQLユーザーがPostgreSQLを触ってみたメモ


その際に気をつけてほしいことがある。
それはMETHODの指定である。

host    all    all    192.168.0.0/24    trust
としてあったとする。

これは192.168.0.1~192.168.0.255のIPアドレスからのアクセスはパスワード認証無しでアクセスできる設定だ。
もしこのDBが外に晒されており、全てのIPを表す0.0.0.0/0を指定した場合は自由にアクセスできる事になる。
PostgreSQLはdefaultでスーパーユーザーとしてpostgresというユーザが作成される。
この状態でpostgresユーザでアクセスすれば...結果は明白である。
笑い事に聞こえるかもしれないがEC2やVPSでDBを作っている場合に一時的にtrustを指定する人を見かける。
そして設定は明示的にに読み込みを行わなければならない。
ここに大きな罠があり


  1. 確認のためpg_hba.confに0.0.0.0/0　trustを指定して起動。
  2. テスト終了後、pg_hba.confを修正
  3. 再起動時や再読み込みを忘れる


とするとpg_hba.confは正しいのに誰でもアクセス出来る状態のままとなる。
せめてmd5を指定するようにしよう。

host    all    all    192.168.1.1/32    md5

詳しいpg_hba.confの説明等は公式documentを読んで欲しい。

19.1. pg_hba.confファイル


なお蛇足だがそもそもpostgresql.confの設定で

listen_addresses = '*'

を指定しないとdefaultではlocalhost以外からアクセス出来ない。
設定箇所が2箇所あるので要注意だ。


3. テーブル作成時の罠

MySQLからPostgreSQLに移行した時、仮にpgadmin3を使って型を指定しようとしたら驚くだろう。
余りにもデータ型の種類が多いからだ。
データ型についてはまず公式documentのリンクを紹介しておく。

第 8章データ型


君たちが欲しいのは


  • 数値型
  • 文字列型
  • 日付/時刻型


だと思う。
それぞれについて簡単に解説しておく。

●数値型

通常は


  • bigint　　8byte整数
  • integer　 4byte整数
  • smallint　2byte整数
  • numeric　 MySQLのDECIMAL相当
    (MySQLではnumericはDECIMALのエイリアス)


で事足りると思う。
ただPostgreSQLにはこの他に論理値データ型として


  • boolean　 1byte


がある。
勿論入るのは0 or 1 or NULL（許可した場合）だ。
SQLとしてはtrue or falseでもよい。
他にも柔軟に受け入れるので使う場合は公式documentをチェックされたい。

論理値データ型


そしてサロゲートキーを使いたい場合にMySQLはAUTO INCREMENTを指定すると思う。
AUTO INCREMENTはPostgreSQLには無い。
その代わりシーケンスを作り、該当の整数型のdefaultにnextval(シーケンス名)を指定することで同義になる。
とは言ったもののその手順は煩雑だ。
そのため最初から


  1. 整数型の指定
  2. シーケンスの作成
  3. 該当シーケンスをdefaultに指定


を全て丸めてやってくれる型がある。
それがserial型だ。


  • bigserial　　　→　　bigint
  • serial　　　　 →　　integer
  • smallserial　　→　　smallint


なおPostgreSQLのシーケンスは最大値に行った場合にCYCLEの指定の有無で周回するか決まる。
CYCLEを指定しない場合はNO CYCLEとなり周回せずにエラーが発生する。
だがserial型で作った場合はCYCLEが指定されない=最大値になるとエラーが発生する。
また自分で設定すれば連番の取得の昇降やSTEP、MAXやMINも指定できる。
CYCLEを指定して周回するIDも作れる。
またAUTO INCREMENTと違い複数テーブル（またはカラム）からも参照、指定することが出来る。
シーケンスはMySQLには無い概念なので一度調べてみると設計の幅が広がるのでオススメだ。

●文字型

PostgreSQLの文字列型は


  • character varying　可変長
  • varchar　　　　　　character varyingのエイリアス
  • character　　　　　空白を埋める固定長
  • char　　　　　　　 characterのエイリアス
  • text　　　　　　　 制限なし可変長


となる。
実際は可変長、固定長、制限なしの可変長だ。
多くの運用の場合、固定長を使うメリットがない。
なので可変長のcharacter varying(以下varchar)かtextを使うことになる。
またvarcharとtextの違いは制限の有無のみだ。
そのため参照速度だけで言えば制限のオーバヘッドの少ないtextの方が早い。
また制限する場合は


  • varchar(n)


とnを指定することになるがnは文字長(文字数)だ。
バイトでは無いので注意が必要だ。
(MySQLの場合のVARCHARはバイト数)
(MySQLも文字数だった、yoku0825さんご指摘あざます！！あと誕生日もおめざす！！)



仕様として標準SQLに準拠しているのだがそもそも標準SQLの仕様に癖がある。
一度公式documentを拝読しておくと救われるかもしれない。

8.3. 文字型


またMySQLとの大きな違いとしてPostgreSQLの文字列型は文字の大小を区別する。
('A' != 'a'である)
つまりMySQLのBINARY属性を指定した状態と同じ挙動である。
文字列に関してはMySQLと大きく違う仕様が多いので注意が必要だ。
（これは逆も然りでPostgreSQL使いがMySQLを使う際に多くの人がこの罠にハマる）
蛇足としてPostgreSQLの多くの関数は文字列を受け付ける際はvarcharを指定してもtextにCASTされる。
そういった理由からよく文字列型は全てtextを指定する設計も見かける。
その場合は不正なデータを入れられた時の予防やディスク容量計算が難しくなる。
適正な型指定はデータを守るのでCHECK制約と合わせて使いわけよう。
更にPostgreSQLには列挙型(enum)もある。

8.7.1. 列挙型の宣言


(MySQLにもEnumがあるらしい)



CHECK制約とは違いデータにソート順を持たせることが出来る。
覚えておいて損はないだろう。


●日付/時刻型

日付/時刻型は

  • timestamp　　日付と時刻両方を持つ　例：2015-01-01 00:00:00
  • date　　　　 日付を持つ(時刻無し)　例：2015-01-01
  • time　　　　 時刻を持つ(日付無し)　例：00:00:00
  • interval　　 時間間隔　　　　　　　例：1 year 2 months 3 days 4 hours 5 minutes 6 seconds

がある。
timestampはMySQLのdatetime相当だ。
timestampとtimeについてはtime zoneを持たせることが出来る。
（これによりMySQLのtimestampを表現することが出来る）
指定した場合はUTCとして内部で持ち、表示の際に設定されたタイムゾーンに合わせて計算してくれる。
国内で使う場合はタイムゾーンを指定しないtimestamp without time zoneで問題ない。
またMySQLのtimestampのdefaultのようにUPDATE文の対象になった際に自動的に対象レコードの指定columnをCURRENT_TIMESTAMPで更新する機能は無い。
同じようにしたい場合はトリガーを書くことになる。
これは非常に便利なのでPostgreSQLにも欲しいところだ。
またintervalについては癖の強い型だ。
そのほかの日付/時刻データ型と合わせて公式documentを見ていただきたい。

8.5. 日付/時刻データ型



●配列型と範囲型

補足としてPostgreSQLは配列型と範囲型がある。
どちらも強力な機能だが乱用は毒にもなる。
公式documentと例を上げているエントリを紹介しておく。



4. ORMの罠

RoRを使う人は問題ないがPHPerはFrameworkのORMが対応してないことがある。
まさにFuelPHPの話だ。
私は標準のクエリビルダをラッパーし自作ORMを作成しているがこれは万人向けではない。
そのため、もしPostgreSQLに対応したORMが必要な場合はDoctrine2をオススメする。
ただし悲しいことに公式documentは英語しかない。
しかしDoctrine2はSymfony2のORMだ。
そのためSymfony2の公式documentを読むことで使い方を知ることが出来る。

Symfony2


FuelPHPでインストールする場合はComposerに対応しているので安心して欲しい。

FuelPHPでdoctrine2を使ってみた


またDoctrine2を利用すればスキーママイグレーションも出来る。
(FuelPHPの標準のスキーママイグレーションはMySQL専用なので動かない)



ここまで来た君は手元のアプリケーションからDBに接続し、自由にテーブル設計できたはずだ。
長くなったので今日はここまでとする。
この後、運用で困った事があればメーリングリストで聞いてみるといい。
きっと誰かが答えてくれるはずだ。

PostgreSQLユーザ会　メーリングリスト


それでは検討を祈る。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2015年8月24日月曜日

MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと



私が尊敬してるDBスペシャリストの@yoku0825さんがこんな事言ってた。



@yoku0825さんはMySQLのスペシャリスト中のスペシャリストだ。
その@yoku0825さんがこんな事を言うなんて只事じゃない！！
で話になった元ネタはコレ。

日々の覚書: #yapcasia でMySQL 5.7の罠についてLTしてきました


要はMySQL5.7は「目指している正しい姿」になるために下位互換性を幾つかを捨ててるよって話だ。
その中には360日問題があるけどそれ言うと正しさとは？みたいな話になるので今回は話題にしない。
(デフォルトでパスワードが360日後に無効になるという仕様がデフォルトになったという話)
MySQLを使ってる人は@yoku0825さんのブログを一読したほうがいい。
必ず知らなかった罠が幾つか見つかると思う。
そのツイート見て



とブーメラン投げて見事に刺さってるので今から記事書く。
両サイドにはかなり厳しい話もするが俺の本音を聴いておけ（関白宣言）
まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。
なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。
むしろ実際に使ってみた際の違いをにフォーカスする。

1. SQLの違い


基本的にMySQLでやっていたことはPostgreSQL出来る。
しかし関数の挙動の違いは幾つかある。
例えば時間から曜日に該当する数字に変換した場合に


  • MySQL　→　date_format(time,"%w")　0から始まり、日曜日に該当する
  • PostgreSQL　→　to_char(time,'D')　1から始まり、日曜日に該当する


など挙動に互換性がない場合も多い。
関数を使う場合は一度仕様を確認した方がいい。
幸い、PostgreSQLは有志によって日本語ドキュメントが充実している。
今はGithubで管理されてるので誤字脱字、表現の曖昧さなどはプルリクエストすることが出来る。

PostgreSQL日本語ドキュメント




MySQLを使ってた人はPostgreSQLを使うことでWindow関数など新たに知る機能が多いだろう。
MySQLしか触ったことが無く、OracleやMSDB等を触ったことが無いなら一度SQLの勉強をした方がいい。
必ず業務を効率化してくれるはずだ。
SQL勉強する人向けには最近読んだ本でPostgreSQLベースで書いてあって読みやすかった本をオススメしとく。



じゃあPostgreSQL優秀じゃん！大は小を兼ねるじゃん！！と言いたいところだがMySQLにしか無い文法もある。
MySQLにもPostgreSQLにもMerge文はSQL標準なのに実装されてない。
しかしMySQLには代替案として




がある。
これに準ずる機能はPostgreSQLには無い。
しかしWITH句とRETURNING句（MySQLには無い機能だね）を使えば一応PostgreSQLでも表現出来る。
第九回 中国地方DB勉強会 in 米子でこの話題は取り上げたので興味がある人は資料を見て欲しい。
このリンクの先に梶山さんのMySQL5.7の話が出てるのでそっち見て欲しい、いや見たほうが良い、絶対見るべきだ。
ただ事ある毎にPostgreSQLにMerge文相当が無いことをDis指摘していたら遂に9.5からそれ相当の構文が実装された。
これはMySQLの「INSERT...ON DUPLICATE KEY UPDATE構文」と似た構文で実装されている。

INSERT ... ON CONFLICT {UPDATE | IGNORE}構文


PostgreSQL9.5に興味が出た人はリリース予定の機能が以下にまとまってる。

What's new in PostgreSQL 9.5(英語)


英語なんて読めるか！って人は下記のブログをcheckするといいだろう。

日々の記録 別館


Twitterで行われるラーメン飯テロに耐えれるなら著者のぬこさんをフォローするのもいい。
あとはみかかな人たちが頑張ってるのでSlideShareをWatchすると幸せになれるかもしれない。
オススメのSlideShareのリンクを貼っておく。

10大ニュースで振り返るPGCon2015


おっと話が大分脱線してしまった。
話を戻すがPostgreSQLのSQLは


  • 文字結合が||で出来る
  • 日付操作がday +1で出来る


などどちらかと言えばOracleを意識した記述も多い。
ただ悪名高き(+)は無いしNULL = ""も無いのでそこは安心して欲しい
なのでわかりやすく例えるとしたら

ザ・キング・オブ・ファイターズの95の京と96の京くらい違う


といったところか。
新日本企画が産んだ名作格ゲー、ザ・キング・オブ・ファイターズを知らない若者は

細かいところは違うけど大体一緒でPostgreSQLの方が痒いところに手が届きやすい


くらいのニュアンスで居るといい。
つまりSQLに関してPostgreSQLに乗り換えて不満が出ることは少ないだろう。


2. 機能の違い


これもPostgreSQLの方が多い。
まずマテリアライズド・ビュー（以下マテビュー）がPostgreSQLにはある。
簡潔に言うとviewの結果を実体としてキャッシュするというものだ。
これでtmp_hogeみたいな中間テーブルを作る必要は無くなる。
ただし銀の弾丸ではない。
乱用するとCPUやHDDリソースなどが死ぬ。
そのほかにもCHECK制約があるがこのへんはMySQLで慣れた人には使うシーンが想像出来ないと思う。
データにバグやヒューマンエラーで不正なデータが入って苦しんだ人は覚えておくいい。
次の新規設計時にDBがデータを守ってくれる。
どちらかと言えば


  • JOINのアルゴリズムが複数ある
  • 相関サブクエリが早い


と言う点がMySQLと比較すると直接的にパフォーマンスが上がりメリット感じるところだろう。
ただしUPDATE文に関してはPostgreSQLの方が遅い（場合が多い）
これは追記型アーキテクチャの壁なのでMySQLの方が有利な点だ。
しかしガンガンUPDATEを走らすようなシステムはロックを必要とするはずでロック待ちの方が速度に影響およぼす。
そのため直接的に問題になることは少ないはずだ。

さてここまで話をしたのはPostgreSQLの良いところだ。
勿論MySQLの方が有利な機能もある。
それはレプリケーションだ。
そもそも論としてMySQLとPostgreSQLはアーキテクチャが違うのだがPostgreSQLには自動フェイルオーバーはない。
PostgreSQLの場合はPacemakerなどのサードパーティを利用して実現することになる。
corosyncに苦い思い出がある人は機会があれば一緒に飲もう。
また自動フェイルオーバーはMySQL5.6からの機能だ。
MySQL5.6をまだCHECKしてない人は奥野さんのブログを見るといいだろう。

開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！


とは行ってもPostgreSQLのレプリケーションに対する投資は素晴らしく今は追いつきつつあると行っても過言ではない。
以上の通り機能面でもSQLと同様の事が言える。
ここも安心してPostgreSQLを推せる内容だ。


3. GUIツールの違い


ここからはPostgreSQLのダメな所になる。
正直言ってPostgreSQLの管理や設定を一つのGUIで全て行うのは諦めた方がいい。
まずSQLエディタ（DBAツール）だがMySQL使いはWorkbenchを使ってると思う。
基本無料なので使ってない人は是非使った方がいい。
それに対してPostgreSQLはpgAdmin3になる。
残念ながら使いやすいとは言い難い。
例えばMacOS版は日本語入力がインラインではない。
この時点でリュウが使ったら殺意の波動に目覚めるレベルだ。
カプコンが産んだ名作、ストリートファイターを知らない若者はウメハラの背水の陣を見ておくといい。
そしてpgAdminは大切な場面で度々落ちる。
エクセル方眼紙を彷彿させると言えば共感してくれる方も多いだろう。
とにかく、PostgreSQLのGUI関連は弱い。
周囲に聞くとみんなコマンドラインの黒い画面でpsqlを直接操作しているらしい。
なので不満がコミュニティからあまり出ていないようだ。
しかし私は補完が利かない環境での開発は耐えれない若者なので代替案として以下のツールを使ってる。




どちらも無料で使え、ER図をリバース・エンジニアリングしたり出来る。
しかもPostgreSQLもMySQLにも繋げれるのでオススメだ。
0xDBEはIDEを開発してるJetBrains製でMacOSでもWindowsでも動くので是非試して欲しい。
A5:SQL Mk-2はmatsubaraさんが個人で開発されてる。
日本語だしExcelにテーブル定義書をリバース・エンジニアリング出来る。
これが無料なのが信じれないレベルのクオリティだ。
なおphpMyAdminに対抗したphpPgAdminも一応ある。
インストールしないことをオススメする。
とモダンなUIとは程遠いPostgreSQLだがPythonでpgAdmin4を作るという話が進んでる。
これがキラーアプリになってくれることを切に願っている。

4. ハードウェアでの違い


長くなってきたので簡潔に言う。
PostgreSQLはMySQLと違ってSSDにしたからといって何十倍の速度も出ない
（せいぜい数倍程度）
さらにFusion-ioは特にMySQLに特化してるのでその差は顕著だ。
PostgreSQLはHDDに特化してシーケンスに書き込もうとするのでそのオーバーヘッドの差が大きい。
もし、金の弾丸でPostgreSQLを殴るときはまずはメモリを増やそう。
PostgreSQLに限らずRDBの多くの問題は金で殴ってメモリを増やすと解決することが多い。
それでもダメな場合は優秀なDBエンジニアを用意しよう。
PostgreSQLはハードウェアを金で殴りにくいのは事実だ。

5. クラウド上での違い


やっとAWS RDSにPostgreSQLが去年追加された。
しかしまだ日本語の全文検索拡張はインストール出来ないしAuroraのPostgreSQL版も無い。
だがHerokuを初め、標準的な使い方であればPostgreSQLをsupportしてるところも出てきた。
国内だとニフティがRDSとしてPostgreSQLをサービスしている。
このへんはOSC 沖縄の時に話をしたので興味がある人はそちらを参考にして欲しい。

OSC沖縄でクラウドの選び方の話で登壇してきたので資料を公開する





随分と話が長くなってしまった。
本当はPostgreSQLには


  • PL/SQLの代わりにPL/PythonやPL/JavaScriptが使える
  • 外部テーブルラッパー(FDW)を使えばPostgreSQLのtableのようにMySQLを参照できる
  • MySQLと違いトリガーを行単位とクエリ単位が選べる（MySQLは行単位のみ）


などの話もしたかったがこのへんの話はまた別の機会にしようと思う。
なお、全然実践的じゃなかったし本当にMySQL派の人がPostgreSQLを使うときのハマリどころは皆無だった。
そこでお詫びにとみたさんの記事を紹介する。



最後になるがMySQLとPostgreSQLはライバル同士だ
しかしながらコミュニティ間はフレンドリーそのものだ。
他にライバル同士がこんなにフレンドリーなOSSコミュニティはあるのだろうか。
実際に合同勉強が開かれたりもする。

MyNA・JPUG合同DB勉強会 in 東京を開催してきた(FDWの話もしてきた)


私はそういうところがRDBのOSS界隈の好きなところである。
これを読んで興味を持った人は是非、DBのコミュニティに参加して欲しい。
MyNAもJPUGも暖かく迎えてくれるだろう。
それはどちらのコミュニティも変わらないことだ。


#### 2015/08/25追記 ####

好評だったので第二弾も作った

MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた

投稿者 時刻: 0 件のコメント:
ラベル: ,

2015年7月20日月曜日

第10回 中国地方DB勉強会 in 岡山をJAWS-UGと共催してDDDの話をしてきた #ChugokuDB #jawsug



今回のDB勉強会は僕の大好きなスーパーエンジニア カズさんのありがたいお言葉から始まりました。
ちなみに僕のGithubは真っ白でした。

ということで第10回 中国地方DB勉強会 in 岡山を開催してきました。
岡山は勉強会というコミュニティが成熟してきたなぁという実感が凄くありました。
例えば会場の準備、当日の担当の分担、めっちゃ低いドタキャン率。
どれも主催の私からすると本当に何もしなくてもイベントが進むレベルで聴衆者のような気分でした。
これは私達よりももっと先輩のひらさんやきよくらさんたちが積み上げて来た歴史が為せる技です。
この良き文化を引き継ぎ、もっと多くの地方に拡散していくのが私達の世代のミッションだなと思ったりしたのでした。

とちょっと話がそれましたが今回はJAWS-UGとの共催でした。
なのでAWSのセッションが半分、DB枠としてDDDの話が半分といった感じで総勢26名の参加がありました。
実務を通じた経験の話やAWSの最先端の話は非常に面白く、岡山特有のQ&Aの盛り上がりは流石の一言です。
そして毎度ながらご協力してくださった講師・スタッフの皆様、ありがとうございました。
そんな第10回の詳細は次のとおりです。

■登壇資料など
中国地方DB勉強会のポータルサイトにまとめました。

中国地方DB勉強会


※今回は動画の配信はありません

■メーリングリスト
次回の告知についてはMLやDoorKeeperを使います。
興味がある方はチェックしてみてください。

・中国地方DB勉強会ML Google Group

・DoorKeeper


■twitterのまとめ
Twitterについては@razonさんがまとめてくれています。

・Twitterのまとめ


それと第11回はOSC広島の翌日に同会場で開催します。
シルバーウィークの5連休の初日がOSC、翌日が中国地方DB勉強会となっています。
勉強会駆動旅行に是非ご活用ください。
ただ、もう宿が埋まりつつあるようです。
参加希望の方はお早めにお申込みと宿泊場所の確保をよろしくお願い致します。

■第11回 中国地方DB勉強会 in 広島
■概要
日時： 2015-09-20（日）10:00 - 17:00
会場：広島県広島市中区大手町１－５－３ サテライトキャンパスひろしま　504号室


詳細はこちら
第11回 中国地方DB勉強会 in 広島

※セッション対象予定
柿木さん(地元枠)：実務を通したDBの話
MySQL枠：調整中
きよくらさん(OITEC)：SQL Serverの話
渡辺さん(地元枠)：開発を通したDBの話
津田さん(地元枠)：DBの面白い話
吉田さん(JPUG)：DBの面白い話
曽根さん：コミュニティを通したDBの話

DBを通した幸せになった話（苦労した話）をテーマ（それ以外もありますが）やろうと思います。
前日のOSC広島にもJPUGは参加します。
こちらも面白いセミナーが目白押しなので是非参加してみてください。

オープンソースカンファレンス2015＠広島

なお、懇親会は18:00～20:00で考えています。
交流含めて是非参加をご検討していただけたらと思います。

さていよいよ3年目に突入し、DB勉強会はJPUGやDBの枠に収まらず色んなコミュニティやソフトウェアのサラダボウルのような場所になっていければと思ってます。
初心者から上級者まで色んな人の交流の場としてもご活用ください。
なのでこれからも中国地方で楽しい勉強会として頑張って行きたいと思います。
それでは皆様のご参加、お待ちしております！！
投稿者 時刻: 1 件のコメント:
ラベル: , ,

2015年7月17日金曜日

MyNA・JPUG合同DB勉強会 in 東京を開催してきた(FDWの話もしてきた)

MyNA・JPUG合同DB勉強会 in 東京を開催してきました。
遂に東京進出！！中国地方に収まらないスケールのデカさを魅せつけてきました。
ただ初の関東開催ということで関東の洗礼を受けましたｗ



それでも平日の日中に雨が降っていたにも関わらず40名以上の参加者がありました。
本当に皆様、ご参加して下さりありがとうございました。
この勉強会は会場を貸していただいたDMM.com ラボ様とMyNAの梶山さんのお陰で開催することが出来ました。
本当に良い経験が出来ました、ありがとうございます。
また所属しているまほろば工房には協賛費を出してもらいました。
お陰でドタキャンに怯える事無く、上手く乗り切る事が出来ました。
関東でイベントを開くときは


  • ドタキャンがあること前提で対応できる仕組みをつくる
  • お金の事に怯えなくて住むような事前準備


が非常に大切だなと思いました。
普段の地方開催だと懇親会はほとんどドタキャン無いで本当にその優しさを身をもって感じましたね。

■twitterのまとめ
Twitterについては@eielhさんがまとめてくれています。

MyNA・JPUG合同DB勉強会 in 東京 #ChugokuDB


■登壇資料など
他の講師の方の登壇資料も中国地方DB勉強会のポータルサイトにまとめました。

MyNA・JPUG合同DB勉強会 in 東京


今回は配信を行っていないので動画はありません。
当日のスーパーエンジニア講師のお話とスーパーエンジニア参加者のマサカリは来た人だけが味わえた特権ですね。
当たり前のようにPostgreSQLのコミッターやFDWのコントリビュータがいたり、MySQLエースやinnoDB作ってた人が居て全体的なレベルの高さがカオスでした

それと今回は講師業もしたのでスライド載せときます。
PostgreSQLの外部データラッパー（FDW）はNOSQLや他DBとのインターフェイスの一つの答えだと思ってます。
MySQLのストレージエンジンに似ていてやはり得意な事は得意なソフトウェアに任せるのが良いと思ってます。
その上でFDWが橋渡しをする、そんな想いを伝えたかったです。
ですがデモが糞みたいなデモで参加者には申し訳なかったです...
次回、汚名を返上する機会があればリベンジしたいですね。
ということで当日の資料はこちらです。



なので全体的に参加者のレベルも高く、正規化やRDBの基本的な話は理解されてる前提で講師も話をしてました。
本来は初心者から中級者向けをターゲットだったのでそういった参加者の方には難しい話だったと思います。
そこは僕のバランス取りとマーケティングが失敗しました。
何度やってもこういうバランス取りの答えが見えないので本当に難しいですね。

逆に懇親会はすごい人ばかりでただただ僕は色んな人の知見を勉強させて貰えました。
と言いながら勉強するフリをしながらひたすら余りそうなビールを消費するという貴重な経験をしました。
（結局1ケースほどビールが余ったのですが）


ということで色々と手探りでしたが結果的に大変有意義なイベントだったのではないかと思います。
コミュニティ主体のイベントは単体のコミュニティでやるものが多く、合同のイベントはもっとあって良いと思います。
このようなイベントは多くの化学反応を産むと思いますし、なによりも楽しいです。
これをキッカケにもっとDBに限らず色んなコラボが生まれて欲しいなぁと願っています。
また中国地方DB勉強会はそういったコラボを産む場所になれるように今年は頑張っていこうと思っています。
一緒に共催したい！！というコミュニティがありましたら是非ご連絡をよろしくお願いします。


ということで、soudai1025とイベントを開催したい！！という方、お待ちしております。
ホントまたこのイベントやりたいなぁ(*´ω｀*)
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2015年6月8日月曜日

第九回 中国地方DB勉強会 in 米子を開いてきた

第九回 中国地方DB勉強会 in 米子を開催してきました。
今回は初の米子開催！！ということで色々と手探りでしたが結果的に30名近い参加がありました。
これは米子現地スタッフの上村さんを始め、鳥取の方の勢いをすごく感じました！！
今回を企業として「株式会社　リゾーム」のパトラッシュさんと「日本Oracle」の梶山さんに来ていただきました。
実務を通じた経験の話やMySQLの最先端の話は非常に面白かったと好評でした。
他県の方も多く参加しており、大成功の勉強会だったと思います。
そして毎度ながらご協力してくださった講師・スタッフの皆様、ありがとうございました。
そんな第9回の詳細は次のとおりです。

■登壇資料など
中国地方DB勉強会のポータルサイトにまとめました。

第九回　中国地方DB勉強会


各講師の資料、そして今回はUstream配信をYouTubeに保存しております。
上記のポータルサイトからご参照ください。

■メーリングリスト
次回の告知についてはMLやDoorKeeperを使います。
興味がある方はチェックしてみてください。

・中国地方DB勉強会ML Google Group

・DoorKeeper


■twitterのまとめ
Twitterについては@eielhさんがまとめてくれています。

第9回 中国地方DB勉強会 in 米子 #ChugokuDB


■動画まとめ

中国地方DB勉強会　YouTube


それと第10回はJAWS-UGとの共催で岡山で開催します。
すでに申し込みが10名以上おり、埋まってしまいそうな勢いです。
参加希望の方はお早めにお申込みをよろしくお願い致します。

■第10回 中国地方DB勉強会 in 岡山 ～日本AWSユーザ会・PostgreSQLユーザ会(JAWS-UG・JPUG) 合同勉強会～
■概要
日時：2015年7月18日 (土) 10:00 - 18:30
会場：岡山県岡山市津島中１－１－１ 岡山大インキュベータ
http://www.smrj.go.jp/incubation/od-plus/

詳細はこちら
第10回 中国地方DB勉強会 in 岡山 ～日本AWSユーザ会・PostgreSQLユーザ会(JAWS-UG・JPUG) 合同勉強会～

※セッション対象予定
AmazonWebServices　講師3名
ドメイン駆動設計 　講師1名
その他、全員参加のハンズオンを予定しております。

クラウドの主流と言っても過言ではないAWSの話を3セッション予定しております。
また問題に対して如何に開発に落としこむか、というテーマでDDD(ドメイン駆動設計/Domain-driven design)の講師を呼びします。
セッションとハンズオンがありますのでこの機会にDDDに是非触れていただけたらと思います。

なお、懇親会は18:00～20:00で考えています。
交流含めて是非参加をご検討していただけたらと思います。

と今回でついに中国地方統一（全県開催）を果たしました。
次の岡山でDB勉強会も3年目になります。
これからも中国地方で楽しい勉強会として頑張って行きたいと思います。
それでは皆様のご参加、お待ちしております！！
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2014年12月9日火曜日

第六回　中国地方DB勉強会を開いてきた

第六回も無事終わりました。
第六回はクラウドをテーマに山口で開催されました。
特にAWSのAuroraの話とMySQL5.7の詳しい話を聞けたのは山口が中国地方最速だと思います。
どちらも非常に興味深く、今後のRDBも目が離せないと感じましたね。
本当に色々とご協力していただいた講師やスタッフの皆様、ありがとうございました。
そしてそんな第六回の詳細は次のとおりです。

■登壇資料など
中国地方DB勉強会のポータルサイトにまとめました。

第六回　中国地方DB勉強会


各講師の資料、そして今回はUstream配信をYouTubeに保存しております。
上記のポータルサイトからご参照ください。

■メーリングリスト
次回の告知についてはMLやDoorKeeperを使います。
興味がある方はチェックしてみてください。

・中国地方DB勉強会ML Google Group

・DoorKeeper


■twitterのまとめ
Twitterについては@eielhさんがまとめてくれています。

第6回 中国地方DB勉強会 in 山口


■動画まとめ

中国地方DB勉強会　YouTube


■第六回のアンケート募集中
当日に参加やUst拝見された方は下記のアンケートに答えてくださると嬉しいです。
次回のコンテンツや今後の運営に活用させて頂きます。

・アンケートはこちら
※匿名アンケートです


■第7回　中国地方DB勉強会
日時：2015年1月31日 (土曜日)
時間：13:00-17:00
会場：松江テルサ別館２Fオープンソースラボ

講師予定：

  • PostgreSQL　原田さん
  • MySQL　梶山さん
  • 調整中　玉川さん
  • 未定　山口さん


懇親会：根っこ(松江駅南口）

以上のように考えています。
原田さんにはPostgreSQL9.4の目玉機能のJSONBの話をしていただくと思います。
また梶山さんには山口に引き続き、MySQL5.7の話をしていただくと思います。
なお、懇親会は18:00～20:00で考えています。
交流含めて是非参加をご検討していただけたらと思います。

参考までに翌日から島根では蟹小屋がオープンするそうです。
これは一泊二日の勉強会駆動旅行を発動するしかないですね！！！

また申し込みサイトが出来ましたらMLやDoorKeeperで告知します。
ご興味がある方は上記のMLとDoorKeeperにご登録してみてください！！
12月20日くらいまでには申し込みサイトをお知らせ出来ると思います。

また今回も山口の地元スタッフのお陰で動画に残っています。
是非見てみてください。

とついに山陽を制覇したDB勉強会ですが年明け早々についに山陰進出です！！
特にRubyのお膝元松江市でDBエンジニアの皆様がどんな話をするか大変興味深いですね。
年明け最初のイベントとなりますが次回も皆様とお会いできるのを楽しみにしております。

投稿者 時刻: 1 件のコメント:
ラベル: , , , , ,

2014年9月9日火曜日

2014年版　WEB系の開発をするために必要な10の開発環境 ~Windows~

ずっと使ってたZenBookのマザーボードが亡くなられ、初期化されました。
なのでこれを機に開発環境を見直しました。
2年前のまとめはこちら

WEB系の開発をするために必要な10の開発環境 ~Windows~



この頃からはツールも変わったモノもありますしそのままのモノもあります。
ですが必要な項目は依然変わってないと思いますので項目は踏襲します。



１　IME

前回はGoogle日本語入力をオススメしました。
この二年で更に使いやすくなり、もうGoogle日本語入力無しでは生きていけませんｗ
便利な機能として

郵便番号を入れると住所に変わる
「きょう」→2014/09/06のように日付に変換できる（ことし、あさって等でも可）
「くりえいと」→Createのように英単語の読みで英語に変換してくれる

などです。
顔文字やZ+Hでの矢印なども便利ですね！
AndroidやMacOSなどでも同じ変換が出来るのでマルチプラットフォームでストレス無く使く入力出来るのは嬉しいですね！！
また、流行りの語句なども変換してくれるのが非常に助かります。


２　ブラウザ

ブラウザ事情もIE・Firefox・Google Chromeの3強状態は変わらず。
ただChromeの開発者ツールが一番使いやすいと思うので開発はChromeメインにしてます。
Chromeの開発者ツールの使い方はドットインストールがわかりやすいのでオススメです。

Chrome Developer Tools入門 (全10回)


FirefoxもIEも開発者ツールは付いてるのでブラウザ依存の不具合とぶつかった時などに使えると色んな時に役に立つので調べておいて損は無いですよ。

３　テキストエディタ

僕は今も昔もIDE派です。
でも時々ちょっとconf触ったり、メモ作ったり、直接HTML触ったりするときなどテキストエディタは必要です。
そこで僕が使ってるのはSakuraEditor。
矩形選択も置換も使いやすいのでログを見たり集計するときにも役立ちます。
また常駐アプリとしてついてくる機能のgrepが非常に便利です。
Windowsだとソース内のキーワードでgrepしたい時とか困るんですよね。
それがバッチシ対応してくれるし、対応箇所も一覧で出してくれるので非常に使いやすいです。
また補完は辞書のパッケージを追加すれば対応してくれます。
PHPをちょっと書く程度なら十分ですよ！
そしてそんなSakuraEditorの対抗馬なのがSublime Text 3ですね。
UTF-8の環境で使うなら補完、拡張性、どれをとってもSakuraEditor以上のパワーです。
実際に僕はWinSCP（後述）のデフォルトエディタはSublime Text 3をデフォルトにしてます。
一括置換も便利ですしテキストエディタ界の中心的存在です。
長い間、秀丸エディタが築いてきた牙城を崩す存在ですね。
Sublime Textについてはいい本が出てます。



電子書籍版もあるのでSublime Textを始める人は一度読んだ方がいいですよ！！

４　IDE

昔はEclipseを使ってましたが今はすっかりNetBeans使いです。

PHPerがNetBeansを使いたくなる７つの理由


特にFuelPHP使ってる人にはNetBeansが超絶オススメですね。
使い方は上のリンクでも紹介してますが補完もバリバリ聞くしHTMLやJSもバッチシ対応です。
ユニットテストも宣言元にジャンプもデバッカもバッチシです。
var_dump開発しなくて済むとすごい効率が上がりますよ！
ただ最近、Symfony2の時にNetBeansの非力さを感じる時があります。
Symfony2使うとすっごい最初のロードが長いんですよね(´・ω・｀)
そんな人には有料ですがPHPStormがオススメです！！
Web系の補完も抜群でNetBeansより軽快です。
Symfony2やCakePHPなどのフレームワークで開発する人やJSもバリバリ書くようなフロント寄りの人は買ったことによるメリットが間違いなく大きいです。
お試し無料期間もあるのでまずは触ってみるのがいいのではないでしょうか。
あと何かと面白いイベントしてることがあるので＠samuraismウォッチするのがオススメです。
それと




らしいのでセール待ちせずにサクッと買ったほうが良いと思います。
ツイッターのレスポンスとかメール対応がすごく優しく日本人にも安心対応なのも良いところですね。

５　ローカル実行環境

PHPer御用達はやっぱりXAMPPが主流だと思います。
ですが開発プロジェクトが増えるたびに度重なるバーチャルホスト。
そしてPHPやその他のライブラリのバージョンがプロジェクトごとに違って繰り出されるエラー。
そんな経験皆さんありませんか？
それを解決するにはVMです。
僕は以前からVirtualBoxを使っています。
VirtualBoxはお手軽にWindows上にVMを建てれるので簡単です。
ですがOSのインストールからやらねばならず、ネットワークの設定等のインフラ系の知識も必要とします。
たまになら良いのですが頻繁に、しかも「今すぐ開発を始めたい！」という時には高いハードルになってしまいます。
そこで活躍するのがvagrantです。
vagrantはVMのラッパーとパッケージ化を同時に提供してくれます。
ViretualBox, VMWare, AWSなどのVMに対応しており、高速にかつシンプルにVMを作成できます。
そしてVMへのアクセス、管理、設定も簡略化してくれます。
これにより、開発環境の依存関係に悩まされることなく、そして多くのインフラ系知識のブラッシュアップも必要なく開発に集中できます。
しかもNetBeansにプラグインを入れるとvagrantをNetBeansのGUIで操作できます。
SSHもCygwinのような黒魔術を使うこと無くNetBeansからアクセスできます。
すべてがNetBeansで解決できるので作業が捗ること間違いなしです！！

６　RDB

vagrantの出現によりlocalにDBを入れることがなくなりました。
これによりlocalにアパッチやDBを入れないので開発しない時に無駄なプロセスが起動しなくなりました。
こういうところにもVMを使うと良い点がありますね。

７　DB管理ツール＆SQLエディタ

SQLエディタは自分の中ではA5:SQL Mk-2が一強です。
前回ご紹介した時はまだSSHトンネルも無く、PostgreSQLにアクセスするにはドライバーが必要でした。
現状ではSSHトンネルが可能なのでセキュアに接続できますしvagrantへのアクセスも簡単です。
またドライバーが必要ないのでダウンロードして解凍したらすぐに使うことができます。
このお手軽さにプラスして各種機能が非常に強力です。
特にテーブル定義書の出力とER図のリバース自動生成はいつも助けられています。
DBにもマルチ対応なのでMySQLとPostgreSQLでツールを変える必要がないのも非常に助かります。
ただしDB管理ツールではないのでDDLの必要な作業はGUI上ではできません。
（SQLを発行すれば当然出来る）
そこで外部制約やテーブル設計時に強力なのがMySQLならMySQL Workbench、PostgreSQLならpgadmin3です。
DBAツールなので簡単にテーブルの作成や編集もできますし外部制約やDB固有の機能にもバッチリサポートしてます。
それぞれグラフィカルな実行計画の結果やレプリケーションの設定、confの変更なども可能です。
phpMyAdminやphpPgAdminを覚えるよりセキュアで断然便利なので是非活用してみてください。

８　ファイル転送ツール

今はもうWinSCP一強です。
SCPの管理の使いやすさもですが自動同期の機能や開くファイルのエディタの指定など細かく手が届いて便利です。
地味にシンボリックリンクを作れたりパーミッションを変更できたりするのでCGIが苦手な人でも大丈夫です。
更にノートン コマンダー インターフェイスを使うとキーボードでの操作に特化するそうです。
僕もこれから効率向上のために試してみようと思ってます。

９　バージョン管理ツール

こちらもSVNから完全にGitに移行しました。
NetBeansからGitは直接管理できるので基本的にはNetBeansのGUIで触ってます。
しかもNetBeansは自分自身の保存ログとGitのコミットログを使ってソースのDiff出せたりするので超絶便利です。
マジこれだけでもNetBeans使う価値あります。
でもなんでもかんでもNetBeansのプロジェクトに出来るわけではないと思います。
そんな時はSourceTreeがイケてます。
GUIで操作でき、Githubへの連携も最初から念頭に置かれています。
ちなみにプライベートな開発をするときは僕はbitbucketを使ってます。
プライベートリポジトリでも無料なのでちょっとした開発の時は便利ですよ。
また社内で「クラウドにデータを置くのはちょっと…」って時にサーバーを社内に建てることになったらgitbucketがgithubのクローンの中でもダントツオススメです。
Scalaで作られてますが日本人が作者なので情報も多く、環境構築、アップデートともにすごく簡単です。
実際に僕も社内で使ってますがGUIでリポジトリが管理できることはもちろん、プルリクエストとissuesによるチケット管理はすごく便利です。
またWikiやREAD.MEなども対応しており、プロジェクトの暗黙知を無くすプラットフォームが成熟している感じです。
個人的には開発者だけで回すならredmine無しでgitbucketでやりとりしたほうがうまく回る気がしてます。

１０　SSHクライアント

最近はTeraTerm proを使ってます。
Tera Term Menuを使うとTera Termのアクセスするサーバの管理もできます。
実際にはvagrantを使い出すとSSHを使うことも減ってきました。
昔はサーバに入ってvimでゴリゴリすることもあったのですがそういう時はWinSCPでは入ります。
なのでほとんどのことは別のツールでことが足りるのですがやはりコマンドラインが必要なこともあります。
昔はPuTTYを使ってたのですがPuTTYもかなり良いので好みの問題かなと思います。


と言うことでVMが出てきたことで環境依存の悩みも無くまりました。
またここでは説明しませんでしたがPHPUnitやBehatなどでテストが充実し、デバッカを使う機会も減りました。
この様に環境がどんどん進化してますのでぜひ一度調べてみると良いと思います。
また今回の内容でPHPerの最新環境に興味が出た人は次の本が参考になります。


また2014/9/20に広島市でオープンソースカンファレンス広島が開催されます。
ここにFuelPHPユーザ会として参加します。
ブースも出しますし登壇もしますので興味がある方は是非遊びに来てください！！

FuelPHPで始めるモダンPHP開発！！


ということでWeb系の方はこれを機に環境を見なおしてみると良いかもしれません。
投稿者 時刻: 0 件のコメント:
ラベル: , , , , ,

2014年6月4日水曜日

twigとPHPとSQLでの年齢計算

年齢計算は良く出てくることなんだけどTwigでやる時のメモ。


Twig

TwigにはPHPの関数が使えないので計算で出します。
birthdayには日付型のデータが入っているとして

{% set age = "now"|date('Y') - birthday|date('Y') %}
{% if ("now"|date('m/d') < birthday|date('m/d')) %}
    {% set age = age -1 %}
{% endif%}

で出ます。

(今年 - 誕生日年）


をして年を外した日付で比較して誕生日が来てなかったら1引くというロジックですね。

PHP

PHPはtime()で引き算したりいろいろあるのですが個人的に一番好きな方法をご紹介します。
ついでにDateTimeクラスのdiff()は5.3以降のPHPじゃないと動きません。

$birthday = new \DateTime("'2014-06-04'");
$now = new \DateTime();
$interval = $now->diff($birthday);
$age = $interval->y;

MySQL

MySQLはTwigと同様に計算で出します。 

SELECT
  (YEAR(CURDATE()) - YEAR(birthday)) - (RIGHT(CURDATE(), 5) < RIGHT(birthday, 5)) AS age
FROM
 member

PostgreSQL

PostgreSQLにはage関数があります。

日付/時刻関数と演算子

なので単純に

SELECT
 age(now(),birthday)
FROM
 hoge

で差分の日付型が帰ってくるので頭の年を取得して。 

SELECT
 extract(year from age(now(),birthday)) AS age
FROM
 hoge

こんな感じです。
むしろPostgreSQLはFrom句が無くても動くので

SELECT extract(year from age(now(),date '2013-06-04'))  AS age

SELECT extract(year from age(now(),now() + '-10 year'))  AS age

とか動きます。
と言うことでよく使う年齢の計算方法でした。
投稿者 時刻: 0 件のコメント:
ラベル: , , , ,
登録: 投稿 (Atom)