我做一个就业网站，简历的相关信息要是存入数据库该怎么设计表结构？

用户表 user

存放用户信息

角色表 role

标识区分是公司用户还是普通用户和管理员

简历表 resume

根据用户ID存放用户的简历信息

公司表 company

存放公司的信息

招聘信息表 recruitment 存放公司用户ID 表示公司发布了几个职位

存放公司用户发布的招聘信息

求职信息表 job 存放用户ID 表示普通用户向哪些公司发布了简历 关联用户和招聘信息

存放用户发简历的求职信息

第一步是确定数据库是否只需要人才的姓名和基本联系信息，还是需要各人的简短评估，甚或是简历等更详细的信息。

第二步，把各岗位按其重要性区分优先次序，保证数据库重点突出，规模适宜管理。

以下是十四种发现优秀外部人才的方法：

寻找专家和潜才的第一步可能是公司某管理人员在某个演讲场合演讲后，某位听众前来索取演讲稿副本时递上的名片。

现成的名片/姓名信息数据库软件。某员工在读到一篇专业文章后，保存作者姓名以及文中提到的思想领袖或专家的资料。

通过搜索专家。

招聘人员与公司从事标杆研究活动团队联系，获取他们在做标杆比较时发现的关键人才名单。

请公司内部的优秀人才利用他们的联系网络，获取他们所知道的专家的名单。

请公司内部的骨干员工输入他们指导的人才的名单，和曾交过手的最好的竞争对手的名单。

咨询求职者、顾问等：“谁最善于……?”

在数据库中添加通过员工引荐系统(由最优秀人员引荐)转来的被推荐者名单。 在数据库中输入专业协会的获奖者名单。

审阅与你争夺人才的对手发布的公关通告，关注通告中提到的他们所聘用和提拔的人才的名单。

在数据库中添加曾到公司应聘(但未聘用的)的高资历人才名单。

如果新加入数据库的名字恰好正是另一名员工曾推荐的名字，便应重点关注该人，因为已有两个人分别认为该人为疑才或潜才。管理者可以与该人安排非正式会面，或者由招聘人员致电该人，做快速评估。

当有重大行业活动即将展开时，招聘人员要首先与各部门管理者共同选定目标关键人才。然后，请参会的员工和管理者在这些行业活动或展会上找到这些目标，对他们进行进一步评估，并开始游说他们加入公司。

优秀人才名单通常不会发生太大的变动，因为卓越的人才几乎永远都是出类拔萃的。出色的招聘经理也会耐心地等待他们做出跳槽的决定。

让职能领域的专家参与招聘

招聘人员并非所有领域的技术专家，因此他们筛选的对象对他们而言通常都是陌生人(除了简历内容以外，这些人的其他信息都一无所知)。而陌生人以及他们的简历往往带有欺骗性，因此在每个关键领域寻找优秀人才时，都必须有该职能领域专家的参与。

招聘团队的管理者必须认识到，这一人才搜索过程不应该仅是人事部门的事。招聘人员可以帮助维护人才名单，但大部分的工作应该由各个部门的经理、员工和团队完成，因为他们才是专家，才会经常有机会与其他专家打交道。如果要完善企业的人才捕捉系统，或许可以考虑聘用市场调查公司或在招聘团队中增加具有人才搜索经验的人员。

人事部可以扮演教练的角色，培训各职能部门的管理者和员工寻找各自专业领域的优秀人才。然而，人才搜索必须成为企业文化(招聘文化)的一部分，而帮助企业招到优秀人才的人员应该得到奖励。例如，为那些提供优秀人才名单，帮助企业评估他们碰到的明星人才的员工提供一些小奖品(例如星巴克咖啡的贵宾卡)。此外，与曾经做过猎头的招聘人员保持沟通，因为他们通常都有捕捉人才的小技巧。

编制一本《人才搜索指南》，供员工参考使用。人才搜索过程的持续进行迫使各职能部门的经理人界定其专业领域的优秀人才标准。当经理人和员工在与一些优秀人才接触时，向对方请教专业的问题、最佳学习渠道和最佳解决方案，他们自己也可以受益匪浅。

毋庸置疑，所有有竞争意识的团队都会追踪纪录其他团队里最优秀的队员的成绩。不论在商界、军队还是体育界，如果想要建立竞争力，就要创建人才数据库。

　数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！

　那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则：

1、数据库设计最起码要占用整个项目开发的40%以上的时间

数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。

2、数据库设计不仅仅停留于页面demo的表面

页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。

3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了

每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。

4、数据库设计时就要考虑到效率和优化问题

一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。

5、添加必要的（冗余）字段

像“创建时间”、“修改时间”、“备注”、“ *** 作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和 *** 作用户IP来查找定位。

6、设计合理的表关联

若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。

7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联

这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。

8、选择合适的主键生成策略

---