如何为类似monster.com的网站设计架构？

Question

我正在开发一个类似于求职者网站的网站。此外还有第三方参与（如求职者，雇主和工作/ Recruitment_Agency）。第三方安排前两方之间的交易。

我会遵循什么方法？架构如何看起来像？也有人可以参考一些好的链接或样本模式。由于

Answer 1

假设你想与关系数据库的工作：

经典模式（类似ORM生成一个）：

Table 1: Job_Seeker 
Table 2: Employer 
Table 3: Recruitment_Agency 
Table 4: Job_Seeker__Employer__Recruitment_Agency 
    foreign keys: 
    *job_seeker_id 
    *employer_id 
    *recruitment_agency_id 

，并确保在这三个外键索引，以实现更好的性能。

这样你就可以立即查询你想要什么，从任何表开始。例如，你可以使用表4中开始表1和表2中加入条件之间任何连接的表3 伪选择从代理＃4传来的所有记录：

join table1, table2 on job_seeker_id=table1.id, employer_id=table2.id having recruitment_agency_id=4 

这就要求“唯一”的一个加盟。 然后你可以添加其他中间表，如果你只需要连接两个表，但这完全取决于你在做什么。 显然，从长远来看，联接并不是真的很快，会耗费内存，并且会危及可伸缩性（特别是如果你加入多列多表），所以如果你的网站应该扩展很多，你可以做的就是去规范化您的模式（即避免引用其他行，而是将它们复制到您搜索的行中）。

非规范化和可伸缩性的极端选择是使用模式免费数据库（为了简单起见，假设一个基于mongodb的文档）。然后我的文档是这样的：

{ 
"_id":1, 
"job_seeker":{"name":"John Doe","address","New York"}, 
"employer" : {"name":"Mario Rossi","address","Rome"}, 
"agency" : {"name":"My agency","address","London"} 
} 

显然非版本的数据库都OK了你只，如果你没有真正奇怪的查询（这仍然是可能的的Map/Reduce反而会乏味写）。

对于一般参考我特别喜欢this article。

关于关系数据库的更深入的了解this是一本必备的书（AFAIK它是斯坦福大学第一个数据库课程的参考文本）。

Answer 2

你写测试描述应用程序应该做什么。为每个用户故事做这件事（作为求职者，我想注册以便能够被招聘机构联系）。优先处理用户故事。每个故事都会对数据库方案进行一些小的更改。

Answer 3

Employer 
- Id 
- profile 

JobSeeker 
- Id 
- Educational info 
- Professional info 

Job/Recruitment_Agency 
- Id 
- Join date 

Transactions: 
- Id 
-Customer ID: ID of customers in transaction. 
-Completed 
-Amount (Credit) 
-Reciept ID: the ID returned from Payment Gateway. 
-Created Date: set the created date of the transaction 
-Payment Method: set payment method for the transaction 
-Detail: enter the detail information of the transaction (optional) 

- Employer_id 
- JobSeeker_id 
- Job/Recruitment_Agency_id