MySQLデータの特定のフィールドのコンテンツを保存できず、特定のフィールドのコンテンツをページで読み取ることができません

MySQLデータの特定のフィールドのコンテンツを保存できず、特定のフィールドのコンテンツをページで読み取ることができません

データベーステーブルフィールドの命名規則

要約：現在の研究開発作業では、データベーステーブルやデータベーステーブルのフィールド形式が不規則であるため、開発の進行に影響を与える問題がしばしば発生します。元のデータベーステーブルを後続の開発で使用する場合、データベーステーブルの可読性は十分に高くありません。 、およびテーブルフィールドルールは十分に高くありません。統合すると、データクエリが発生し、データ使用の効率が低下します。したがって、これらの問題を解決および最適化するには、適切なデータベーステーブルフィールドの命名規則のセットを整理する必要があります。

この記事は、データベースの命名、データベースのテーブルの命名、データベースのテーブルのフィールドの命名、SQL言語のコーディングを含む標準化されたドキュメントです。研究開発で発生しやすい問題や一般的なエラーに合わせて編成および変更され、データベースに関連しています。将来の関連する研究開発。仕事の準備をしてください。

1つは、データベースの命名規則です。

26個の英字（大文字と小文字を区別）と0〜9個の自然数（多くの場合不要）とアンダースコア ' 'を使用します。名前は簡潔で明確で、複数の単語はアンダースコアで区切られます ' '、1つのプロジェクトは1つのデータベース、複数のプロジェクトは注意同じデータベースを使用する

次に、データベーステーブルの命名規則

2.1データシートの命名規則

（1）26個の英字（大文字と小文字を区別）と0〜9の自然数（多くの場合不要）とアンダースコアで構成され、名前は簡潔で明確であり、複数の単語はアンダースコアで区切られています ' '

（2）大文字ではなく、すべて小文字で名前を付けます

（3）名前、時刻、日時、パスワードなどのデータベースキーワードの使用は禁止されています。

（4）テーブル名は長すぎてはいけません（通常は3つ以下の英語の単語）

（5）テーブルの名前は、通常、名詞または動詞-目的語句を使用します

（6）名前を表すには、単数形を使用します。たとえば、従業員の代わりに従業員を使用します。

詳細テーブルの名前は次のとおりです。メインテーブルの名前+文字dtl（詳細の省略形）

例：発注書の名前はpo_orderであり、発注書の詳細テーブルはpo_orderdtlです。

（7）テーブルに説明情報を入力する必要があります（SQLステートメントを使用してテーブルを作成する場合）

2.2命名規則

①module_+ファンクションポイントの例：alllive_log alllive_category

②機能ポイント例：ライブメッセージ

③一般表の例：all_user

2.3最適化する命名の例

①冗長性：

エラーの例：yy_alllive_video_recomment yy_alllive_open_close_log

注：プロジェクト名を削除し、テーブル名の長さを単純化して、「yy_」に移動します

②同じカテゴリーのテーブルの命名に違いがあり、管理が悪い

エラーの例：yy_all_live_category yy_alllive_comment_user

注：プロジェクト名を削除し、命名規則を統一してください。すべて「yy_alllive_」で始まります。

③命名形式が異なります

エラーの例：yy_showfriend yy_user_getpoints yy_live_program_get

説明：アイテム名を削除し、命名規則を統一し、動詞と目的語のフレーズを分離し、動詞と目的語の論理シーケンスを統一します

3、データベースフィールドの命名規則

3.1フィールドの命名規則

（1）26個の英字（大文字と小文字を区別）と0〜9の自然数（多くの場合不要）とアンダースコアで構成され、名前は簡潔で明確であり、複数の単語はアンダースコアで区切られています ' '

（2）大文字ではなく、すべて小文字で名前を付けます

（3）説明情報をフィールドに入力する必要があります

（4）名前、時刻、日時パスワードなどのデータベースキーワードの使用は禁止されています。

（5）フィールド名は通常、名詞または動詞-目的語句を使用します

（6）使用するフィールドの名前は、わかりやすくする必要があります。通常、英語の単語は3語以内です。

（7）テーブルの列に名前を付けるときは、テーブルの名前を繰り返さないでください

たとえば、employeeという名前のテーブルでemployee_lastnameという名前のフィールドを使用することは避けてください

（8）列の名前にデータ型を含めないでください

（9）フィールドの命名にはフルネームを使用し、省略形は使用しないでください

3.2命名規則

①名詞の例：user_id user_name sex

②動詞句の例：is_friend is_good

3.3最適化する命名の例

①大文字の規則が統一されていない

間違った例：user_id houseID

注：統一されたルールを使用して、「user_id」と「house_id」に変更してください

②下線が引かれたルールが統一されていない

間違った例：username userid isfriend isgood

注：アンダースコアを使用して、分類、再現性の向上、および管理の容易化を行い、「user_name」、「user_id」、「is_friend」、および「is_good」に変更します。

③フィールドが明確でない

エラーの例：uid pid

注：読みやすさを向上させるためにフルネームを使用し、「user_id」および「person_id」に変更してください

3.4フィールドタイプの仕様

（1）次のデータ型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinaryを除くすべてのフィールドを設計する場合、デフォルト値が必要です。文字タイプのデフォルト値は、の空の文字列です。文字。、数値型のデフォルト値は値0であり、論理型のデフォルト値は値0です。

（2）システム内のすべての論理型で、値0は「false」として表され、値1は「true」として表されます。datetimeおよびsmalldatetime型フィールドにはデフォルト値がなく、NULLである必要があります。

（3）フィールドのデータを格納するためにできるだけ少ないストレージスペースを使用します

intを使用する場合は、varchar、charを使用しないでください。

varchar（256）の代わりにvarchar（16）を使用しないでください

IPアドレスはint型を使用します

固定長タイプは、charを使用するのに最適です。例：postcode（postcode）

tinyint、intを使用できる場合は、smallintを使用しないでください

各フィールドにデフォルト値を指定することをお勧めします。できればnullではありません。

（4）適切なフィールドタイプを使用してスペースを節約します

文字は数値に変換されます（変換可能な最高の変換であり、スペースを節約し、クエリのパフォーマンスを向上させます）

NULLフィールドの使用は避けてください（NULLフィールドはクエリと最適化が難しく、NULLフィールドインデックスには余分なスペースが必要であり、NULLフィールドの複合インデックスは無効です）

使用するテキストタイプを減らします（テキストフィールドの代わりにvarcharを使用してみてください）

3.5データベースの各フィールドの正規の説明

（1）第3正規形（3NF）の標準に準拠するようにしてください

 表内的每一个值只能被表达一次 

 表内的每一行都应当被唯一的标示 

 表内不应该存储依赖于其他键的非键信息

（2）フィールドが実際に他のテーブルのキーワードに関連付けられており、外部キー参照として設計されていない場合は、インデックスを作成する必要があります

（3）フィールドが他のテーブルのフィールドに関連している場合は、インデックスを作成する必要があります

（4）ファジークエリ以外の条件でフィールドを検索する必要がある場合は、インデックスを作成する必要があります

（5）クラスター索引の作成を可能にする主キーを除いて、他のフィールドの索引は非クラスター索引でなければなりません。

4、SQL言語コーディング標準

4.1大文字の使用

（1）INSERT、UPDATE、DELETE、SELECTとその句、IF……ELSE、CASE、DECLAREなど、すべてのキーワードは大文字にする必要があります。

（2）ユーザー変数を除くすべての関数とそのパラメーターは大文字にする必要があります

（3）変数を定義するときに使用されるデータ型は小文字でなければなりません

4.2注意事項

コメントはバッチ処理に含めることができます。トリガーとストアドプロシージャに説明コメントを含めると、テキストの読みやすさと保守性が大幅に向上します。この仕様では、次のことを推奨しています。

（1）コメントは主に英語です。実際のアプリケーションでは、中国語のコメント付きのSQLステートメントバージョンは英語環境では使用できないことがわかります。後続のバージョンの実行中の異常エラーを回避するために、推奨されます。英語のコメントを使用するには

（2）コメントはできるだけ詳細かつ包括的にする必要があります。各データオブジェクトを作成する前に、オブジェクトの機能と目的を詳細に説明する必要があります。入力パラメータの意味を説明する必要があります。値の範囲が決定されている場合は、また、一緒に説明する必要があります。特定の意味を持つ変数（ブール変数など）の場合、各値の意味を指定する必要があります。

（3）コメント構文：単一行コメント、複数行コメント

1行コメント：コメントの前に2つのハイフン（–）があり、変数と条件節に使用できます。

複数行のコメント：記号の間の内容はコメントの内容です。完全な操作には、このタイプのコメントを使用することをお勧めします。

（4）注記は簡潔であり、説明は明確である必要があります

（5）機能コメント：

トリガー、ストアドプロシージャ、その他のデータオブジェクトなどの関数テキストを作成する場合は、各関数に適切なコメントを追加する必要があります。コメントは主に複数行のコメントであり、主な構造は次のとおりです。

プロシージャの作成sp_xxx

上記はhttps://www.cnblogs.com/isme-zjh/p/11720160.htmlから転送されます

栗をあげる

栗を少し与えます（バックエンドの対応するフィールドの内容は保存できません）

フィールド名はdomain_certificate_creditCardです。このフィールドの内容はデータベースに保存できますが、このフィールドの内容をバックエンドに保存することはできません。
domain_certificate_creditCardフィールドをdomain_certificate_credit_cardに変更すると、データベースを正常に保存できます。

private String domain_certificate_credit_card;//域名证书（信用卡）

別の小さな栗を与えます（フロントエンドは対応するフィールドの内容を読み取ることができません）

CS_Email_idという名前のフィールドはデータベースに保存できますが、フロントエンドページでajax値を取得すると、このフィールドの下のコンテンツを取得できません。
Google Chromeが開発者ツール（F12）を開いたところ、このフィールドの下にコンテンツがあることがわかりました。確認して再確認すると、開発者ツールによって返されるjsonに対応するフィールドが小文字のCS_Email_id、つまりcs_email_idであることがわかりました。

上記を設定する必要があるか、コーディング上の理由であると思われます。あなたが良い解決策を持っているなら、コメントエリアにコメントを残してください。親指を立ててくれてありがとう。