Postgresについて知っておきたかったこと
- Postgresドキュメントの膨大さ: Postgresの公式ドキュメントは非常に優れているが、量が膨大で、初級エンジニアが最初から最後まで読むのは難しい。
データ正規化
- データ正規化: データベーススキーマから重複データを取り除くプロセス。たとえば、
documentsテーブルにuser_email列を置くのではなく、usersテーブルと外部キーで関連付けるのがよい。
- 非正規化の必要性: 特定のデータをより速く読み取るために、非正規化が必要になる場合もある。しかし、非正規化されたデータには、データ不整合や書き込みの複雑さが増すというコストが伴う。
Postgresの作者たちの助言に従う
- Postgres Wikiの「してはいけないこと」: 公式のPostgres Wikiには「してはいけないこと」の一覧がある。理解できなくても、ミスを避ける助けになる。
- 推奨事項: すべてのテキスト保存には
text型を使い、すべてのタイムスタンプ保存にはtimestampz/time with time zone型を使い、テーブル名はsnake_caseで書く。
一般的なSQLの癖
- SQLは大文字小文字を区別しない: SQLキーワードは大文字小文字を区別しない。これはPostgresに限った話ではない。
- NULLの特殊性: SQLの
NULLは「不明」を意味し、ほとんどの演算子と組み合わせると結果はNULLになる。IS NULL、IS NOT NULLなどの演算子を使ってNULLを比較できる。
psqlをもっと便利にする
- 出力の読みやすさ向上: ターミナルのページャーを使って、長い出力を見やすくする設定ができる。
lessをページャーとして設定できる。
- 曖昧なNULLの明確化:
psqlでNULLを表す文字列を設定し、出力中のNULLを明確にできる。
- 補完機能の活用:
psqlは自動補完をサポートしており、SQLキーワードやテーブル名を簡単に入力できる。
インデックス追加の効果
- インデックスの定義: インデックスは、データをすばやく検索できるようにするデータ構造。
- インデックスの限界: ローカルデータベースに行がほとんどない場合、インデックスは役に立たないことがある。複数列にインデックスを張るときは順序が重要。
JSONBの活用
- JSONBの長所と短所: PostgresはJSONを効率的に保存・クエリする機能を提供するが、誤って使うと性能が低下することがある。
- JSONBの構造上の限界: JSONB列は構造の保証がなく、標準的なテーブルスキーマほど自己文書化されていない。
その他の役立つヒント
- 長いトランザクションの問題点: トランザクションが長く続きすぎると、他のクライアントによるデータベースアクセスを妨げることがある。
- Postgresの強力な機能: Postgresはドキュメント指向データベースの強みを提供し、JSONBを通じて効率的にデータを保存・クエリできる。
2件のコメント
やってはいけないこと、いつか一度読んでみたいです
Hacker Newsの意見
Postgresは大文字と小文字を区別するが、クエリでキーワードを大文字で書くのは可読性を高めるためのもの。必須ではないが、デバッグ時にクエリを見やすく整形するのは有用
actuallyUsingCaseInIdentifiersのような識別子で大文字を使うのは避けたい"Don't Do This" のWiki項目を初めて見つけたが、とても有用
内容の多くはPostgresに限った話ではない（例: nullの特異性、インデックス列の順序など）
(email, username)のような一意制約があると、同じemailをnullのusername付きで複数回挿入できるデータを正規化せよという助言には慎重に向き合うべき
開発者たちが正規化をもっと気にして、JSON(b)カラムに何でも詰め込むのをやめてほしい
「旅」という言葉は使われすぎていて、ブログでは不快に感じる
コードセクションがモバイルではほとんどスクロールできないほど使いづらい
JSON仕様における
nullは定数値であり、SQLのNULLとは異なるインデックスを追加しても何の効果もないことがある
このような記事を読んで90%理解できると、自分が担当してきた職務に誇りを感じられる