Merge branch 'hr-11-22-add_jhrcw_tables_analyse'
This commit is contained in:
12
docs/.vitepress/cache/deps/_metadata.json
vendored
12
docs/.vitepress/cache/deps/_metadata.json
vendored
@@ -1,25 +1,25 @@
|
||||
{
|
||||
"hash": "5e89be5d",
|
||||
"configHash": "296343fe",
|
||||
"hash": "f01e8699",
|
||||
"configHash": "180cc241",
|
||||
"lockfileHash": "d0a71e3e",
|
||||
"browserHash": "51bc0564",
|
||||
"browserHash": "c5767560",
|
||||
"optimized": {
|
||||
"vue": {
|
||||
"src": "../../../../node_modules/vue/dist/vue.runtime.esm-bundler.js",
|
||||
"file": "vue.js",
|
||||
"fileHash": "a8d2aada",
|
||||
"fileHash": "ffd8baa8",
|
||||
"needsInterop": false
|
||||
},
|
||||
"vitepress > @vue/devtools-api": {
|
||||
"src": "../../../../node_modules/@vue/devtools-api/dist/index.js",
|
||||
"file": "vitepress___@vue_devtools-api.js",
|
||||
"fileHash": "0e97b6c5",
|
||||
"fileHash": "c91fbfa8",
|
||||
"needsInterop": false
|
||||
},
|
||||
"vitepress > @vueuse/core": {
|
||||
"src": "../../../../node_modules/vitepress/node_modules/@vueuse/core/index.mjs",
|
||||
"file": "vitepress___@vueuse_core.js",
|
||||
"fileHash": "3570d8b8",
|
||||
"fileHash": "b91f8785",
|
||||
"needsInterop": false
|
||||
},
|
||||
"@theme/index": {
|
||||
|
||||
@@ -7,61 +7,48 @@ export default defineConfig({
|
||||
themeConfig: {
|
||||
// https://vitepress.dev/reference/default-theme-config
|
||||
nav: [
|
||||
{ text: 'Home', link: '/' },
|
||||
{ text: 'Examples', link: '/markdown-examples' }
|
||||
|
||||
{ text: "Home", link: "/" },
|
||||
{ text: "Examples", link: "/markdown-examples" },
|
||||
],
|
||||
|
||||
sidebar: [
|
||||
{
|
||||
text: "Examples",
|
||||
items: [
|
||||
{ text: 'Markdown Examples', link: '/markdown-examples' },
|
||||
{ text: 'Runtime API Examples', link: '/api-examples' },
|
||||
{ text: "Markdown Examples", link: "/markdown-examples" },
|
||||
{ text: "Runtime API Examples", link: "/api-examples" },
|
||||
|
||||
{ text: "龚涵博", link: "/ghb" },
|
||||
{ text: "吴禹谷", link: "/wyg" },
|
||||
{ text: "黄睿", link: "/hr" },
|
||||
{ text: "黄睿", link: "/hr/hr" },
|
||||
{ text: "吴子妍", link: "/wzy" },
|
||||
{ text: "潘绅翰",
|
||||
items:[{text: "psh示例",link:"/psh"}]
|
||||
},
|
||||
{ text: "潘绅翰", items: [{ text: "psh示例", link: "/psh" }] },
|
||||
{ text: "郑子墨", link: "/zzm" },
|
||||
|
||||
{
|
||||
text: "黄睿",
|
||||
items: [{ text: "hr 示例", link: "/hr" }],
|
||||
},
|
||||
{ text: "石亚玲", link: "/syl" },
|
||||
],
|
||||
},
|
||||
|
||||
|
||||
{
|
||||
text: 'ex',
|
||||
items: [
|
||||
{ text: '龚涵博', link :'/ghb'}
|
||||
]
|
||||
text: "黄睿",
|
||||
items: [{ text: "金华人才网数据表分析", link: "/hr/hr" }],
|
||||
},
|
||||
{
|
||||
text: "ex",
|
||||
items: [{ text: "龚涵博", link: "/ghb" }],
|
||||
},
|
||||
{
|
||||
text: "吴子妍",
|
||||
items: [{ text: "第三次研讨会笔记", link: "/note3-tables" }],
|
||||
},
|
||||
{
|
||||
text: '吴子妍',
|
||||
items: [
|
||||
{ text: '第三次研讨会笔记' , link:'/note3-tables'}
|
||||
]
|
||||
}
|
||||
|
||||
,{
|
||||
text: "石亚玲",
|
||||
items: [
|
||||
{ text: "jinhua", link: "石亚玲/syl-11-22-add_jh_tables_analyse" },
|
||||
{ text: "算法", link: "石亚玲/syl" },
|
||||
{text:"日程表" , link: "石亚玲/schedule" }
|
||||
|
||||
]
|
||||
}
|
||||
|
||||
{ text: "日程表", link: "石亚玲/schedule" },
|
||||
],
|
||||
},
|
||||
],
|
||||
|
||||
|
||||
|
||||
socialLinks: [
|
||||
{ icon: "github", link: "https://github.com/vuejs/vitepress" },
|
||||
|
||||
@@ -1,2 +0,0 @@
|
||||
# hr
|
||||
content
|
||||
143
docs/hr/hr.md
Normal file
143
docs/hr/hr.md
Normal file
@@ -0,0 +1,143 @@
|
||||
|
||||
# 【实战分析】从界面反推数据库设计：以金华人才网站为例
|
||||
|
||||
## 前言
|
||||
|
||||
最近在学习系统架构与数据库设计，为了检验学习成果，我选取了 **金华人才网 (jhrcsc.com)** 及其关联的 **大学生欢迎中心** 网站作为案例。通过浏览其核心业务界面（找工作、找人才、企业招聘、资讯公告等），我尝试反推了其后端数据库的表结构设计，并总结了关键的业务实现逻辑与潜在的优化方案。
|
||||
|
||||
以下是我的分析总结记录。
|
||||
|
||||
---
|
||||
|
||||
## 一、 核心数据库架构设计
|
||||
|
||||
一个成熟的招聘系统通常由 **用户权限**、**企业/职位**、**简历中心**、**内容管理(CMS)** 四大模块构成。
|
||||
|
||||
### 1. 用户与权限模块 (User & Auth)
|
||||
这是系统的入口，最大的难点在于如何处理“个人求职者”与“企业HR”的身份区分。
|
||||
|
||||
* **表名：`sys_user` (用户主表)**
|
||||
* `uid` (PK): 用户唯一标识。
|
||||
* `username` / `mobile`: 登录账号/手机号。
|
||||
* `password`: 加密后的密码 (推荐 Bcrypt)。
|
||||
* `user_type`: 用户类型 (1=个人, 2=企业)。
|
||||
* `last_login_time`: 最后登录时间（用于判断活跃度）。
|
||||
* **设计思考**：为了扩展性，建议配合 RBAC 模型，增加 `sys_role` 和 `sys_user_role` 表，允许一个账号切换不同身份。
|
||||
|
||||
### 2. 企业与职位模块 (Enterprise & Jobs)
|
||||
对应网站的“找企业”和“找工作”界面。
|
||||
|
||||
* **表名：`company_profile` (企业信息表)**
|
||||
* `id` (PK): 企业ID。
|
||||
* `uid`: 关联的用户ID。
|
||||
* `company_name`: 企业全称。
|
||||
* `logo_url`: Logo图片存储路径 (建议存相对路径或CDN地址)。
|
||||
* `industry_id`: 行业字典ID (如：交通/物流)。
|
||||
* `nature_id`: 性质字典ID (如：国企、民营)。
|
||||
* `scale_id`: 规模字典ID (如：20-99人)。
|
||||
* `is_famous`: 是否名企 (用于首页推荐排序)。
|
||||
|
||||
* **表名：`company_jobs` (职位发布表)**
|
||||
* `id` (PK): 职位ID。
|
||||
* `company_id`: 关联企业ID。
|
||||
* `job_name`: 职位名称 (如：市场营销)。
|
||||
* `salary_min` / `salary_max`: 薪资范围 (存储数值，单位元)。
|
||||
* `is_negotiable`: 是否面议 (Boolean)。
|
||||
* `edu_req` / `exp_req`: 学历与经验要求的字典ID。
|
||||
* `city_id` / `district_id`: 工作地区ID。
|
||||
* `refresh_time`: 刷新时间 (决定列表页排序权重)。
|
||||
* `status`: 状态 (1=招聘中, 0=已下架)。
|
||||
|
||||
### 3. 简历中心模块 (Resume)
|
||||
对应网站的“找人才”界面，核心在于隐私保护与多维度展示。
|
||||
|
||||
* **表名：`resume_base` (简历基本信息)**
|
||||
* `id` (PK): 简历ID。
|
||||
* `uid`: 关联求职者ID。
|
||||
* `realname`: 真实姓名。
|
||||
* `gender`: 性别。
|
||||
* `birth_year`: 出生年份 (界面显示年龄通常由年份动态计算)。
|
||||
* `privacy_level`: 隐私设置 (完全公开/仅投递可见/保密)。
|
||||
|
||||
* **表名：`resume_edu` / `resume_work` (经历附表)**
|
||||
* 设计为 **一对多** 关系。
|
||||
* `resume_id`: 外键。
|
||||
* `school_name` / `company_name`: 学校或公司名。
|
||||
* `start_time` / `end_time`: 起止时间。
|
||||
* `description`: 经历描述。
|
||||
|
||||
### 4. 运营与内容模块 (Operation & CMS)
|
||||
对应“看资讯”、“招聘会”界面。
|
||||
|
||||
* **表名：`cms_article` (资讯文章)**
|
||||
* `title`: 标题。
|
||||
* `cat_id`: 分类ID (政策、公告、指导)。
|
||||
* `content`: 富文本内容 (HTML)。
|
||||
* `publish_time`: 发布时间。
|
||||
|
||||
* **表名：`job_fair` (招聘会)**
|
||||
* `title`: 招聘会主题。
|
||||
* `start_time` / `end_time`: 举办时间范围。
|
||||
* `poster_url`: 海报图片。
|
||||
* `address`: 举办地点。
|
||||
|
||||
* **表名：`sys_dict` (通用数据字典)**
|
||||
* **作用**：这是系统中最重要的辅助表，用于存储“行业”、“学历”、“薪资范围”等下拉选项，减少数据冗余。
|
||||
* 字段：`dict_code` (如 edu_level), `dict_value` (1), `dict_label` (本科)。
|
||||
|
||||
---
|
||||
|
||||
## 二、 关键业务逻辑实现
|
||||
|
||||
在分析界面交互时，我总结了以下几个有趣的逻辑实现方式：
|
||||
|
||||
### 1. 简历隐私脱敏 (Masking)
|
||||
在“找人才”列表页，求职者姓名显示为“季**”。
|
||||
* **实现逻辑**：前端不应接收完整姓名。后端 API 在输出 JSON 前进行处理：
|
||||
```php
|
||||
// 伪代码示例
|
||||
if (!$user->is_paid_enterprise) {
|
||||
$resume['name'] = mb_substr($resume['realname'], 0, 1) . "**";
|
||||
$resume['mobile'] = "******";
|
||||
}
|
||||
```
|
||||
|
||||
### 2. 招聘会状态判断
|
||||
界面显示“进行中”或“已结束”。
|
||||
* **实现逻辑**：通常不在数据库存状态字段，而是运行时计算：
|
||||
* `Now < start_time` -> **未开始**
|
||||
* `Now > end_time` -> **已结束**
|
||||
* `Otherwise` -> **进行中**
|
||||
|
||||
### 3. 薪资的存储与展示
|
||||
界面显示“6.7-12k/月”或“面议”。
|
||||
* **实现逻辑**：
|
||||
* **存储**：数据库存精确数值 `salary_min=6700`, `salary_max=12000`。
|
||||
* **展示**：若 `is_negotiable=1` 则直接显示“面议”；否则除以1000拼接字符串。这种方式既支持范围搜索（WHERE salary > 5000），又支持前端灵活展示。
|
||||
|
||||
### 4. 登录分流
|
||||
如何实现个人和企业在同一个入口登录？
|
||||
* **方案**：后端接口统一，通过前端 Tab 页传参（`type=person` 或 `type=company`）。登录成功后，根据数据库 `user_type` 字段，后端返回不同的重定向 URL（`/person/dashboard` 或 `/company/dashboard`）。
|
||||
|
||||
---
|
||||
|
||||
## 三、 思考：现有架构的潜在优化点
|
||||
|
||||
作为学习者，如果让我来重构这个系统，我会考虑以下技术升级：
|
||||
|
||||
1. **搜索性能优化 (Elasticsearch)**
|
||||
* 目前的 SQL `LIKE '%关键词%'` 查询在数据量大时效率极低。
|
||||
* **改进**：引入 Elasticsearch，将职位和简历数据同步索引，实现毫秒级全文检索、拼写纠错和高亮显示。
|
||||
|
||||
2. **图片存储 (OSS + CDN)**
|
||||
* 网站包含大量 Logo 和海报。
|
||||
* **改进**：不应将图片二进制存入数据库或仅存本地服务器路径。应上传至阿里云 OSS / 七牛云，数据库只存 URL，配合 CDN 加速加载。
|
||||
|
||||
3. **安全性加强**
|
||||
* 招聘网站数据价值高，极易被爬虫抓取。
|
||||
* **改进**：接口增加 **Rate Limiting (频率限制)**；简历联系方式查看需增加 **积分扣除** 逻辑；关键接口增加 **Signature 签名校验**。
|
||||
|
||||
## 总结
|
||||
|
||||
通过对 `jhrcsc.com` 的逆向分析，我深刻体会到：**界面是数据的投影**。看似简单的网页，背后需要严密的数据库范式设计和复杂的业务逻辑支撑。这次分析不仅帮我复习了 SQL 表设计，也让我对业务系统的全链路交互有了更清晰的认识。
|
||||
|
||||
@@ -1,2 +0,0 @@
|
||||
# hr
|
||||
content
|
||||
Reference in New Issue
Block a user