社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。Read less
社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。Read less
SQLアンチパターンはMySQLがベースになっているのでPostgreSQLではそのまま動かない。とりあえずサンプルデータベースの変更ポイント。 BLOBをBYTEAに変更 UNSIGNGEDがないので省略 DATETIMEをTIMESTAMPに変更 テーブルを削除したい場合はDROP文をIF EXISTSオプションを付けて冒頭に書いておけばOK。 DROP TABLE IF EXISTS Accounts, BugStatus, Bugs, Comments, Screenshots, Tags, Products, BugsProducts; 修正後のSQLって公開してもいいのかな? id:t-wada さんに公開OKといただきました。 (追記)リポジトリ公開しました 写経しながらとなりますが、こちらのリポジトリにおいておきます。 https://bitbucket.org/shuji
9章 ラウンディングエラー(丸め誤差)より floatを使う場合に精度に注意すべきという点については同意です。 SELECT * FROM Accounts WHERE hourly_rate = 59.95; このため、account_idが123の行hourly_rate列にサイド59.95を割り当てても、リテラル値59.95とは等価になりません。 Accounts.hourly_rateがfloat型のとき、MySQLとは異なりPostgreSQLでは、このクエリは59.95が格納された行を返却する。 これはMySQLでのfloat型が単精度であるのに対して、PostgreSQLのfloat型は倍精度だからだ。単精度浮動小数点型であるreal又はfloat4を使うとMySQLと同様マッチしなくなる。 この時点でもうfloatのことなんて考えたくなくなるところだ。 さてAccounts
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く