#mozaicfm #7 REST を聞いた - iakioの日記
#7 REST - mozaic.fm RESTの引力に惹かれたREST人達を、RESTの伝道師たる@yoheiが粛清する話。だったと思う。 APIバージョニングの話を聞きながら、/api/v1/fooじゃなくいっそ/api/v1.2.*/fooとか/api/>=v1.3.4,<v1.4/fooとかだったらどうなるだろう。とか想像した。APIのセマンティックバージョニング。まあマイナーバージョンは必要無いかな。 とはいえ、もともとはURLの設計としてどうかというよりサーバー側をどう実装するかの話だったので、そういう意味ではほぼ無理ゲーな気がする。たとえバージョンごとに別々のサーバーがあったとしても、最終的には永続化レイヤーが問題になるんだろうなあ。 Goのバージョンの話が出てたけど、最近TypeScriptを勉強していて、あの.d.tsもなかなか大変なことになってるなと思った。 伊勢神宮の
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);
外部キー制約は重荷になるか - iakioの日記
SQLアンチパターン 4章 キーレスエントリ(外部キー嫌い)より 外部キー制約によって、多少のオーバーヘッドが生じるのは事実です。しかし、以下にあげるように、他の選択肢と比べると、外部キーの方がより効率的であることがわかります。 本書では、外部キー制約を使うことによってデータを更新する時の事前チェックを省略できるので効率が良いという主張。 とはいえ、データベースは「外部キー制約に違反した」というエラーは返してくれるが、複数の制約がある場合にそこからどの外部キー制約に違反したかを取得する一般的な方法は無いので、ユーザーに詳細なエラーの内容を提供する必要がある場合は、やはり事前チェックが必要になる。 あるいは筋が悪いけど、頑張ればどの制約に違反したかをエラーメッセージから拾えるかもしれない。いちいち自分で書く気にはならないが、そういうライブラリがあったら面白そうだ。 MySQLの例 ERROR
特定の2つのタグが付けられたバグ検索 - iakioの日記
7章 マルチカラムアトリビュート(複数列属性) より 特定の2つのタグが付けられたバグ検索といった少し複雑な処理も、簡単に記述できます。 BugsテーブルとTagsテーブルが1対多の関係のとき、"printing"と"performance"という2つのタグが付いたバグの検索をどう行うか。いかにもありがちな話だが案外難しい。 2つのどちらかなら簡単だ。 SELECT DISTINCT b.* FROM Bugs AS b JOIN Tags AS t USING (bug_id) WHERE t.tag = 'printing' OR t.tag = 'performance'; では2つ両方がついているものはどうするか。自分ならまずこんなのを考えるかもしれない。 -- A SELECT * FROM Bugs AS b WHERE EXISTS (SELECT * FROM Tags A
交差テーブルを参照するテーブルの外部キー - iakioの日記
3章 IDリクワイヤド - 3.5.3 自然キーと複合キーの活用 より 現実問題として、複合主キーがどのようにフレームワークでサポートされているか等については良く知りません。 1つ注意すべき点は、複合主キーを参照する外部キーもまた、列の組み合わせでなければならないことです。このため、従属テーブル側では同じ列定義が重複することになり、簡潔さを欠いてしまいます。 これは何を言っているのかというと、もし交差テーブルBugsProductsと1対多の関係となるテーブルがあった場合その外部キーをどうするかという話。 BugsProductsの主キーに疑似キーidを使っていれば、従属テーブル側の外部キーはBugsProducts(id)を参照すればよい。 CREATE TABLE BugsProducts ( id SERIAL PRIMARY KEY, bug_id BIGINT, product_
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
SQLアンチパターンメモ - iakioの日記
SQLアンチパターンを読んだのですこしずつ思ったことをメモしていこうと思います。 この本は読んで納得するというよりは、考えるきっかけを与えてくれる本だと思います。長い歴史の中で今になってこういった本が出てきたというのがSQLの不思議な運命を象徴しているようにも思います。 10エントリくらいは書きたいと思ってます。主にMySQLとPostgreSQLについて書きます。 あと、ちょっと動作を確認してみたいと思ったらSQL Fiddleというサービスが便利ですよ。 記事一覧 交差テーブルを参照するテーブルの外部キー - 3章 IDリクワイヤドより カスケード更新のパターン - 4章 キーレスエントリ(外部キー嫌い)より 外部キー制約は重荷になるか - 4章 キーレスエントリ(外部キー嫌い)より SQLの制約エラーの詳細を取得する方法 - 4章 キーレスエントリ(外部キー嫌い)より 特定の2つのタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
