SlideShare a Scribd company logo
Web エンジニアが
PostgreSQL を選ぶ 3 つの理由
PostgreSQLカンファレンス 2014
What is it?
データベースは何を基準に選んでますか?
What is it?
アプリケーションにとって
データの寿命はコードより長い
という事実
What is it?
なぜPostgreSQLを使うのか
あじぇんだ
1 自己紹介
2 ランキングを作る
3 可変なプロパティを扱う
4 型を極める
5 まとめ
あじぇんだ
1 自己紹介
2 ランキングを作る
3 可変なプロパティを扱う
4 型を極める
5 まとめ
自己紹介
名前:曽根 壮大(そね たけとも)
年齢:30歳(三人の子供がいます)
職業:Webエンジニア
所属:日本PostgreSQLユーザ会
   中国支部 支部長
  技術的にはLL系言語とかRDBが好きです
中国地方DB勉強会
https://dbstudychugoku.github.io/
Web エンジニアが postgre sql を選ぶ 3 つの理由
あじぇんだ
1 自己紹介
2 ランキングを作る
3 可変なプロパティを扱う
4 型を極める
5 まとめ
ランキングを作る
仕様変更に強いランキングを作る
ランキングを作る
Viewに紐づくデータは
仕様変更
の影響を受けやすい
ランキングを作る
ランキング
ランキングを作る
ランキング
↓
要件が多様なので影響を受けやすい
名前 戦闘力
フリーザ 530000
悟飯(幼少期) 1307
クリリン(ラディッツ戦) 206
ヤムチャ(ラディッツ戦) 177
ランキングを作る
要件
ランキングを作る
要件
1 戦闘力の降順(DESC)
ランキングを作る
要件
1 戦闘力の降順(DESC)
2 表示は名前と戦闘力
実際のSQL
SELECT
名前,戦闘力
FROM キャラクター
ORDER BY
戦闘力
DESC
ランキングを作る
要件
1 戦闘力の降順(DESC)
2 表示は名前と戦闘力
3 上位三名を表示
実際のSQL
SELECT
名前,戦闘力
FROM キャラクター
ORDER BY
戦闘力
DESC
LIMIT 3
ランキングを作る
要件
1 戦闘力の降順(DESC)
2 表示は名前と戦闘力
3 上位三名を表示
4 編で分ける
名前 戦闘力 編
フリーザ 530000 フリーザ編
悟飯(幼少期) 1307 ラディッツ編
クリリン 206 ラディッツ編
ヤムチャ 177 ラディッツ編
農夫 5 ラディッツ編
ギニュー 120000 フリーザ編
クリリン 1500 フリーザ編
亀仙人 139 ラディッツ編
※実務では編は正規化するべき
実際のSQL
SELECT
名前,戦闘力
FROM キャラクター
WHERE 編 = ‘フリーザ編’ または 編 = ‘ラディッツ編’
ORDER BY
戦闘力
DESC
LIMIT 3
ランキングを作る
クライアント「それじゃない。」
名前 戦闘力 編
悟飯(幼少期) 1307 ラディッツ編
クリリン 206 ラディッツ編
ヤムチャ 177 ラディッツ編
亀仙人 139 ラディッツ編
農夫 5 ラディッツ編
フリーザ 530000 フリーザ編
ギニュー 120000 フリーザ編
クリリン 1500 フリーザ編
ランキングを作る
SQLを二回投げるか?
ランキングを作る
ウィンドウ関数
ランキングを作る
ウィンドウ関数
ウィンドウ関数は現在の行に何らの
関係するテーブル行の一纏まり全般
の計算を行う。
実際のSQL
SELECT
rank() OVER (
PARTITION BY "編"
ORDER BY "戦闘力" DESC
)
, *
FROM "キャラクター";
名前 戦闘力 編
悟飯(幼少期) 1307 ラディッツ編
クリリン 206 ラディッツ編
ヤムチャ 177 ラディッツ編
亀仙人 139 ラディッツ編
農夫 5 ラディッツ編
フリーザ 530000 フリーザ編
ギニュー 120000 フリーザ編
クリリン 1500 フリーザ編
ランキングを作る
クライアント
「かつキャラの最大戦闘力で並べて」
名前 戦闘力 編
フリーザ 530000 フリーザ編
フリーザ 10000000 フリーザ編
フリーザ 20000000 フリーザ編
悟飯(幼少期) 1307 ラディッツ編
クリリン 206 ラディッツ編
ヤムチャ 177 ラディッツ編
農夫 5 ラディッツ編
ギニュー 120000 フリーザ編
クリリン 1500 フリーザ編
クリリン 0 フリーザ編
クリリン 10000 フリーザ編
亀仙人 139 ラディッツ編
名前 戦闘力 編
フリーザ 2000000 フリーザ編
ギニュー 120000 フリーザ編
クリリン 10000 フリーザ編
悟飯(幼少期) 1307 ラディッツ編
クリリン 206 ラディッツ編
ヤムチャ 177 ラディッツ編
亀仙人 139 ラディッツ編
農夫 5 ラディッツ編
実際のSQL
SELECT
rank() OVER (
PARTITION BY "編"
ORDER BY max("戦闘力") DESC
) , "名前", MAX("戦闘力"), "編"
FROM "キャラクター"
GROUP BY "名前","編";
名前 戦闘力 編
フリーザ 2000000 フリーザ編
ギニュー 120000 フリーザ編
クリリン 1500 フリーザ編
悟飯(幼少期) 1307 ラディッツ編
クリリン 206 ラディッツ編
ヤムチャ 177 ラディッツ編
亀仙人 139 ラディッツ編
農夫 5 ラディッツ編
ランキングを作る
仕様変更に強いランキングを作る
ランキングを作る
開発者
「毎回SQLの差し替えするの辛い」
ランキングを作る
Viewを使う
ランキングを作る
街角の声
「Viewを使うと遅いのでは?」
ランキングを作る
View
ランキングを作る
View
• INDEXは効く
ランキングを作る
View
• INDEXは効く
• 参照の際にSQLを実行するだけ
ランキングを作る
View
• INDEXは効く
• 参照の際にSQLを実行するだけ
• 元のSQLが遅い場合は当然遅い
ランキングを作る
参照元のテーブルが大きくなった
ランキングを作る
参照元のテーブルが大きくなった
↓
参照元のSQLが遅い
ランキングを作る
マテリアライズドビュー
ランキングを作る
マテリアライズドビュー
実体の存在するView。
参照したクエリ結果を保存するため、
参照元を更新した際はマテビューの
更新も必要になる。
※ただしPostgreSQL 9.3からの機能
ランキングを作る
クエリ結果を実体化する
ランキングを作る
クエリ結果を実体化する
↓
高速化
ランキングを作る
マテビューは銀の弾丸ではない
ランキングを作る
マテビューの問題点
・リフレッシュ管理が必要(自動更新しない)
※ただし、9.4から自動更新が可能
・普通のテーブル同様に表領域を消費する
・リフレッシュはそれなりにリソースを使う
ランキングを作る
更新が多いとボトルネックになる
ランキングを作る
まとめ
ランキングを作る
まとめ
1 データをシンプルに保つ
ランキングを作る
まとめ
1 データをシンプルに保つ
2 コード側の実装に依存しない
ランキングを作る
まとめ
1 データをシンプルに保つ
2 コード側の実装に依存しない
3 要件に合わせて選択肢を選ぶ
あじぇんだ
1 自己紹介
2 ランキングを作る
3 可変なプロパティを扱う
4 型を極める
5 まとめ
可変なプロパティを扱う
可変なプロパティを扱う
• アンケートフォーム
可変なプロパティを扱う
• アンケートフォーム
• ユーザの付属情報
可変なプロパティを扱う
• アンケートフォーム
• ユーザの付属情報
• ブログのタブ
可変なプロパティを扱う
• アンケートフォーム
• ユーザの付属情報
• ブログのタブ
などなど…
可変なプロパティを扱う
アンケートフォーム
可変なプロパティを扱う
アンケートフォーム
回答者 キャラクター 回答日
そーだい 榛名 2014/11/28
たけとも 高雄 2014/11/28
soudai1025 大和 2014/11/29
可変なプロパティを扱う
アンケートフォーム
ここに「択一回答」があるじゃろ?
    ( ^ω^)←お客様
択一回答
可変なプロパティを扱う
アンケートフォーム
これを
    ( ^ω^)←お客様
)択一回答(
可変なプロパティを扱う
アンケートフォーム
こうして…
    ( ^ω^)←お客様
可変なプロパティを扱う
アンケートフォーム
こうじゃ!
    ( ^ω^)←お客様
複数回答
可変なプロパティを扱う
アンケートフォーム
可変なプロパティを扱う
アンケートフォーム
テキストフォームまで
こっそり追加される
可変なプロパティを扱う
どのように対応するか
可変なプロパティを扱う
データについて
可変なプロパティを扱う
データについて
• データを消せない
可変なプロパティを扱う
データについて
• データを消せない
• データを変更できない
可変なプロパティを扱う
データについて
• データを消せない
• データを変更できない
• データの追加で対応
可変なプロパティを扱う
SQLアンチパターン
↓
カンマ区切り(CSV)で保存
※ジェイ・ウォーク
回答者 キャラクター 回答日
そーだい 榛名 2014/11/28
たけとも 高雄,榛名 2014/11/28
soudai1025 大和,金剛,武蔵 2014/11/29
回答者 キャラクター 回答日
そーだい 榛名 2014/11/28
たけとも 高雄,榛名 2014/11/28
soudai1025 大和,金剛,武蔵 2014/11/29
保存するデータが
カラムのサイズに依存する
可変なプロパティを扱う
SQLアンチパターン
可変なプロパティを扱う
SQLアンチパターン
• 検索が難しい
可変なプロパティを扱う
SQLアンチパターン
• 検索が難しい
• 集計が難しい
可変なプロパティを扱う
SQLアンチパターン
• 検索が難しい
• 集計が難しい
• 更新が難しい
可変なプロパティを扱う
SQLアンチパターン
↓
データの数だけカラムを増やす
※メタデータトリブン
回答者 キャラ1 キャラ2 キャラ3 回答日
そーだい 榛名 NULL NULL 2014/11/28
たけとも 高雄 榛名 NULL 2014/11/28
soudai1025 大和 金剛 武蔵 2014/11/29
可変なプロパティを扱う
SQLアンチパターン
可変なプロパティを扱う
SQLアンチパターン
• 項目追加の度にカラムが増える
可変なプロパティを扱う
SQLアンチパターン
• 項目追加の度にカラムが増える
• データの可読性が下がる
可変なプロパティを扱う
SQLアンチパターン
• 項目追加の度にカラムが増える
• データの可読性が下がる
• データの整合性を担保が難しい
可変なプロパティを扱う
正規化
回答者 回答日
そーだい 2014/11/28
たけとも 2014/11/28
soudai1025 2014/11/29
回答者 キャラクター
そーだい 榛名
たけとも 高雄
たけとも 榛名
soudai1025 大和
soudai1025 金剛
soudai1025 武蔵
可変なプロパティを扱う
最初から正規化すれば両対応
可変なプロパティを扱う
集合でデータを表現する
可変なプロパティを扱う
変更に強くなる
可変なプロパティを扱う
PostgreSQLのアプローチ
可変なプロパティを扱う
PostgreSQLのアプローチ
↓
配列型
回答者 キャラクター 回答日
そーだい {榛名} 2014/11/28
たけとも {高雄,榛名} 2014/11/28
soudai1025 {大和,金剛,武蔵} 2014/11/29
可変なプロパティを扱う
配列型
可変なプロパティを扱う
配列型
• INDEXが効く
可変なプロパティを扱う
配列型
• INDEXが効く
• 柔軟な検索(内包なども可能)
可変なプロパティを扱う
配列型
• INDEXが効く
• 柔軟な検索(内包なども可能)
• 任意の箇所の更新も可能
可変なプロパティを扱う
配列型の注意点
• 外部制約が使えない
• ORMが多くの場合使えない
可変なプロパティを扱う
配列型のその他の使い方
• タグなどの複数の値を持たせる
• 木構造を表現する
可変なプロパティを扱う
配列型まとめ
可変なプロパティを扱う
配列型まとめ
• 外部制約の不要な場合に使う
可変なプロパティを扱う
配列型まとめ
• 外部制約の不要な場合に使う
• ORMに依存しない場合に使う
可変なプロパティを扱う
配列型まとめ
• 外部制約の不要な場合に使う
• ORMに依存しない場合に使う
• 最初に正規化を検討する
可変なプロパティを扱う
もっと柔軟に対応したい
可変なプロパティを扱う
もっと柔軟に対応したい
• ドキュメント志向
可変なプロパティを扱う
もっと柔軟に対応したい
• ドキュメント志向
• スキーマレス
可変なプロパティを扱う
もっと柔軟に対応したい
• ドキュメント志向
• スキーマレス
• Key=>Valueな関係性を保存
可変なプロパティを扱う
JSON型
可変なプロパティを扱う
JSON型
• JSON本体をカラムに保存
可変なプロパティを扱う
JSON型
• JSON本体をカラムに保存
• 高速な参照(INDEXが効く)
可変なプロパティを扱う
JSON型
• JSON本体をカラムに保存
• 高速な参照(INDEXが効く)
• 各種変換の関数を用意
回答者 JSON 回答日
そーだい {キャラクタ:[榛名]} 2014/11/28
たけとも {キャラクタ:[高雄,榛名]} 2014/11/28
soudai1025 {キャラクタ:[大和,榛名,武蔵]} 2014/11/29
回答者 JSON 回答日
そーだい {キャラクタ:[榛名],Lv:40} 2014/11/28
たけとも {キャラクタ:[高雄,榛名]} 2014/11/28
soudai1025 {キャラクタ:[大和,榛名,武蔵]} 2014/11/29
可変なプロパティを扱う
JSON型
可変なプロパティを扱う
JSON型
• 柔軟にデータを保存できる
可変なプロパティを扱う
JSON型
• 柔軟にデータを保存できる
• View変更によるDB変更が不要
可変なプロパティを扱う
JSON型
• 柔軟にデータを保存できる
• View変更によるDB変更が不要
• 9.4からはより強力なJSONB型
可変なプロパティを扱う
JSON型の注意点
• 外部制約の不要な場合に使う
• ORMに依存しない場合に使う
• 問題点は配列型と同様
あじぇんだ
1 自己紹介
2 ランキングを作る
3 可変なプロパティを扱う
4 型を極める
5 まとめ
型を極める
豊富な型の例
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
型を極める
型を選ぶ利点
型を極める
型を選ぶ利点
• 正しいデータのみが保存される
型を極める
型を選ぶ利点
• 正しいデータのみが保存される
• 正しいソートが行われる
型を極める
型を選ぶ利点
• 正しいデータのみが保存される
• 正しいソートが行われる
• 適切な検索が行える
型を極める
ネットワークアドレス型
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
• IPv4もIPv6も対応
• サブネットマスクの整合性
• 文字列ではなくIPとしてソート
IP
192.1.1.1/32
192.2.1.1/32
192.10.1.1/32
型を極める
幾何データ型
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
• point、boxなど豊富な型
• 充実した関数と演算子
• 地図の範囲検索など
店名 緯度 経度
品川AP 35.630793 139.73786
品川駅 35.630152 139.74044
五反田駅 35.626446 139.723444
実際のSQL
SELECT
sqrt(power((対象緯度-自分の緯度)*111,2)
 +
power((対象経度-自分の経度)* 91,2))
 AS distance
平均で緯度1度あたり111km
平均で経度1度あたり91km
検索例
半径●●メートルの中の登録店を調べる
自分を中心とした円に
含まれているか
実際のSQL
SELECT
店名,
sqrt(power((お店.緯度 - 自分の緯度) * 111, 2)
+ power((お店.経度 - 自分の経度) * 91, 2)) AS 距離(km)
FROM お店
WHERE
circle(point(お店.緯度*91.0,お店.経度*111.0), 円の半径)
@ circle(point(自分の緯度*91.0,自分の経度*111.0), 円の半径)
店名 距離(km)
品川AP 0.01
品川駅 0.4
型を極める
まとめ
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
•
型を極める
まとめ
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
• 適切な型にデータを入れる
型を極める
まとめ
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
• 適切な型にデータを入れる
• 型を使い不正なデータを無くす
型を極める
まとめ
• 列挙(enum)型
• ネットワーク・アドレス型
• 範囲型
• 幾何データ型
• 適切な型にデータを入れる
• 型を使い不正なデータを無くす
• 特別な検索も可能になる
あじぇんだ
1 自己紹介
2 ランキングを作る
3 可変なプロパティを扱う
4 型を極める
5 まとめ
まとめ
まとめ
Webは日々複雑になっている
まとめ
Webは日々複雑になっている
↓
取り扱うデータも増えている
まとめ
運用が始まるとデータは変えれない
まとめ
運用が始まるとデータは変えれない
↓
どんなにコードが綺麗でもデータ構造
がダメだとリファクタリングは難しい
まとめ
SQLや型を使ってデータを守る
まとめ
SQLや型を使ってデータを守る
↓
運用をシンプルにする
まとめ
データの寿命はコードより長い
ご静聴ありがとうございました。

More Related Content

PDF
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
PDF
基本に戻ってInnoDBの話をします
PDF
O/Rマッパーによるトラブルを未然に防ぐ
ODP
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
PDF
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
PDF
マイクロサービス 4つの分割アプローチ
PDF
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
基本に戻ってInnoDBの話をします
O/Rマッパーによるトラブルを未然に防ぐ
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
マイクロサービス 4つの分割アプローチ
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~

What's hot (20)

PDF
PostgreSQLアンチパターン
PDF
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
PDF
マイクロにしすぎた結果がこれだよ!
PPTX
地理分散DBについて
PPTX
トランザクションをSerializableにする4つの方法
PDF
ヤフー社内でやってるMySQLチューニングセミナー大公開
PDF
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
PDF
ドメインオブジェクトの設計ガイドライン
PPTX
20160526 依存関係逆転の原則
PDF
強いて言えば「集約どう実装するのかな、を考える」な話
PDF
Tackling Complexity
PDF
なかったらINSERTしたいし、あるならロック取りたいやん?
PDF
MySQLで論理削除と正しく付き合う方法
PDF
イミュータブルデータモデル(入門編)
PPTX
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
PDF
Where狙いのキー、order by狙いのキー
PDF
それはYAGNIか? それとも思考停止か?
PPTX
世界一わかりやすいClean Architecture
PPTX
概念モデリング再入門 + DDD
PostgreSQLアンチパターン
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
マイクロにしすぎた結果がこれだよ!
地理分散DBについて
トランザクションをSerializableにする4つの方法
ヤフー社内でやってるMySQLチューニングセミナー大公開
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
ドメインオブジェクトの設計ガイドライン
20160526 依存関係逆転の原則
強いて言えば「集約どう実装するのかな、を考える」な話
Tackling Complexity
なかったらINSERTしたいし、あるならロック取りたいやん?
MySQLで論理削除と正しく付き合う方法
イミュータブルデータモデル(入門編)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
Where狙いのキー、order by狙いのキー
それはYAGNIか? それとも思考停止か?
世界一わかりやすいClean Architecture
概念モデリング再入門 + DDD
Ad

Viewers also liked (11)

PDF
カヤックを退職すべきではない3つの理由
PDF
フレームワークを使うべき 3 つの理由
PDF
kintone cafe東京vol3 「kintoneの開発が楽しい3つの理由」
PPT
おジャ魔女どれみが素晴らしい3つの理由
PDF
自動構築と自動テスト〜インフラのコード化とクラウドの優位性
PDF
Vpcを使う3つの理由
PDF
スタートアップがAWSを使うべき3つの理由
PDF
安心してぐっすり眠るための AWS 運用術
PDF
私がCloudStackを使う4つの理由
PDF
最短で AWS を乗りこなすライフハック術
PDF
「スキルなし・実績なし」 32歳窓際エンジニアがシリコンバレーで働くようになるまで
カヤックを退職すべきではない3つの理由
フレームワークを使うべき 3 つの理由
kintone cafe東京vol3 「kintoneの開発が楽しい3つの理由」
おジャ魔女どれみが素晴らしい3つの理由
自動構築と自動テスト〜インフラのコード化とクラウドの優位性
Vpcを使う3つの理由
スタートアップがAWSを使うべき3つの理由
安心してぐっすり眠るための AWS 運用術
私がCloudStackを使う4つの理由
最短で AWS を乗りこなすライフハック術
「スキルなし・実績なし」 32歳窓際エンジニアがシリコンバレーで働くようになるまで
Ad

Similar to Web エンジニアが postgre sql を選ぶ 3 つの理由 (20)

PDF
Webで役立つRDBの使い方
PDF
お前の罪を数えろ
PDF
実務で役立つデータベースの活用法
PDF
MySQL 入門的なはなし
PDF
ふくよかなモデル
PDF
SQLQL は GraphQL にとってなんなのか
PDF
Integral - New O/R Mapper for Common Lisp
PDF
リレーショナルデータベースとの上手な付き合い方 long version
PDF
Random partionerのデータモデリング
 
PDF
Oracle Databaseを用いて学ぶ RDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
PDF
Nosql
PDF
よろしい、ならばMicro-ORMだ
PDF
StepInNosql
PDF
ARC-009_RDB 技術者のための NoSQL ガイド
PDF
20181110 fok2018-pg-extension
PDF
Lt 関数の変動性分類についておさらいしてみる。
PDF
PPTX
設計をする上で役にたった制約について
PDF
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏
PDF
オープンソース・データベースの最新事情
Webで役立つRDBの使い方
お前の罪を数えろ
実務で役立つデータベースの活用法
MySQL 入門的なはなし
ふくよかなモデル
SQLQL は GraphQL にとってなんなのか
Integral - New O/R Mapper for Common Lisp
リレーショナルデータベースとの上手な付き合い方 long version
Random partionerのデータモデリング
 
Oracle Databaseを用いて学ぶ RDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Nosql
よろしい、ならばMicro-ORMだ
StepInNosql
ARC-009_RDB 技術者のための NoSQL ガイド
20181110 fok2018-pg-extension
Lt 関数の変動性分類についておさらいしてみる。
設計をする上で役にたった制約について
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏
オープンソース・データベースの最新事情

More from Soudai Sone (20)

PDF
DBの闇を書くにはこの余白は狭すぎる
PDF
レガシーな環境からモダンへの挑戦
PDF
PostgreSQLとpython
PDF
地方エンジニアがPostgreSQLを通じて成長した話
PDF
知って得するWebで便利なpostgre sqlの3つの機能
PDF
DDDハンズオン
PDF
今すぐ使えるクラウドとPostgreSQL
PDF
Postgre sqlから見るnosql
PDF
中国地方Db勉強会
PDF
Ansibleで始めるpostgre sqlの冗長化
PDF
Web で変わったクラウドと postgre sql の今と昔
PDF
すぐ始めれるクラウド
PDF
Osc2014
PDF
PostgreSQLの冗長化について
PDF
Osh2014
PDF
Postgre sql9.3新機能 (OSC hiroshima 2013)
PDF
聞いたら参加したくなるJjug cccの報告
PDF
地方における勉強会事情
PPTX
今、最も勢いのあるWebフレームワーク「fuel php」
PDF
Git hub pagesで告知サイトを作ってみた
DBの闇を書くにはこの余白は狭すぎる
レガシーな環境からモダンへの挑戦
PostgreSQLとpython
地方エンジニアがPostgreSQLを通じて成長した話
知って得するWebで便利なpostgre sqlの3つの機能
DDDハンズオン
今すぐ使えるクラウドとPostgreSQL
Postgre sqlから見るnosql
中国地方Db勉強会
Ansibleで始めるpostgre sqlの冗長化
Web で変わったクラウドと postgre sql の今と昔
すぐ始めれるクラウド
Osc2014
PostgreSQLの冗長化について
Osh2014
Postgre sql9.3新機能 (OSC hiroshima 2013)
聞いたら参加したくなるJjug cccの報告
地方における勉強会事情
今、最も勢いのあるWebフレームワーク「fuel php」
Git hub pagesで告知サイトを作ってみた

Web エンジニアが postgre sql を選ぶ 3 つの理由