<span class="unnamed3">3.データベース設計 <br> 重要なのは、mysql の効率、mysql メモリの適切な割り当て、特にテーブル キャッシュの <br> サイズです。さらに、システムの電源が突然失われるとどうなりますか? mysqlは堅牢ですか? <br> テーブルの名前は、タイプを示すプレフィックスを使用するように設計されており、すべて小文字 (?) で表されます。例: <br> ユーザー テーブルのように、システムのデータベースの前に s が付きます: suser (sUSER はどこですか?)、次のようになります: <br> s: システム テーブル、suser、sclass <br> m: ユーザー メール テーブル、msysop、mdrangon <br> w: ユーザー メッセージ テーブル、wsysop、wdrangon <br> a:レイアウトインデックステーブル、alinux、acampus <br> b: レイアウト記事テーブル、blinux、bcampus <br> c: 特殊分類レイアウトテーブル、cnewboard <br> i: エッセンスエリアインデックステーブル、ilinux、ilinux01、icampus、icampus04 <br> j: エッセンス領域記事テーブル、jlinux、jcampus、<br><br> また、識別子として文字列と数字を使用する必要がありますか?たとえば、sysop という名前のアカウントの <br>id は 1 です。彼の文字のテーブルは msysop ですか、それとも m00001 ですか?同様に、campus というバージョンの場合、対応する <br> コードは 5 です。つまり、このバージョンの記事のテーブル名は bcampus ですか、それとも b00005 ですか?文字列を使用すると <br> が理解しやすいかもしれません。エラーを確認してみましょう。 <br><br> ユーザー情報テーブル: suser <br> usernum int unique, // 一意の識別子、最大 30,000 アカウントですが、少なすぎますか? <br> userid char[20] 主キー、// ソートキー、ID、すべて小文字。 <br> passwd char[20], // パスワードは、暗号化された暗号文を保存します。 <br> realid char[20], //実際の ID、大文字と小文字の混合。 <br> username char[24], // ユーザー名 <br> userlevel longint, // 64 種類の権限? <br> numlogins int, <br> numposts int, <br> firstlogin time, <br> lastlogin time, <br> Staytime time, /* 合計滞在時間*/ <br> lasthost char[32], <br> email varchar[100], <br> address varchar[100], <br> // 他のデータが必要ですか?将来テーブルを変更できるように、特定の予約値を確保しておく必要がありますか? <br> // 新しいフィールドを追加するときの効率はどれくらいですか? <br><br> レイアウト分類テーブル: sclass <br> classnum int unique, // 分類識別子 <br> classid char[20], // 分類英語 ID:computer <br> classname varchar[100],// 中国語カテゴリの説明: Computer World <br> classtable char[20], // 特別なカテゴリに対応するページテーブル <br> // 一般に、最初のような特別なカテゴリの場合、各ページは 1 つのカテゴリにのみ属します。 Section, <br> // 新しいレイアウトは特別なテーブルで記述できます <br><br> レイアウト テーブル: sboard <br> boardnum int unique, // レイアウトの識別 (必要ですか?) <br> boardid char [20], // ボードの英語名 <br> boardname varchar[100], // ボードの中国語名 <br> boardclass char[20], // ボードが属するカテゴリ <br> boardsysop varchar[100], // Bamboo list<br> boardposts int, // ボード内の記事数 <br> boardlevel int, // ボードの読み取りおよび書き込み権限 <br> Indextable char[20], // ボードに対応するインデックス テーブルの名前: aboardid? <br> texttable char[20], //レイアウトに対応する記事テーブル名: bboardid? <br> // 最後の 2 つの項目は必要ですか? それらは必然的な対応関係と見なすことができますか? それとも <br> // より柔軟に対応できるようにする必要がありますか?さらに、レイアウトの大文字化の問題を直接デフォルトにできますか? <br> // 最初の文字のみが大文字になります。<br><br> 特別なカテゴリのレイアウト テーブル: snewboard, sstarboard <br> boardid char[20], / / レイアウトの ID <br> // そのようなテーブルは必要ですか? <br><br> レイアウト インデックス テーブル: acampus、alinux、afootball。 。 。 。 。 。 <br> id int, // 記事番号、手動で調整しますか? ? ? ? <br> mark char[1], // 記事マーク、m、g、b、d。 。 。 。 <br> title varchar[100], // 記事タイトル <br> Writer char[20], // 記事著者 ID <br> posttime time, // 公開時刻 <br> textnum longint, // 対応する番号? ? ?調整なし <br><br> レイアウト記事表 <br>textnum longint, // 記事番号? <br> textword text, // 記事の内容? <br> // インデックスと記事コンテンツを分離する必要がありますか?効率の観点から、遅延フラッシュ <br> // は避けられません。削除するには、最初にマークを付けます。 <br><br> // ユーザーページの未読記事には未読データがたくさんありますか? これを実現するには、多数のテーブル <br> // を構築する必要がありますか? <br> // 投票関数はまだ考慮されていません。 。 。 。 <br></span> <p style="width:100%;text-align:center;margin:10px 0"> <br> <br> </p> <p style="width:100%;text-align:center;margin:10px 0"> </p> <p class="clear"></p>