プロジェクトの開発プロセス
BBSテーブルには、プロジェクトの開発に見えるように設計する前に、
プロジェクト開発のプロセスは、以下のものが含まれます
1.需要分析
建築家+ +開発チームのリーダー、プロダクトマネージャー
、このプロジェクトを進めるために、クライアント企業のニーズについて話をしに行く前に行う方法を数える必要がある
点を先行し、比較的簡単な解決策を考えるためのピット内
の顧客と話をしてあなた方の意識のガイドの顧客はすでに良いプログラムのニーズを設置したいとき
2.プロジェクトデザイン
ライブやっアーキテクト
、プロジェクトを（2000+日の周りのすべてのプログラマヘッドによれば）提供
の言語を選択し
、フレームの選択を
（キャッシュライブラリのメインライブラリー何で）データベースを選択し
、機能部門
開発開発グループ長い会議の配布タスク
3.開発のグループ化
プロジェクトの全体的な枠組みを構築するための設計者や開発者の頭部
次に、コードのさまざまな部分に向けて自分のチームメンバーが記入してみましょう
4.テスト
1.自己写测试脚本
显而易见的bug如果你自己没有发现，测试部分的如果发现了 那你可能歇逼了,因为你可能就会面临扣绩效的场面
2.测试部分专门测试
5.配達のオンライン
あなたの会社の運用・保守担当者や顧客の運用・保守要員に
テーブルデザイン
今、リレーショナルテーブルを言います。
7つのテーブルの合計
ログイン登録は、ユーザデータを格納するテーブルを使用する必要があります
7つのテーブルの合計
- ユーザーテーブル
- 個人サイトテーブル
- 投稿タグ付きのテーブル
- 記事の分類
- 記事のテーブル
- ポイントテーブルをステッピングのように
- コメントテーブル
解析テーブルの関係
最初の6足の親指テーブルを分析
これは、（ステッピングのように、ユーザー、投稿）上の称賛やステップで記事にその時点のユーザーを記録します
分析表は、最も重要です：
本表中的一条数据能否对应另外一张表的多条数据
另外一张表的一条数据能够对应当前的表多条数据
user_id article_id is_up
1 1 1
1 2 0
1 3 1
2 1 1最も基本的な関係を満たし、その後の関係は、多対多の関係が成立していないです。
1ポイント1人のユーザーが一度だけ、記事を賞賛し、または上のステップただ1以上。
ユーザーは、一度だけの記事と同じように1に2を指し、または、上のステップすることができ、一度だけ。
上記は、多くの1つです
その後の記事では唯一の1にすることができます
ユーザに対応する1つのレコードのみ
ユーザーは複数のレコードを持つことができます
レコードのレコード番号は、物品に対応することはできません
記事には複数のレコードすることができ
さんは分析してみましょうどのような最初の7つのテーブルのレビューテーブル
コメントは、コメントを注意することができますどのように
user 一对多用户
article 一对多文章
content
parent 一对多评论表 自关联
to='Comment'
to='self'id user_id article_id parent_id
1 1 1
2 2 1 1
3 3 1 1
