SQLアンチパターン読了記
お疲れ様です。
こういうときでもメールの癖は抜けないものですね。
チャットが利点なのはこういう"枕詞"みたいなのをつけなくていいから、
生産性も上がる、というところですよね。
チャットにはチャットの良さがあり、メールにはメールの良さがありますからしっかり使い分けしていきたいものです。
（メールが紙媒体の書類のような扱いになってきていますしね）
さて本題です。
私自身はApplication Engineerなので業務でさほど考える場面は少ないのですが、
ビジネスマンにとっての三種の神器である「英語とITと簿記」は、
僕と同じレイヤの技術者にとっては「RDB、Linux（shell scriptとkernel含む）、正規表現」なのではないか？と考えています。
（エンジニアがビジネスマンでないとはどういうことか！みたいなツッコミはおやめください。勿論PJのROIはとても重要だと思っています。）
もっともよわよわエンジニアなので、とりあえず「読むべき」とされる本を片っ端から読みまくっています。
今回はそのうちの一冊をサマライズします。
こちらです。
25個、事例が紹介されていました。
サマっても多分読まないので、「1アンチパターン：1行」で書きます！
（数行で言ってること変えましたごめんなさい）
SQLアンチパターン25
- カンマ区切りの属性を格納しない（従属テーブルを使用する）
- 親IDが連なる場合は、隣接リストの使用は極力避ける
- PrimaryKeyを意味もなく連番にしない
- ForeignKey制約を適切に使用する（面倒だから使わない、はありえない）
- 可変属性の解決策はとても慎重になる*
- ポリモーフィックな動作をさせる際にはとても慎重になる*
- 多くの列に属性を格納しない（従属テーブルを使用する）
- テーブルサイズの増大には、パーティショニングと正規化で対抗する
- 小数データを格納する列にはFLOAT型ではなく、NUMERIC型を使用する
- 値を限定する際は列定義でなく、参照テーブル方式を用いる
- 大きなサイズのファイルの管理にはBLOB型を用いる（直置きしない）
- インデックスは適切に使用する（パフォーマンスに甚大な影響あり）
- NULLはNULLとして理解し、扱う（SQLのNULLを理解してクエリを書く）
- GROUP BYを複数使用する際、曖昧な表現にならないように注意する
- クエリ内にて、RAND()をできるだけ使用しない（ソート処理するため）
- 全文検索を行う際には、SQLで実装せず提供されている機能を使用する
- 複雑なクエリを1つ実装するより、単純なクエリを複数実装する
- 必要に応じて列名やテーブル名などは明記する
- PWの格納時、ソルト付与し合わせて最低20字にしてハッシュ化する
- 動的なSQLクエリの生成時は基本的にはプリペアドステートメントを使用する
- 疑似キーの欠番は埋めない仕様、運用を行う
- 返り値があるときはエラーチェックのため無視をしない
- バージョン管理とドキュメンテーションは必ず行うこと
- モデルをアクティブレコードにしない
- コンティンジェンシープランは災害などあらゆる可能性を考慮し作成する
*...SQL側での制約を行えなくなり、誤ったデータの挿入が容易なため
-------------
こんなところでしょうか。
文字にしてみると意外と当たり前のことですね。
しかしなかなかこういったことの言語化は難しいものだと思っています。
べき集は数多くありますが、べからず集はなかなかないですからね。
ただDBを専門的に扱ってきた方たちからすると極めて一般的で、かつ初心者向けの内容と感じられたのでしょうか。
Applicationレイヤにいるとこの内容を知らずにキャリアを積んでいる方が多い印象です。PMやOperationsよりの方たちはもうちょっと知っている方が多いでしょうか。
その部分のスキルセットの違いが大きく課題になったりすることもあります。（アプリの実装が悪くて、などはたくさん聞きます）
僕個人としてはなんでもできるつよつよエンジニアになりたいです（願望）
最後まで読んでいただき、ありがとうございました。
