MongoDB 的招聘管理门户数据存储/架构设计
我想使用 MongoDB 创建一个 SAAS 招聘管理门户，它将解决以下用例，
一位聪明的人力资源经理将在门户上注册他们的公司 （因此到目前为止发现了两个资源：人力资源经理和公司）
公司将拥有自己的个人资料页面，例如 http:// /myportal.com/abccompany （与 Twitter 相同）
注册后，人力资源经理可以邀请她公司的其他人力资源经理 （此处应用的业务验证与yammer相同，基于域名的访问[email protected]可以邀请[email protected] )
邀请所有可能的员工后，人力资源经理将开始发布职位 （我们现在找到了第三个资源，一个新的职位空缺！！）
创建新的职位发布后，我们获得该职位的 URI，该职位可以发布在社交媒体、其他职位门户等中。
如果沟通正确，候选人会对 Abc 公司的职位空缺感兴趣，并且他会做出一份工作之后申请在我们的门户网站上注册候选人资料。 （我们现在发现了另外两个资源“候选人”和“职位申请”）
工作申请是我们将拥有大部分事务数据的资源，该资源将不断快速变化，因为工作申请将遍历并捕获招聘的多个阶段活动），其余资源大多是只读的。
接下来，将会有一个巨大的候选人数据库，该数据库旨在与其他数据分开，以便将它们重新用作候选人档案，这意味着候选人数据不与特定公司绑定。
我如何在 MongoDb 中对此进行建模（最好使用 Morphia - 一个 java 库）来实现以下目标：
- 优化对作业申请资源的查询
- 获得 MongoDB 提供的全文搜索的优势
I want to use MongoDB for creating a SAAS Recruitment Management Portal, which will address following use cases,
One smart HR Manager would register their company on portal
( hence two resources found so far An HR Manager , and A Company )Company will have it's own profile page like http://myportal.com/abccompany
( same as twitter does )After registration HR Manager can invite other HR managers from her company
( business validation applied here is same as yammer , domain name based access [email protected] can invite [email protected] )After inviting all possible employees , HR Manager will start posting Jobs
( we found third resource now , A New Job Opening !! )After creating a new Job Posting we get URI for that Job , which could be published in Social media, other job portals etc..
If communicated right, A Candidate would get interested in a Job Opening at Abc Company and he will make a Job application after registering a Candidate profile on our portal.
( we found two more resources now Candidate and A Job Application )Job Application is the resource where we will have most of the transactional data , this resource will keep changing fast as Job Application will traverses thru and will capture multiple phases of recruitment activities ), rest of the resources are mostly read only.
Down the line, there will be a huge database of Candidates which is intended to be kept separate from other data so as to reuse them as Candidate Profile, that means Candidate data is not tied to a specific Company.
How do I model this in MongoDb ( preferably using Morphia - A java library ) to achieve following goals,
- To get optimize queries on Job Application resource
- To get the advantage of full text search provided by MongoDB
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有两件事让我觉得有点奇怪：
您知道 MongoDB 不支持传统意义上的事务（跨多个文档）吗？这并不是一个大问题，因为数据建模与关系数据库不同，并且您可能能够使用单个文档（这几乎是事务性的）来完成许多功能。
MongoDB 目前不支持全文搜索 - 经常请求和计划它，但需要更多时间：https://jira.mongodb.org/browse/SERVER-380
但是，Morphia 支持正则表达式，您可以手动标记/词干。
虽然您可以轻松地使用 MongoDB 来实现此目的，但我认为您没有任何理由不能使用 MySQL。
对于建模，我会从一种简单的方法（公司用户、公司、职位发布、候选人、应用程序）开始，只有在确实遇到性能问题时才开始优化。缓存应该能让您在您的场景中走得更远。
Two things which struck me as a little odd:
You are aware that MongoDB doesn't support transactions in the conventional sense (spanning multiple documents)? This isn't such a big problem as data modelling is different to relational databases and you might be able to accomplish many features with a single document (which is pretty much transactional).
MongoDB currently doesn't support full-text search - it's often requested and planned, but will take some more time: https://jira.mongodb.org/browse/SERVER-380
However, Morphia supports regular expressions and you can manually tokenize / stem.
While you can easily use MongoDB for this, I don't see any reasons why you couldn't go with MySQL as well.
For modelling I'd start with a simple approach (company-user, company, job-posting, candidate, application) and only start to optimize if you are actually having performance issues. Caching should get you a long way in your scenario.