Alibabaコーディングガイドラインがよかった件

中国のECサイト？のアリババのコーディングガイトを見た

github.com

私はJavaの開発をしたことがないので
このjava ガイドラインの部分をみても・・・そうなんだ〜としか言えない
印象は細かいな〜大きい企業になれば細かいのかな
MySQLのルールは自分の会社でも使えると思うので取り入れていきたと思う

テーブルスキーマのルール
インデックスルール
SQLルール

テーブルスキーマのルール

1.[必須]TrueまたはFalseの概念を表す列

is_xxxという名前にする必要があります。データ型は符号なしtinyint（1がTrue、0がFalse）である必要があります

XXX_flagだったりバラバラなのでこれも統一したほうがいいのね

2.[必須]表と列の名前

小文字、数字またはアンダースコアで構成されていなければなりません。
2つのアンダースコアの間に数字だけを含む名前（他の文字は含まない）と名前で始まる名前は許可されません。
カラム名を変更するにはコストがかかり、リリース前の環境ではリリースできないため、カラム名は慎重に指定する必要があります。

カラム名を変更するなんて、リリース後にはない。コストというより怖くてできないな

3.[必須]複数の名詞

テーブル名として使用できません。

そうなの・・・気にしたことなかった

4.[必須] desc、range、match、delayedなど

キーワードは使用しないでください。MySQLの公式ドキュメントから参照することができます。

知らなかった・・・description（説明）で使っている・・・やばいな〜

5.[必須]プライマリキーインデックスの名前の先頭にpk_を付け、カラム名を続けます。ユニークなインデックスは、列名の先頭にuk_を付けて名前を付ける必要があります。通常のインデックスは、idx_ [column_name]の形式にする必要があります。

これは同じだわ

6. [必須] 小数点以下は10進数

floatとdoubleは使用できません。
浮動小数点数と倍精度浮動小数点数が格納されていると精度が低下する可能性があり、データの比較結果が正しくない可能性があります。格納するデータ範囲が小数点以下の範囲を超える場合は、積分部分と小数部分を別々に格納することをお勧めします。

デシマルか・・・精度を求められることなからついついfloatとか使っている

7. [必須]その列に格納する情報の長さがほぼ同じ場合

charを使用します。

これは普通にそうだよね

8. [必須] varcharの長さは5000を超えてはいけません

他の列の索引付け効率への影響を避けるために、それらを別の表に保管する方がよいでしょう。

今後は気をつけます

9. [必須]表には、id、gmt_create（作成日）、およびgmt_modified（更新日）

3つの列が含まれていなければなりません

　→　名前はちがうけど普通だね
　　　古いサイトだと更新日がない・・・
　　　リレーションシップテーブルの場合もいるのかな

10. [推奨]テーブル名を[table_business_name] _ [table_purpose]として定義すること

　→　なんとなくわかる

11. [推奨]アプリケーション名と同じデータベース名を定義してください。

なんとなくわかる

12. [推奨]新しいステータス値を追加

カラムのコメントを更新します

DB設計書にやるけど、コメントも修正するのか

13. [推奨]一貫性を考慮

検索パフォーマンスを向上させるために、複数のテーブルに重複して適切な列を格納することもできますが、一貫性を考慮する必要があります。冗長列は、次のようにすべきではありません
1）頻繁に変更される列。
2）非常に長いvarcharまたはテキストで型付けされた列。

例
商品カテゴリの名前は短く、頻繁に使用され、ほとんど決して変更/固定値ではありません。これらは、関連するテーブルに重複して格納されて、結合クエリを避けることができます。

14. [推奨]データベースのシャーディング

1つのテーブルまたはテーブルに500万行を超える行が2GBを超える場合にのみ推奨されます
シャーディングとはパーティション化のことです。RANGEパーティション化でいうとテーブルを年月毎にデータを分けて特定の年月のデータだけを取得したいなら、そのデータが入っているパーティションだけをアクセスすることでパフォーマンスを改善する

やりたいけどできていない

インデックスルール

1. [必須]ビジネスロジックが適用できる場合

一意のインデックスを使用する必要があります

やりたいけどできていない

2. [必須]JOINは、3つ以上のテーブルが関係する場合は許可されません

結合する列は、絶対に類似したデータ型でなければなりません。結合する列に索引が付いていることを確認します

10個とかやっているSQLがあるわぁ～

3. [必須] varcharカラムにインデックスを追加するとき

インデックスの長さを指定する必要があります。インデックスの長さは、データの分布に従って設定する必要があります。

知らなかった

4. [必須] LIKE '％...'またはLIKE '％...％'はページングで検索するときには使用できません。

本当に必要な場合は、検索エンジンを使用できます。
検索エンジンとは
MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.9 全文検索関数

5. [推奨] ORDER BY句を使用する場合は、インデックス順を使用してください。

ORDER BY句の最後の列は、複合インデックスの末尾にある必要があります。
その理由は、file_sortの問題を避けることで、クエリのパフォーマンスに影響します

OKな例：
ここで、a =？そしてb =？cで注文する。インデックスは：a_b_c

NGの例：
クエリ条件に範囲が含まれている場合、インデックス順序は有効になりません（例：a> 10 by b; 索引a_bはアクティブ化できません。

6. [推奨] SQLパフォーマンス最適化の目標は、EXPLAINの結果タイプがREFレベル

またはRANGE以上になること、または可能であればCONSTSに到達することです
条件：
多くても1つの一致する行があり、これはオプティマイザによって読み取られます。それは非常に速いです。

REF：
通常のインデックスが使用されます。

範囲：
=、<>、>、> =、<、<=、IS NULL、<=>、BETWEENなどのいずれかを使用してキー列を定数と比較するときに使用できるインデックスの範囲が取得されます。またはIN（）演算子です。

SQLルール

1. [必須] COUNTについて

COUNT（*）の代わりにCOUNT（column_name）またはCOUNT（constant_value）を使用しない。
COUNT（*）はSQL92で定義された標準構文で、行数をカウントします。これはデータベース特有のものではなく、NULLおよびNULL 以外のものとは関係ありません。

COUNT（*）はNULL行をカウントしますが、COUNT（column_name）はNULL値の行を考慮しません

2. [必須] NULLについて

1）NULL <> NULLはfalseではなくNULLを返します。
2）NULL = NULLは、trueではなくNULLを返します。
3）NULL <> 1はtrueではなくNULLを返します。

3. [必須]ストアドプロシージャは許可されません。

デバッグ、拡張、および移植が困難です。

これは危険なので納得！！

4. [必須]データの修正、DBレコードの削除と更新とき

データの正確性を確保するためにSELECTを行う必要があります。

２重送信とかあるもんね

5. [推奨] IN節は避けてください。

IN節のレコードセットサイズは、慎重に評価し、避けられない場合は1000以内で制御する必要があります。

6. [ご参考]文字数カウントの注意

グローバル化のニーズのためには、文字が表現されて格納されるべきUTF-8 、および文字数カウントの注意が必要です。
SELECT LENGTH（ "山田太郎"）; 12を返します。
SELECT CHARACTER_LENGTH（ "山田太郎"）; 4を返します。UTF-8との違いを考慮して、必要に応じてUTF8MB4エンコードを使用する。