JHashimotoのブックマーク - はてなブックマーク

参照テーブルとアプリケーションの値リスト - iakioの日記
10章サーティーワンフレーバー(31のフレーバー) より ENUMのかわりに参照テーブルを使うという話。基本的にはやってみたいと思うアイディアだった。すると、多くのプログラマーは、アプリケーションコードの側にも値のリストを定義し、手でメンテナンスするという選択をします。参照テーブルを使えば、アプリケーション側では値のリストを定義する必要がないという主張なのだが、このケースではそう簡単ではないと思う。 statusをドロップダウンリストから選択するだけであれば問題無いが、バグを管理するアプリケーションを考えたとき、 'IN PROGRESS'のものを'FIXED'にするボタンが欲しいとか、'NEW'のものだけ表示させたいみたいな要求がありそうだからだ。つまり値のリストに対して、個別の要件がありそうな場合はアプリケーションコード側にもリストの定義は必要になる。章の冒頭では'Mr.',
JHashimoto 2013/05/19
"バグを管理するアプリケーションを考えたとき、 'IN PROGRESS'のものを'FIXED'にするボタンが欲しいとか、'NEW'のものだけ表示させたいみたいな要求がありそうだからだ。"

DB

アーキテクチャ
リンク
SQLの制約エラーの詳細を取得する方法 - iakioの日記
1つ前のエントリで、SQLの制約はエラーの詳細拾えなくて使えないわーといったのが聞こえたわけではないのだろうが、Bruce Momijan(PostgreSQLのCore Developer)がこんなエントリを書いていた。 Matching Server and Client Constraints チェック制約を使うと無効なデータの入力を避けることができるが、ユーザーに対するフィードバックにはあまり役に立たない。1つの改善案は、制約に名前をつけること CREATE TABLE ledger (id SERIAL, balance NUMERIC(10,2) CONSTRAINT "Zero and negative balances not allowed" CHECK (balance > 0)); INSERT INTO ledger VALUES (DEFAULT, -2.00);
JHashimoto 2013/05/19
"チェック制約を使うと無効なデータの入力を避けることができるが、ユーザーに対するフィードバックにはあまり役に立たない。1つの改善案は、制約に名前をつけること"

DB

検証
リンク
SQLでfloat型を使うということ - iakioの日記
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
JHashimoto 2013/03/12
"Accounts.hourly_rateがfloat型のとき、MySQLとは異なりPostgreSQLでは、このクエリは59.95が格納された行を返却する。これはMySQLでのfloat型が単精度であるのに対して、PostgreSQLのfloat型は倍精度だからだ。"

PostgreSQL

トラブルシュート
リンク
1