MongoDB 的招聘管理门户数据存储/模式设计答案

【问题标题】：Recruitment Management Portal Datastore / Schema Design For MongoDBMongoDB 的招聘管理门户数据存储/模式设计
【发布时间】：2012-01-14 08:04:21
【问题描述】：

我想使用 MongoDB 创建一个 SAAS 招聘管理门户，它将解决以下用例，

一位聪明的人力资源经理会在门户网站上注册他们的公司（因此到目前为止找到了两个资源一个人力资源经理和一个公司）
公司将拥有自己的个人资料页面，例如http://myportal.com/abccompany （和推特一样）
注册后人力资源经理可以邀请本公司的其他人力资源经理（此处应用的业务验证与yammer相同，基于域名的访问user1@company1.com可以邀请anyuser@company1.com）
邀请所有可能的员工后，人力资源经理将开始发布职位（我们现在找到了第三个资源，一个新的职位空缺！！）
创建新的职位发布后，我们将获得该职位的 URI，该 URI 可以发布在社交媒体、其他职位门户等中。
如果沟通得当，候选人会对 Abc 公司的职位空缺感兴趣，他将在我们的门户网站上注册候选人资料后提出工作申请。（我们现在又找到了两个资源候选人和工作申请）
Job Application 是我们将拥有大部分事务数据的资源，随着 Job Application 将遍历并捕获招聘活动的多个阶段，此资源将保持快速变化），其余资源大部分被读取仅限。
接下来，将有一个巨大的候选人数据库，旨在与其他数据分开，以便将它们用作候选人资料，这意味着候选人数据不与特定公司相关联。

如何在 MongoDb 中建模（最好使用 Morphia - A java 库）以实现以下目标，

【问题讨论】：

到目前为止，您尝试了什么？这是作业吗？
领域中的哪些因素导致您选择 MongoDB 作为数据存储，尤其是因为您目前似乎还没有特别精通 MongoDB？虽然很好，但 MongoDB 不一定是解决您所说的问题的最佳解决方案。
致 user908088 不，我的朋友，这不是作业！ @cdeszaq 因素，--全文搜索（围绕标签创建功能的能力）--易于管理--相对便宜的托管数据存储！

【解决方案1】：

有两件事让我觉得有点奇怪：

Job Application 是我们将拥有大部分交易数据的资源，该资源将不断变化，因为 Job Application 将遍历并捕获招聘活动的多个阶段），其余资源大多是只读的。

您知道 MongoDB 不支持传统意义上的事务（跨越多个文档）吗？这不是什么大问题，因为数据建模与关系数据库不同，您也许可以使用单个文档完成许多功能（这几乎是事务性的）。

利用MongoDB提供的全文搜索的优势

MongoDB 目前不支持全文搜索 - 它经常被请求和计划，但需要更多时间：https://jira.mongodb.org/browse/SERVER-380

但是，Morphia 支持正则表达式，您可以手动标记/词干。

虽然您可以轻松地为此使用 MongoDB，但我看不出有什么理由不能让您也使用 MySQL。

对于建模，我会从一种简单的方法（公司用户、公司、职位发布、候选人、应用程序）开始，并且只有在您确实遇到性能问题时才开始优化。缓存应该让你在你的场景中走得很远。

【讨论】：