mysqlをベースにしたBBSデザイン (2)

3.データベース設計
重要なのは、mysql の効率、mysql メモリの適切な割り当て、特にテーブル キャッシュの
サイズです。さらに、システムの電源が突然失われるとどうなりますか? mysqlは堅牢ですか?
テーブルの名前は、タイプを示すプレフィックスを使用するように設計されており、すべて小文字 (?) で表されます。例:
ユーザー テーブルのように、システムのデータベースの前に s が付きます: suser (sUSER はどこですか?)、次のようになります:
s: システム テーブル、suser、sclass
m: ユーザー メール テーブル、msysop、mdrangon
w: ユーザー メッセージ テーブル、wsysop、wdrangon
a:レイアウトインデックステーブル、alinux、acampus
b: レイアウト記事テーブル、blinux、bcampus
c: 特殊分類レイアウトテーブル、cnewboard
i: エッセンスエリアインデックステーブル、ilinux、ilinux01、icampus、icampus04
j: エッセンス領域記事テーブル、jlinux、jcampus、

また、識別子として文字列と数字を使用する必要がありますか?たとえば、sysop という名前のアカウントの
id は 1 です。彼の文字のテーブルは msysop ですか、それとも m00001 ですか?同様に、campus というバージョンの場合、対応する
コードは 5 です。つまり、このバージョンの記事のテーブル名は bcampus ですか、それとも b00005 ですか?文字列を使用すると
が理解しやすいかもしれません。エラーを確認してみましょう。

ユーザー情報テーブル: suser
usernum int unique, // 一意の識別子、最大 30,000 アカウントですが、少なすぎますか?
userid char[20] 主キー、// ソートキー、ID、すべて小文字。
passwd char[20], // パスワードは、暗号化された暗号文を保存します。
realid char[20], //実際の ID、大文字と小文字の混合。
username char[24], // ユーザー名
userlevel longint, // 64 種類の権限?
numlogins int,
numposts int,
firstlogin time,
lastlogin time,
Staytime time, /* 合計滞在時間*/
lasthost char[32],
email varchar[100],
address varchar[100],
// 他のデータが必要ですか?将来テーブルを変更できるように、特定の予約値を確保しておく必要がありますか?
// 新しいフィールドを追加するときの効率はどれくらいですか?

レイアウト分類テーブル: sclass
classnum int unique, // 分類識別子
classid char[20], // 分類英語 ID:computer
classname varchar[100],// 中国語カテゴリの説明: Computer World
classtable char[20], // 特別なカテゴリに対応するページテーブル
// 一般に、最初のような特別なカテゴリの場合、各ページは 1 つのカテゴリにのみ属します。 Section,
// 新しいレイアウトは特別なテーブルで記述できます

レイアウト テーブル: sboard
boardnum int unique, // レイアウトの識別 (必要ですか?)
boardid char [20], // ボードの英語名
boardname varchar[100], // ボードの中国語名
boardclass char[20], // ボードが属するカテゴリ
boardsysop varchar[100], // Bamboo list
boardposts int, // ボード内の記事数
boardlevel int, // ボードの読み取りおよび書き込み権限
Indextable char[20], // ボードに対応するインデックス テーブルの名前: aboardid?
texttable char[20], //レイアウトに対応する記事テーブル名: bboardid?
// 最後の 2 つの項目は必要ですか? それらは必然的な対応関係と見なすことができますか? それとも
// より柔軟に対応できるようにする必要がありますか?さらに、レイアウトの大文字化の問題を直接デフォルトにできますか?
// 最初の文字のみが大文字になります。

特別なカテゴリのレイアウト テーブル: snewboard, sstarboard
boardid char[20], / / レイアウトの ID
// そのようなテーブルは必要ですか?

レイアウト インデックス テーブル: acampus、alinux、afootball。 。 。 。 。 。
id int, // 記事番号、手動で調整しますか? ? ? ?
mark char[1], // 記事マーク、m、g、b、d。 。 。 。
title varchar[100], // 記事タイトル
Writer char[20], // 記事著者 ID
posttime time, // 公開時刻
textnum longint, // 対応する番号? ? ?調整なし

レイアウト記事表
textnum longint, // 記事番号?
textword text, // 記事の内容?
// インデックスと記事コンテンツを分離する必要がありますか?効率の観点から、遅延フラッシュ
// は避けられません。削除するには、最初にマークを付けます。

// ユーザーページの未読記事には未読データがたくさんありますか? これを実現するには、多数のテーブル
// を構築する必要がありますか?
// 投票関数はまだ考慮されていません。 。 。 。