PHPCMS 開発ドキュメントの PHP コーディング仕様を参照してください。

注: これは PHPCMS 開発ドキュメントのコーディング仕様です。PHPCMS 開発仕様と呼ばれていますが、すべての PHP プログラミングはこうあるべきだと思います。 PHP をたくさん書いてきたので、この標準と比較して多くのコーディングが不足していると感じました。今後修正する必要があります。

Phpcms コーディング仕様
1. はじめに…2
2. 適用範囲…2
3. 標準化の重要性と利点… 3
4. PHP コーディングの標準と原則… 3
4.1. コードのマークアップ… 3
4.2. 注意点…3
4.3. 書き方のルール…4
4.3.1. インデント…4
4.3.2. 中括弧 {}、if およびスイッチ 4
4.3.3. 演算子、括弧、スペース、キーワード、関数… 5
4.3.4. 関数定義…6
4.3.5. 引用符…6
4.3.6. 多言語の問題… 7
4.4. 命名原則… 8
4.4.1. 変数、オブジェクト、関数名…8
4.4.2. 定数…8
4.5. 変数の初期化と論理チェック… 8
4.6. セキュリティ…9
4.7. 互換性…9
4.8. コードの再利用…10
4.9. その他の詳細…10
4.9.1. 通話を含む…10
4.9.2. エラー報告レベル…11
5. データベースの設計… 11
5.1. フィールド…11
5.1.1. テーブルとフィールドの名前付け… 11
5.1.2. フィールド構造…11
5.2. SQL文…12
5.3. パフォーマンスと効率…13
5.3.1. 固定長テーブルと可変長テーブル…13
5.3.2. 操作と取得…13
5.3.3. 構造の最適化とインデックスの最適化…14
5.3.4. クエリの最適化…14
5.3.5. 互換性の問題…16
6. テンプレートのデザイン…16
6.1. コードのマークアップ…16
6.2. 書き方のルール…16
6.2.1. HTML 16
6.2.2. 変数…16
6.2.3. 言語要素…17
6.2.4. インデント…17
7. ファイルとディレクトリ… 17
7.1. ファイルの命名…17
7.2. ディレクトリの命名…18
7.3. 空のディレクトリインデックス…18

1. はじめに
この仕様は、開発者が長期間にわたって蓄積した成熟した経験を統合および洗練するプログラミング原則で構成されており、優れた一貫したプログラミング スタイルの形成に役立つことを目的としています。半分の労力で 2 倍の結果を達成するために、このドキュメントは必要に応じて随時更新されます。
著作権: Shaanxi Jiusi Lulu Network Technology Co., Ltd.、全著作権所有
最終更新日: 2006 年 11 月 20 日

2.適用範囲
特別な指示がない限り、次のルール要件は phpcms プロジェクトに完全に適用され、社内の他のほとんどの PHP プロジェクトにも適用できます。

3. 標準化の重要性と利点
ソフトウェア プロジェクトが公的で一貫した標準に準拠しようとすると、プロジェクトに関与する開発者がプロ​​ジェクト内のコードを理解し、プログラムのステータスを把握しやすくなります。これにより、新しい参加者がすぐに環境に適応できるようになり、一部の参加者が時間を節約する必要から自分のスタイルを確立したり、生涯にわたる習慣を身につけたりして、他の参加者が読書に過度の時間とエネルギーを浪費することを防ぎます。また、一貫した環境では、コーディング エラーの可能性も減らすことができます。欠点は、人によって基準が異なるため、コーディング スタイルに適応して変更するのに時間がかかり、一時的に作業効率が低下することです。プロジェクトの長期的な健全な発展と、後期におけるチームの作業効率の向上を考慮すると、一時的な作業効率の低下は考慮する価値があり、必ず通過しなければならないプロセスでもあります。標準はプロジェクトの成功の鍵ではありませんが、チームのコラボレーションをより効率的にし、確立されたタスクをよりスムーズに完了するのに役立ちます。
1. プログラマーはあらゆるコードを理解し、プログラムのステータスを理解できます
2. 新人はすぐに環境に適応できます
3. PHP を初めて使用する人が、時間を節約するために独自のスタイルを作成したり、生涯にわたる習慣を形成したりするのを防ぎます
4. PHP を初めて使用する人が同じ間違いを何度も繰り返さないようにします
5. 一貫した環境では、人々は間違いを犯す可能性を減らすことができます
6. プログラマには共通の敵がいる

4. PHP コーディングの標準と原則

4.1. コードタグ
PHP プログラムは、PHP コードを定義するために または を使用できます。このフォームは、HTML ページに純粋な変数を埋め込むときに使用できます。
近年、PHP 開発チームはコードの標準化と標準化を提唱しています。PHP の将来のバージョンでは、この短縮形が廃止されるか、廃止される可能性があります。そのため、プログラムの互換性を高めるために、

を統一する予定です。リリース。

4.2. コメント
コメントは、忘れられやすいコードに簡単な紹介コンテンツを追加するために使用されます。 C スタイルのコメント「/* */」と標準の C++ コメント「//」を使用してください。

プログラム開発中に一時的なコードやデバッグ コードを残すことは避けられず、そのようなコードは将来忘れられないようにコメントする必要があります。すべての一時コード、デバッグ コード、および実験コードには、統一されたコメント マーク「//debug」とその後に完全なコメント情報を追加する必要があります。これにより、プログラムのリリース前と最終的なデバッグの前に、プログラムに疑わしい問題があるかどうかをバッチ チェックすることが容易になります。コード。例:
$num = 1;
$flag = TRUE; //デバッグは、$flag に値を割り当てる必要があるかどうかを判断できません
if(空($flag)) {
//ステートメント
}

4.3. 記述ルール

4.3.1. インデント
各インデントの単位規則は 1 つの TAB (8 つの空白文字幅) であり、コードを記述する際のエラーを防ぐために、プロジェクトに参加する各開発者がエディター (UltraEdit、EditPlus、Zend Studio など) で設定する必要があります。忘れることによって起こる異常。
このインデント仕様は、PHP および JavaScript の関数、クラス、論理構造、ループなどに適用されます。

4.3.2. 中括弧 {}、if と switch
最初の括弧はキーワードと同じ列にあり、最後の括弧はキーワードと同じ列にあります。 if 構造では、if と elseif の前後に 2 つの括弧があり、左右にスペースがあり、すべての中括弧は別の行にあります。さらに、if の後にステートメントが 1 行しかない場合でも、構造を明確にするために中括弧を追加する必要があります。 switch 構造では、通常、case ブロックを処理すると、後続の case ブロックの処理がスキップされるため、多くの場合、ブレークを追加する必要があります。ブレークの位置は、プログラムのロジックによって異なります。ただし、同じスイッチ本体内では、ブレークの位置形式は一貫している必要があります。
以下は、上記の仕様に準拠した例です:
If ($condition)
{
スイッチ ($var)
{
ケース 1: echo 'var is 1';
; ケース 2: echo 'var is 2';
; デフォルト: echo ‘var は 1 でも 2 でもありません’;
}
}
それ以外
{
スイッチ ($str)
{
ケース「abc」:
$result = 'abc';
休憩;
デフォルト:
$result = '不明';
休憩;
}
}

4.3.3. 演算子、括弧、スペース、キーワード、関数

各演算子と、演算に含まれる値または式の間には、両側にスペースが必要です。唯一の例外は、文字連結演算子記号

の両側にスペースがないことです。 左括弧 "(" は関数キーワードと密接に関連している必要があります。それ以外の場合は、スペースを使用して "(" を前のコンテンツから区切る必要があります。
右括弧「)」は、その後に「)」または「.」が続く場合を除き、スペースで区切る必要があります。 文字列内で特に必要でない限り、通常の状況では、プログラムや HTML には 2 つの連続するスペースは表示されません。 いかなる状況でも、PHP プログラム内に TAB またはスペースを含む空行を表示してはなりません。つまり、そのような空行には TAB またはスペースを含めてはなりません。同時に、プログラム行の末尾に余分な TAB やスペースを含めることはできません。ほとんどのエディタには、行末のスペースを自動的に削除する機能が備わっています。習慣がうまく育っていない場合は、それを一時的に使用して、不要なスペースを避けることができます。 大きなプログラム本体では、上下に空行を 1 行だけ追加してください。複数行は禁止です。
プログラム ブロックの分割は、できる限り合理的である必要があります。分割が大きすぎたり、小さすぎたりすると、他の人のコードの読み取りや理解に影響を与えます。一般的には、より大きな機能定義、論理構造、機能構造に分けることができます。 15 行未満のプログラム ブロックの場合、下位および下位の空白行は必要ありません。 説明や表示部分で、中国語、数字、英単語が混在する場合は、数字や英単語の前後にスペースを入れてください。

上記の原則に基づいて、次の例は正しい記述形式を示しています。
$result = (($a + 1) * 3 / 2 + $num)).’テスト’;
$condition ? func1($var) : func2($var);
$condition ? $long_statement
: $another_long_statement;

if ($flag)

{

//ステートメント
//15行以上
}
Showmessage('データを復元するには、restore.php ツールを使用してください。');

4.3.4. 関数の定義

l パラメータの名前は、変数
の命名規則と一致しています。 l 関数定義の左括弧は、間にスペースを入れずに関数名のすぐ隣にあります。 l 左中括弧は新しい行で開始します
l デフォルト値を持つパラメータはパラメータリストの最後に配置する必要があります
。 l 関数を呼び出して定義するときは、パラメータの間にスペースを追加します。

l 関数の開始インデント位置と終了インデント位置が異なる現象を注意深く確認し、効果的に除去する必要があります。

たとえば、標準に準拠した定義:
関数 authcode($string, $operation, $key = '')
{
if($flag)
{
//ステートメント

}

//関数本体
}

不適合の定義:
function authcode($string,$operation,$key = '') {
//関数本体
}

4.3.5. 引用符
PHP では、一重引用符と二重引用符の意味が異なります。最大の違いは次のとおりです。 一重引用符内では、変数 ($var) と特殊なエスケープ文字 (「t r n」など) は解析されないため、PHP の解析速度は高速になります。エスケープ文字は「'」と「\」のみをサポートします。引用符とバックスラッシュ自体
二重引用符で囲むと、変数 ($var) の値が文字列に置き換えられ、特殊なエスケープ文字も特定の単一文字に解析されます。また、「$」など、上記 2 つの特性を特に対象とした特殊な関数エスケープもいくつかあります。 " と "{$array['key']}。プログラムの作成は便利ですが、PHP の解析も非常に遅くなります。 配列内で添字が整数ではなく文字列型である場合、添字を一重引用符で囲むようにしてください。正しい書き方は $array[key] ではなく $array['key'] です。この書き方は、PHP パーサーに key を定数であると認識させ、その定数が存在しない場合は、"key" を添え字として式に取り込みます。同時に、エラー イベントがトリガーされ、通知レベルのエラーが生成されます。
したがって、一重引用符を使用できるほとんどの状況では、二重引用符は禁止されています。上記の分析に基づいて、一重引用符を使用できる状況、または使用する必要がある状況には次のようなものがありますが、これらに限定されません:
l 文字列は固定値であり、「t」などの特殊なエスケープ文字は含まれません。 l $array[‘key’] などの配列の添字を修正しました。 l 式に変数を含める必要はありません。たとえば、$string = “test$var” の代わりに $string = ‘test’; 例外として、phpcms では正規表現 (preg_ シリーズ関数および ereg シリーズ関数に使用) ではすべて二重引用符が使用されます。これは、手動による分析と記述の便宜のためであり、正規表現の統一性を維持し、不必要な分析を減らすためです。
データベース SQL ステートメントでは、すべてのデータを一重引用符で囲むことはできませんが、SQL クエリを実行する前に intval 関数で処理する必要があります。インジェクションの脆弱性や SQL エラーを避けるために、すべての文字列を一重引用符で囲む必要があります。正しい書き方は次のとおりです:
$catid = intval($catid);
SELECT * FROM phpcms_member WHERE username=’$_username’ AND catid=$catid;

特殊文字がエスケープされずにデータベースに挿入される場合のエラーを避けるために、すべてのデータはデータベースに挿入される前にaddslashes()で処理される必要があります。ファイル common.inc.php が phpcms に導入されている場合、GET、POST、および FILE によって取得されたすべての変数は、デフォルトで addslashes() を使用してエスケープされているため、繰り返す必要はありません。データ処理が必要な場合 (直接表示など)、stripslashes() を使用して復元できますが、データはデータベースに挿入する前に再度エスケープする必要があります。
キャッシュ ファイルでは、通常、キャッシュされたデータの値をエスケープするために addcslashes($string, ''\') が使用されます。

4.3.6.

4.4. 命名原則
ネーミングは番組企画の中心です。古代人は、人の本当の名前を知ると、その人に対して信じられないほどの力が与えられると信じていました。物事に適切な名前を考えている限り、それはあなたとあなたの後に続く人たちに、コードよりも大きな力を与えるでしょう。

名前は、その生態学的環境における物事の長期にわたる広範囲にわたる結果です。一般に、システムを理解しているプログラマだけが、システムに最も適切な名前を思いつくことができます。すべての名前が自然に適切であれば、関係は明確であり、意味を推測することができ、一般の人々の推論が期待できます。

一般的な規則として、コードの読者がコードの動作を簡単に理解できるように、クラス、関数、変数の名前は常にわかりやすいものにする必要があります。形式が単純で規則的であればあるほど、認識され、理解されやすくなります。あいまいであいまいな非標準的な名前は避けるべきです。

4.4.1. 変数、オブジェクト、関数名
変数、オブジェクト、関数の名前は小文字にする必要があります。必要な場合を除き、通常、単語の区切りにはアンダースコア "_" を使用しません。 標準的なコンピュータ英語に基づいて、ピンインまたはピンインと英語が混在したすべての命名方法が排除されています。 変数の名前付けには、プロジェクト内で十分に文書化された英語の略語のみを使用できます。たとえば、$data1、$data2 は混同されやすいため、明確でわかりやすい $data1、$userdata の代わりに使用できます。 、
を使用する必要があります。 英語の略語形式が存在するか、文字が英語の略語仕様に準拠している場合は、$bio($biography)、$tpp($threadsPerPage) など、長すぎる名前を合理的に省略できます。 使用される英単語の品詞を知る必要があります。権威に関係する範囲では、$enable*** と $is*** の形式がよく使用されます。前者には動詞が続きます。後者には形容詞が続きます。

4.4.2. 定数

定数は常にすべて大文字で名前を付ける必要があります。いくつかの特殊なケースでは、単語を区切るためにダッシュを使用できます。 PHP の組み込み値 TRUE、FALSE、NULL はすべて大文字で記述する必要があります。

4.5. 変数の初期化と論理チェック
すべての変数は、蓄積、直接表示、または保存する前に初期化する必要があります。例:
$number = 0; //数値の初期化
$string = ''; //文字列の初期化

$array = array() //配列の初期化

決定できない（代入されているかどうかが不明な）変数を判断する場合、これが確実にわかっている場合を除き、if($switch) を直接使用する代わりに empty() または isset() を使用できます。変数を初期化して値を割り当てておく必要があります。
empty() と isset() の違いは次のとおりです:
l bool empty(混合変数)
n var が空またはゼロ以外の値の場合、empty() は FALSE を返します。つまり、""、0、"0"、NULL、FALSE、array()、var $var;、およびプロパティを持たないオブジェクトは空とみなされ、var が空の場合は TRUE が返されます。
l bool isset(混合 var[, 混合 var[, ...]])
n var が存在する場合は TRUE を返し、そうでない場合は FALSE を返します。
n unset() を使用して変数が解放された場合、その変数は isset() ではなくなります。 isset() を使用して NULL に設定された変数をテストすると、FALSE が返されます。 NULL バイト (" 変数が配列であるかどうかを判断するには、is_array() を使用してください。この判断は、foreach() などの配列を横断する操作に特に適しています。これは、事前に判断されないと、foreach() が非配列の場合にエラーを報告するためです。 -配列型変数;
配列要素が存在するかどうかを確認するには、isset($array[‘key’]) または empty() を使用します。この 2 つの類似点と相違点を確認してください。

4.6. セキュリティ

PHP の変数は、C 言語のように事前に宣言する必要がなく、初めて使用するときにインタープリターが自動的に作成します。同様に、インタープリターがコンテキストに基づいて自動的に変数を決定します。開発者の観点から見ると、これは間違いなく非常に便利なアプローチです。変数を作成したら、プログラム内のどこでも使用できます。この結果、開発者は変数の初期化に注意を払わないことがよくあります。したがって、プログラムのセキュリティを向上させるために、明確に定義されていない変数は信頼できません。悪意のある構成体によって送信された変数がプログラムで使用されている変数を上書きするのを防ぐために、すべての変数は定義して使用する前に初期化する必要があります。
詳細については、このドキュメント (http://www.securereality.com.au/studyinscarlet.txt) を参照してください。このドキュメントには、PHP の一般的なセキュリティ問題がリストされています。

4.7.互換性

コード設計では、PHP の上位バージョンと下位バージョンの両方の特性を考慮する必要があります。現時点では、PHP 4.3.0 を最低パス プラットフォームとして使用し、上位バージョンの PHP では新しい関数、定数、または定数を使用しないようにする必要があります。上位バージョンでのみ使用できる関数を使用する場合は、それを 2 回カプセル化し、現在の PHP バージョンを自動的に判断し、下位バージョンと互換性のあるコードを作成する必要があります。 個々の関数については、パラメーター要件またはコード要件は、より厳格な PHP バージョンに従う必要があります。 必要な場合を除き、PHP 拡張モジュールの関数を使用しないでください。ご利用の際は必要な判断を加え、サーバ環境が本機能をサポートしていない場合には必要な処理を行ってください。互換性に関する記述は、ドキュメントやプログラムの機能説明にも含める必要があります。

4.8. コードの再利用
コードを効果的に再利用すると、効率の低下とリソースの無駄を削減できます。ソフトウェア プロジェクトを開発する際の労力の重複と時間の無駄を避けるため。開発者は、既存のコードの再利用率を高めるように努めると同時に、新しいテクノロジーの適用や新しい機能の革新的な開発により多くのエネルギーを費やす必要があります。

l コードを複数回使用する必要があり、実現したいタスクに使用できる組み込みの PHP 関数がない場合は、ためらわずに関数またはクラスを定義します。開発者は、関数と呼び出し条件に基づいて関数を include ディレクトリに配置し、関数ファイルの接尾辞として .func.php を使用し、クラスを include/class ディレクトリに配置する必要があります。 3 行を超える同じ機能を実装するプログラムは、別のプログラム内で複数回使用することはできません。これは許容できない問題です。

l たとえ異なるプログラムであっても、同じプログラム内に 2 つ以上の類似または同一のコードが出現しないようにしてください。開発者は、コードの大きなセクション (10 行以上) や同様の状況の重複を避ける方法を常に見つけられる必要があります。
この部分は短いですが、多くの経験を必要とする部分であり、開発者が最適化するには多大な時間と労力を費やすことになるため、製品開発者は常にコードの重要性と必要性​​を明確に理解する必要があることを強調する必要があります。これは、優れたソフトウェア開発者が備えなければならない基本的な資質です。

4.9. その他の詳細

4.9.1. 通話を含む
呼び出し元のプログラム ファイルを含めるには、重複して含める問題を回避するために、すべてに require_once を使用してください。 呼び出しキャッシュ ファイルをインクルードする キャッシュ ファイルは 100% 正しく開かれることを保証できないため、include_once または include を使用してください。必要に応じて、@include_once または @include を使用してエラー プロンプトを無視できます。 インクルードおよび呼び出しコードは PHPCMS_ROOT.'/' で始まる必要があり、プログラム ファイル名を直接記述することは避けてください (例: require_once ‘x.php’;)。 プログラム、キャッシュ、またはテンプレートを含むがこれらに限定されない、含まれるプログラム ファイルおよび呼び出されるすべてのプログラム ファイルは、通常、直接 URL によってリクエストすることはできません。 phpcms は、./include/common.inc.php でマーク付き定数 IN_PHPCMS を定義することによって、プログラムが正当に呼び出されたかどうかを判断します。したがって、./include/common.inc.php を除き、組み込まれて呼び出されるプログラム ファイルには、訪問者が URL を通じてファイルを直接リクエストできないように、次のコンテンツを含める必要があります:
定義済み('IN_PHPCMS') または exit('アクセス拒否');

4.9.2. エラー報告レベル
ソフトウェア開発およびデバッグ段階では、error_reporting(E_ALL) をデフォルトのエラー報告レベルとして使用してください。このレベルは最も厳格で、開発者がコードをチェックおよび検証して回避できるように、プログラム内のすべてのエラー、警告、およびプロンプトを報告できます。重大な事故、ほとんどのセキュリティ問題、論理エラー、スペルミス。 error_reporting() は ./include/common.inc.php の最初の数行で設定できます。

ソフトウェアをリリースするときは、ユーザーが使いやすくし、不要なエラー プロンプトを最小限に抑えるために、デフォルトのエラー レポート レベルとして error_reporting(E_ERROR E_WARNING E_PARSE) を使用してください。

5. データベース設計
5.1.フィールド
5.1.1. テーブルとフィールドの名前付け
テーブルやフィールドの命名は、前述の「4.4 命名原則」の規約を基本とします。
すべてのデータ テーブル名は、名前が可算名詞である限り、複数形で命名する必要があります。たとえば、 phpcms_member (ユーザー テーブル) 複数の内容を格納するフィールド、または数量を表すフィールドも複数形で命名する必要があります。例: ヒット数 (閲覧数)、アイテム数 (コンテンツ数)。
複数のテーブル間のフィールドが関連している場合、phpcms_article_1 テーブルのarticleidとphpcms_article_data_1テーブルのarticleidなど、テーブル間で関連するフィールドの名前の統一に注意する必要があります。
ID の自己インクリメントを表すフィールドは通常、次の形式を使用します:
l 通常は、userid、articleid
などの完全な形式を使用します。 l 機能的な役割を持たず、管理とメンテナンスの便宜のみを目的とした ID は、フルネームまたは名前付き ID の形式で使用できます。
紙面の都合上、一つ一つ詳しく説明することはできませんが、テーブルやフィールドに関連するすべての命名については、命名の体系性と統一性を確保するために、phpcms の既存フィールドの命名方法を必ず参照してください。
5.1.2. フィールド構造
NULL 値を許可するフィールドの場合、データベースは比較操作を実行するときに、まず NULL かどうかを判断し、NULL でない場合にのみ値が照合されます。したがって、効率性を考慮して、すべてのフィールドを空にすることはできません。つまり、すべての
を空にすることはできません。 項目 ID や投稿数など、負ではない数値を格納することが想定されていないフィールドは、UNSIGNED タイプに設定する必要があります。 UNSIGNED 型は、非 UNSIGNED 型よりも 2 倍の範囲の正の整数を格納できるため、より大きな数値記憶領域を取得できます。 スイッチおよびオプション データを格納するフィールドは、通常、tinyint(1) 非 UNSIGNED 型を使用します。場合によっては、enum() 結果セットも使用される場合があります。 tinyint がスイッチフィールドとして使用される場合、通常は 1 がオン、0 がオフ、-1 より大きい値は特殊な結果または 2 進数の組み合わせです。詳細については phpcms のコード) ;
MEMORY/HEAP タイプのテーブルの場合は、記憶域スペースを節約する計画に特別な注意を払う必要があります。これにより、より多くのメモリが節約されます。たとえば、cdb_sessions テーブルでは、IP アドレス ストレージは char(15) ではなく 4 つの tinyint(3) UNSIGNED タイプのフィールドに分割されます。 どのタイプのデータ テーブルでも、フィールド領域は十分であり、無駄にならないようにする必要があります。数値フィールドの値の範囲を次の表に示します。 フィールドタイプ 記憶領域 (b) UNSIGNED 値の範囲
tinyint 1 いいえ -128~127
はい 0~255
smallint 2 いいえ -32768~32767
はい 0~65535
Mediumint 3 いいえ -8388608~8388607
はい 0~16777215
int 4 いいえ -2147483648~2147483647
はい 0~4294967295
bigint 8 いいえ -9223372036854775808
~9223372036854775807
はい 0
~18446744073709551615

5.2.SQL ステートメント
テーブル名とフィールド名を除くすべての SQL ステートメントでは、すべてのステートメントと関数を大文字で記述するか、大文字と小文字を混合して記述することは避けてください。たとえば、select * from phpcms_member; は非標準の記述方法です。
非常に長い SQL ステートメントには適切な改行が必要であり、JOIN、FROM、ORDER BY などのキーワードに基づいて定義する必要があります。
通常、複数のテーブルを操作する場合、ステートメントを簡素化し読みやすくするために、異なるテーブル名に基づいて各テーブルに 1 ～ 2 文字の略語を割り当てる必要があります。
以下の文例は規格に準拠しています:

$result = $db->query(”SELECT m.*, i.*

FROM「.TABLE_MEMBER.」m、「.TABLE_MEMBERINFO.」 WHERE m.userid=i.userid AND m.userid=’$_userid’);

5.3. パフォーマンスと効率
5.3.1. 固定長テーブルと可変長テーブル
varchar や text などの可変長フィールドを含むデータ テーブルは可変長テーブルであり、その逆は固定長テーブルです。
l 可変長テーブルの場合、多数の削除や変更を行うと、レコード サイズの違いによりテーブルの断片化がさらに進みます。パフォーマンスを維持するには、OPTIMIZE TABLE を定期的に実行する必要があります。固定長テーブルにはこの問題はありません。
l テーブルに可変長フィールドがある場合、固定長フィールドに変換すると、固定長レコードの方が処理しやすいため、パフォーマンスが向上します。ただし、そうする前に、次のことを考慮する必要があります:
l 固定長列の使用には、いくつかのトレードオフが伴います。それらは高速ですが、より多くのスペースを必要とします。 char(n) 型の列の各値は、テーブルに格納されるときに、値が十分な長さでない場合は右側にスペースが埋め込まれるため (空の文字列であっても)、常に n バイトを占めます。 l varchar(n) タイプの列は、各値を格納するために必要なスペースのみが割り当てられ、各値に 1 バイトを加えたものがその長さの記録に使用されるため、占有スペースが少なくなります。したがって、char 型と varchar 型のどちらかを選択する場合は、時間と空間の間でトレードオフを行う必要があります。
l 可変長テーブルを固定長テーブルに変換する場合、1 つの可変長フィールドだけを変換することはできず、すべての可変長フィールドを変換する必要があります。すべてを同時に変換するには、ALTER TABLE ステートメントを使用する必要があります。そうしないと、変換が機能しません。
l 固定長型を使用したくても使用できない場合があります。たとえば、255 文字を超える文字列の場合、固定長タイプはありません。 l テーブル構造を設計する際、固定長データ型を使用できる場合は、固定長データ型を使用するようにしてください。これは、固定長テーブルのクエリ、取得、および更新の速度が非常に速いためです。必要に応じて、頻繁にアクセスされるいくつかのキー テーブル (固定長データ用の 1 つのテーブルと非固定長データ用の別のテーブルなど) を分割できます。たとえば、phpcms の phpcms_member テーブルなどです。したがって、データ構造を計画するときは、全体的な考慮事項を考慮する必要があります
。 テーブル構造を設計するときは、最適なデータ ストレージ システムを実現するために、適切かつ慎重に考慮する必要があります。
5.3.2. 操作と取得
一般に、数値操作は文字列操作よりも高速です。たとえば、比較演算では、1 回の演算で数値を比較できます。文字列操作には、バイトごとの比較がいくつか含まれます (文字列が長い場合はさらに多くなります)。
シーケンス内の値の数が制限されている場合は、数値演算の利点を得るために通常の整数型またはエミュム型を使用する必要があります。
小さいフィールド タイプは常に、大きいフィールド タイプよりもはるかに高速に処理されます。文字列の場合、処理時間は文字列の長さに直接関係します。一般に、テーブルが小さいほど処理が速くなります。固定長テーブルの場合は、必要な範囲の値を格納できる最小のタイプを選択する必要があります。たとえば、mediumint で十分な場合は、bigint を選択しないでください。可変長タイプの場合でも、スペースを節約できます。 TEXT 型の値は値の長さを記録するのに 2 バイトを使用しますが、LONGTEXT は値の長さを記録するのに 4 バイトを使用します。保存される値の長さが 64KB を超えない場合、TEXT を使用すると値ごとに 2 バイトが節約されます。
5.3.3. 構造の最適化とインデックスの最適化
インデックスはクエリを高速化することができ、インデックスの最適化とクエリの最適化は相互に補完的です。インデックスはクエリに基づいて最適化することも、既存のインデックスに基づいて最適化することもできます。これは、クエリまたはインデックスの変更によって異なります。どちらが既存の製品アーキテクチャに適しており、効率への影響が最小限に抑えられます。
インデックスの最適化とクエリの最適化は長年の経験の結果であり、ここで詳しく説明することはできませんが、いくつかの基本的なガイドラインが示されています。
まず、実際の製品の操作やアクセスに基づいて、どの SQL 文が最も頻繁に実行されるかを調べます。最も一般的に実行されるものと、プログラム内で最も一般的に使用されるものは、まったく異なる概念です。最も一般的に実行される SQL ステートメントは、大きなテーブル (データ エントリが多い) と小さなテーブル (データ エントリが少ない) に対する操作に分けることができます。テーブルが大きいか小さいかに関係なく、操作は、読み取り (SELECT) が多い操作、書き込み (UPDATE/INSERT) が多い操作、または読み取りと書き込みの両方が多い操作に分類できます。
頻繁に実行される SQL ステートメントでは、大規模なテーブル操作に特別な注意を払う必要があります:
l 書き込み操作が多数ある場合は、通常、書き込みキャッシュ方式を使用して、ファイルまたは他のテーブルに書き込むか更新する必要があるデータをキャッシュし、大きなテーブルに対して定期的にバッチ書き込み操作を実行します。同時に、元の構造の大きなテーブルが固定長でない場合でも、頻繁に読み書きされる大きなテーブルを固定長型にするように努める必要があります。固定長の大きなテーブルは、データ ストレージ構造とデータ読み取り方法を変更し、大きなテーブルをより多くの読み取りと書き込みを行う固定長テーブルと、より多くの読み取りとより少ない書き込みを行う可変長テーブルに分割することで実現できます。 > l 読み取り操作が多い場合は、SQL クエリの頻度に基づいて、頻度の高い SQL ステートメント専用のインデックスとジョイント インデックスを設定する必要があります。
小さなテーブルは比較的単純で、クエリ要件を満たす特定のインデックスを追加すると、通常は明らかな効果が得られます。同時に、小型の固定長テーブルは、効率と負荷容量の向上にも役立ちます。フィールドが比較的少ない小さな固定長テーブルには、インデックスが必要ない場合もあります。
次に、SQL ステートメントの条件と並べ替えフィールドが非常に動的であるかどうかを確認します (つまり、SQL クエリ条件と並べ替えフィールドは、さまざまな関数スイッチや属性に応じて大きく変化します)。動的すぎる SQL ステートメントはインデックスを介して処理できません。最適化されました。唯一の方法は、データをキャッシュして定期的に更新することです。これは、結果に高い効果が必要ない状況に適しています。
MySQL インデックスには、PRIMARY KEY、INDEX、UNIQUE などがあります。詳細については、MySQL のドキュメントを参照してください。一般に、単一テーブル内のデータ値が重複しない場合は、INDEXよりもPRIMARY KEYやUNIQUEインデックスの方が高速ですので、適宜使用してください。
実際、インデックスは、条件付きクエリの読み取り操作と書き込み操作へのソートのリソース消費を分散します。インデックスの数が増えると、消費されるディスク領域が大きくなり、書き込み操作が遅くなります。したがって、インデックスをやみくもに追加しないでください。フィールドにインデックスが付けられているかどうかに関係なく、最も基本的な出発点はやはり SQL ステートメントの実行確率、テーブルのサイズ、書き込み操作の頻度です。
5.3.4. クエリの最適化
MySQL にはクエリ条件の最適化機能が用意されていないため、開発者はプログラム内のクエリ条件の順序を手動で最適化する必要があります。たとえば、次の SQL ステートメント:
SELECT * FROM table WHERE a>’0’ AND b

実際、a>'0' または b 開発者はこの原則を念頭に置く必要があります。最初に表示される条件は、より多くの結果をフィルタリングして除外する条件でなければなりません。2 番目に表示される条件は 2 番目に配置されます。したがって、テーブル内のさまざまなフィールドの値の分布は、クエリの速度に大きな影響を与えます。 ORDER BY の条件はインデックスにのみ関連し、条件の順序とは関係ありません。
条件付きシーケンスの最適化に加えて、固定または比較的固定された SQL クエリ ステートメントのインデックス構造を最適化して、非常に高いクエリ速度を実現することもできます。原則として、ほとんどの場合、WHERE 条件の順序と ORDER BY ソート フィールドの順序に基づいて確立された結合インデックスが、この SQL ステートメントに一致する最適なインデックス構造になります。ただし、実際には、製品内で 1 つの SQL ステートメントのみを考慮することはできません。また、占有スペースを考慮せずに多数のインデックスを作成することもできません。
上記の SQL ステートメントを例にとると、最適なテーブル テーブルのレコードが数百万、さらには数千万に達すると、インデックスの最適化によって速度が向上することがはっきりとわかります。
上記の条件最適化とインデックス最適化の 2 つの原則に基づいて、テーブル table の値が次の解である場合、最適な条件シーケンス解を取得できます。 フィールドa フィールドb フィールドc
1 7 11
2 8 10
3 9 13
-1 0 12
最適条件: b'0'
最適なインデックス: INDEX abc (b, a, c)
理由: 最初の条件として b 注 1: フィールド c は条件に出現しないため、条件順序の最適化は関係ありません
注 2: 最適なインデックスは、例の SQL 文ではなく、最適な条件列によって取得されます
注 3: インデックスはデータ ストレージの物理的な順序を変更しませんが、特定のオフセットに対応する物理データによって実装される仮想ポインターです

EXPLAIN ステートメントは、インデックスとクエリがよく一致するかどうかをテストする便利な方法です。 phpMyAdmin または他の MySQL クライアントで EXPLAIN+ クエリ ステートメントを実行します (EXPLAIN select * FROM table WHERE a>'0' AND b<'1' ORDER BY c;)。この形式は、開発者が数百万のデータをシミュレートする必要がないことを意味します。また、インデックスが適切かどうかも確認してください。関連する詳細については、MySQL の手順を参照してください。

ファイルソートの使用は、発生してはならない最後の状況であることに注意してください。EXPLAIN の結果がこの結果になった場合、データベースは結果をキャッシュするためにこのクエリ用に特別に一時テーブル ファイルを作成し、クエリの実行後にそれを削除したことを意味します。完成しました。ご存知のとおり、ハードディスクの I/O 速度は常にコンピュータ ストレージのボトルネックとなるため、クエリでの実行頻度が高い SQL ステートメントにはファイルソートを使用しないようにあらゆる努力を払う必要があります。ただし、開発者は、製品内のすべての SQL ステートメントで filesort が使用されないことを保証することはできません。
スペースの制限のため、このドキュメントでは、ジョイント インデックスと通常のインデックスの再利用性、JOIN 接続のインデックス設計、MEMORY/HEAP テーブルなど、データベースの最適化のすべての側面を網羅しているわけではありません。データベースの最適化は、実際には、多くの要素とメリットとデメリットを常に考慮して変更することであり、成功と失敗の経験を繰り返し精査することによってのみ得られます。この経験は、多くの場合、最も貴重で貴重なものとなります。
5.3.5. 互換性の問題
MySQL 3.23 から 5.0 では大幅に変更されているため、互換性の問題やデータベース移植の困難を避けるために、プログラム内で特別な SQL ステートメントを使用しないようにしてください。
通常、MySQL 4.1 以降では、phpcms は GBK/BIG5/UTF-8 などの対応する文字セットを使用して保存する必要があります。従来の latin1 エンコーディングには一定の互換性がありますが、それでも推奨される選択肢ではありません。対応するデフォルト以外の文字セットを使用する場合は、プログラムを実行するたびに SET NAMES 'character_set' を使用して、接続、送信、および結果の文字セットを指定する必要があります。
Mysql 5.0 以降では、いくつかの新しい SQL_MODE が追加されています。デフォルトの SQL_MODE はサーバーのインストール設定によって異なります。そのため、プログラムを実行するたびに SET SQL_MODE=''; を使用して現在の SQL モードを指定する必要があります。
6. テンプレートデザイン
6.1. コードタグ
HTML コードのタグは常に小文字である必要があり、大文字の使用は禁止されています

テンプレート内のすべての論理エンティティ ({if}、{loop} など) の前後には HTML コメント () を付ける必要があります。つまり、< と同様です。 !--{if expr}-- > 形式。実際、phpcms テンプレート コンパイラは HTML コメントを使用しない論理的な記述をサポートしていますが、コメントを追加するとテンプレートが読みやすくなり、ユーザーが DreamWeaver や FrontPage を使用してテンプレートを変更しやすくなります。
6.2. 書き方のルール
6.2.1. HTML
すべての HTML タグパラメータの割り当ては二重引用符で囲む必要があります。たとえば、

を使用する必要があります。

は絶対に使用できません

<入力タイプ=テキスト名=テスト値=ok>
。
いずれの場合も、製品内のテンプレート ファイルは手書きの HTML コードで記述する必要があり、DreamWeaver や FrontPage などの自動 Web ページ作成ツールを使用して記述したり変更したりしてはなりません。
6.2.2. 変数
テンプレートで使用される変数は、その機能と出現位置に応じていくつかの方法に分けられます。
l 論理本体、つまりこの形式のような囲まれた部分では、変数の書き込み仕様は PHP プログラムの仕様と完全に一致しています。 開発者は、テンプレートのコンパイル エラーを回避するために、{} を使用して変数を囲む必要があります。考えられる状況は次のとおりです。
l 変数の前後に角括弧またはその他の機密文字 (「$」、「'」などを含むがこれらに限定されない) がある場合、正しい記述方法は descriptionnew[{$buddy[buddyid]}]; です。 🎜> l 配列の添字は変数であり、正しい書き方は {$extcredits[$creditstrans][title]};
です。 l 他の変数は非常に複雑です。
6.2.3. 言語要素
6.2.4. インデント
phpcms の *.html テンプレート ファイルでは、その論理構造により、HTML 自体のインデントはすべて考慮されません。インデントはTAB方式を採用しており、インデント記号としてスペースは使用せず、適切な改行のみを必要とします。例:

{$article['title']}


7. ファイルとディレクトリ
7.1. ファイルの名前付け
PHP コードを含むすべてのプログラム ファイルまたは半プログラム ファイルでは、拡張子として .phtml、.php3、.inc、.class などではなく、小文字の .php を使用する必要があります。
通常プログラム
list.phpやindex.phpなど、URLで直接呼び出せるプログラムは、プログラム名+.php
で直接名前が付けられます。 関数ライブラリとクラス ライブラリ プログラム
拡張子としてそれぞれ小文字の .func.php と .class.php を使用します。関数ライブラリとクラス ライブラリ プログラムは、他のプログラムからのみ参照でき、独立して実行することはできません。関数またはクラスに属さない手続き型コードを含めることはできません。
処理手順
拡張子として小文字の .inc.php を使用します。他のプログラムからのみ参照でき、独立して実行することはできません。関数のプログラム コードやクラス コードを含めることはできません。
テンプレートソースファイル
拡張子として小文字の .html を使用します。テンプレートのソース ファイルは、phpcms テンプレートのエンコード規則に従って作成されます。これは実行可能プログラムではありませんが、phpcms テンプレート コンパイラによってのみ解析され、./templates/default または ./templates の下の他のテンプレート ディレクトリに配置されます。
テンプレートオブジェクトファイル
テンプレート ファイルのコンパイル後に自動生成されるターゲット プログラムは、拡張子が小文字の .php で、./data/templates ディレクトリに保存されます。
言語パック ファイル
拡張子として小文字の .lang.php を使用すると、テンプレートまたはプログラムで使用される言語パック情報のみを保存できます。
キャッシュ ファイル
このようなファイルはシステムによって自動的に生成され、cache_xxx.php、usergroup_xxx.php、style_xxx.php などのような形式で名前が付けられ、./data/cache ディレクトリに保存されます。
7.2. ディレクトリの名前付け
phpcmsディレクトリの命名は、基本的なガイドラインとして前述の「4.4 命名原則」の取り決めに基づいています。可能な場合は、./templates、./image などの複数形で表示されます。
ディレクトリの数が少ないため、ディレクトリの命名は主に習慣と慣例に基づいて行われます。開発者が新しいディレクトリを作成する必要がある場合は、実装前にプロジェクト チームのメンバーと相談し、合意に達する必要があります。
7.3. 空のディレクトリインデックス
通常のプログラム（URLで直接呼び出せるプログラム）を含まないディレクトリに、スペースを入れた1バイトのindex.htmファイルを配置してください。 phpcms ルート ディレクトリを除くほとんどすべてのディレクトリがこのタイプに属するため、開発者は、http サーバーのディレクトリ一覧表示がオンになっているときにサーバー ファイルがインデックス付けされて一覧表示されないように、これらすべてのディレクトリに空のindex.htm ファイルを配置する必要があります。
添付ファイル ディレクトリなどの機密性の高いディレクトリは、プログラム内で対応する機能を実装する必要があります。新しい下位レベルのディレクトリを作成するときは、新しいディレクトリにインデックスが作成される問題を回避するために、空のindex.htm ファイルを自動的に書き込む必要があります。