ホームページ  >  記事  >  データベース  >  MySQL データベース設計暫定仕様書 V1.0

MySQL データベース設計暫定仕様書 V1.0

黄舟
黄舟オリジナル
2017-02-16 11:58:591349ブラウズ



データベース設計仕様:

1、テーブル設計仕様

1.1 テーブル設計について

a) テーブル名と列名は次のようにする必要があります。注記。

b)名前に意味のある英単語や略語を使用するには、「_」で区切って複数の単語を使用する必要があります。使用できるのは英文字、数字、アンダースコアのみで、スペースは入れません。 。たとえば、USER_DETALL では、キーワード TYPE または STATUS をフィールド名として使用することはできません。

c) 名前の長さは 15 文字を超えてはなりません (20 文字を超えることは避けてください)。データセットのビジネス範囲、または POWER_USER (ユーザー センター) などのビジネス機能を反映する必要があります。

d) フィールドの型が列挙型またはブール型の場合、CHAR(1) (または CHAR(2)) 型を使用し、デフォルト値を入力します。ステータス フィールドのデフォルト値は null にすることはできず、通常は null です。 0 または - 1 に設定されます。ステータス フィールドの説明は、「グループ購入クーポンのステータス: 1. 購入済み、2. 使用済み、3. 返金済み、4. 返金済み」と書かれています。

e) デザイン時に日付フィールドを含めるようにしてください: CREATE_DATE (作成日)、UPDATE_DATE (更新日) など。 MySQL は、「2014-12-31 00:00:00.0」などの日付の入力方法に同意します

f) 数値型のデフォルト値は 0、文字列の場合は ''、日付のデフォルト値は次のとおりです。 「1900-01-01 00:00:00.0」。

g) 主キーフィールド ID に bigint を使用します。create ステートメントに AUTO_INCREMENT=6653864 マークがある場合は、それを削除してください。

h) 日付フィールドのデフォルト値は null にすることはできず、通常は 1970-12-31 00:00:00.0 に設定されます。

i) 携帯電話フィールド、電子メールフィールド、および取得されるその他のフィールドは null にすることができず、デフォルト値は空の文字列 '' です。数値タイプのフィールドは null にすることができず、デフォルト値は 0 です。

j) デフォルトの文字エンコーディングは utf8 で、デフォルトのストレージ エンジンは INNODB です

追記: 各テーブルには主キー フィールドとエントリ日付フィールドが必要で、値を NULL にすることはできません。

1.2 インデックスの設計

1) 通常のインデックス、IDX_ で始まるフィールド名を接続します。

2)create_date(入力時間)フィールドなど、値範囲の小さな複製比を持つフィールドに対して作成されるインデックス化されています。 IS_RETURN (返金されたかどうか) フィールド。

3) 主キー フィールドに一意のキーを作成する必要はなく、主キー フィールドに別のインデックスを作成する必要もありません。

4) ORDER_GOODS テーブルの ORDER_SN (製品番号) など、WHERE 条件の背後で頻繁にクエリされるフィールドにはインデックスを付ける必要があります。

5) SHOP_MALL テーブルの IS_DEL フィールドなどの範囲フィールドにはインデックスを付ける必要はありません。

6) インデックス付けされるフィールドには null 値があってはなりません。そうしないと、インデックスの効率に影響します。

1.3 テーブル構造の例

テーブル作成文の例:

CREATE TABLE `SHOP_GAY` (

) `ID` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 'ショップID',

`SHOP_NAME` VARCHAR(50) DEFAULT '' COMMENT 'ショップ名',

`LEGAL_PERSON_MOBILE` VARCHAR(11) DEFAULT NULL COMMENT '正規の携帯電話',

` SCORE` BIGINT(20) DEFAULT 0 COMMENT 'ポイント',

...

`MANAGER_NAME` VARCHAR(20) DEFAULT '' COMMENT '店長の名前',

`BRIEF ` VARCHAR (500) DEFAULT '' COMMENT '店舗紹介',

`HAS_WAREHOUSE` CHAR(1) DEFAULT '0' COMMENT '倉庫の有無、0:なし 1:あり',

`DESCRIPTION_FIT` DECIMAL(3,1) DEFAULT 0 COMMENT '説明は一致します -- すべての注文項目の評価の平均を計算し、小数点第 1 位を取得することによって取得されます',

`BACKGROUND` VARCHAR( 200) DEFAULT '' COMMENT 'ストアタイトル画像',

`CREATED_DATE` TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '作成時間',

`UPDATED_DATE` DATETIME DEFAULT '1970-12-31 00:00 :00.0' コメント'更新時刻', KEY IDX_UP TIME(UPDATED_DATE)

) ENGINE=INNODB DEFAULT CHARSET=utf8 COMMENT='GAY ストア'

フィールドの追加例:

ALTER TABLE AUTH_MALL ADD COLUMN SHORT_NAME VARCHAR(20) DEFAULT '' COMMENT ' スクエア名の略語 ' AFTER FULL_NAME ;

テーブルフィールドの変更例:

ALTER TABLE GATEWAY_PAYMENT_ORDER MODIFY COLUMN STAT varchar(2) デフォルト '0'

コメント '取引ステータス 0: 支払い/返金保留中、1: サードパーティチャネルからのコールバック待ち、2: 支払い/返金成功、3: 支払い/返金失敗、4: 支払い/返金確認成功、5: 支払い/返金確認失敗、6; 取引終了、7: 支払い保留中 (このステータスの場合 - 受取口座が正常かどうかを確認する必要があります)、8: 支払い/返金確認成功 - 他の操作は許可されません、9: 署名検証失敗、10: 同期確認/購入者が支払いました - 販売者が発送するのを待っています WAIT_SELLER_SEND_GOODS、11: 同期確認/販売者が発送し、購入者が確認するのを待っています WAIT_BUYER_CONFIRM_GOODS の AFTER DESCRIPTION;

2 SQL

2.1 を書くときは、単一​​テーブルのクエリを使用し、複数テーブルの JOIN を避けるようにしてください。後続の JOIN の ON 条件は、SELECT A.C1,B.C2 FROM A,B ON(A.ID=B.PID OR B.TAG=A.TAR_GET) のように OR で判断できません。パフォーマンスは非常に低くなります。 , PS: オンラインで開くのが遅い一部の機能モジュールは、この OR 書き込み方法が原因で発生します。

2.2 では、アプリケーションの SQL ステートメントを作成し、作成、削除、変更、付与、削除などのすべての DDL 操作を禁止します。特別なニーズがある場合は、使用する前に DBA に相談してください。 。

2.3. SQLを記述するときは、各フィールドの接頭辞としてテーブル名を必ず指定してください。たとえば、user_business ub where ub.create_date > から ub.id,ub.name を選択します。iBatis の SQLMap ファイルでは、バインディング変数は「#var_name」で表され、置換変数は「$var_name$」で表されます。 "; すべては動的な順序を必要とします by 条件付きのクエリに置換変数を使用する場合、受信される可能性のあるコンテンツを列挙としてコード内にハードコーディングする必要があり、外部から受信するコンテンツを受け入れることは禁止されています。

2.4 では、innodb を使用してデータベースに接続するときに、トランザクションのサポートが必要な場合は、次のように自動送信をオフにします。 set auto_commit=0;トランザクション処理の場合、例外コード ブロックに挿入、削除、更新、コミットを実行した後、ロールバック操作を記述する必要があります。

2.5、select * のようなコードは書かないでください。フィールド名を指定する必要があります。

2.6 では、MySQL の日付と文字は同じであるため、次のような Oracle のような追加の変換を行う必要はありません:

select e.username fromemployee e where e.birthday> ;=' 1998-12-31 11:30:45'。

2.7、ビジネス要件である場合を除き、where 句のフィールドに関数を適用することは避けてください。ただし、記述する際には DBA に相談する必要があります。たとえば、DATE_FORMAT(p.PAYMENT_DATE, '%Y-%m-%d') >= DATE_FORMAT('2014-10-01', '%Y-%m-%d') を修正する必要があります。

2.8、group by を使用する場合、デフォルトで並べ替えが実行されます。並べ替える必要がない場合は、order by null を使用できます。 2.9、テーブルを接続する際、接続に使用する2つのテーブルのフィールドのデータ型が一致しない場合は、片方に型変換関数を追加する必要があります。 mysql が暗黙的な型変換を実行しないようにします。

2.10 では、アプリケーション内のデータベースに対してバッチ更新 SQL 操作を実行することは禁止されています。必要に応じて電子メールを送信してください。DBA が判断し、適切なタイミングで IDC ライブラリ上で手動で実行します。期間。

3、基本原則

PS: テーブル構造の変更は、データベース テーブルが属するチームによって開始される必要があります。

1. テスト環境で実行されるテーブル構造に対するすべての SQL 変更は、DBA によってレビューされる必要があります。


2、物理的な削除は許可されていません。ストアドプロシージャ、トリガー、ビューは許可されていません。特別な状況とビジネスシナリオがDBAに適用されます

PS: すべての仕様は適応可能です皆様のビジネスシーンに合わせて、より良いご提案をいただければ幸いです。今後もビジネスの発展に合わせて最適なデータベース仕様をまとめ、拡張していきます。

上記は MySQL データベース設計暫定仕様書 V1.0 の内容です。その他の関連内容については、PHP 中国語 Web サイト (www.php.cn) をご覧ください。





声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。