会员教育经历的存储与搜索

bizbuy 2008-02-02 01:26:29
我现在要对会员的教育经历进行存储和检索,为了存储和读取效率,我开始的打算是这样的:

将会员所有的教育经历,包括学校、专业、时间等,放到一个<table></table>中,存入数据库的一个字段。
这样只用控制<table>的CSS就可以了,读取和存储都很方便。


但是朋友说,这样就没法检索了,或者说检索的效率非常低。建议我还是按原来的把每条教育经历逐条放到数据库保存。



我的问题:
1)我的办法对检索性能的影响很大吗,这种数据是否不适合建立索引?
2)逐条存放并索引后,检索应该是很快,但是读取和存储的时候效率不好,有没有比较好的方案?
...全文
161 20 打赏 收藏 转发到动态 举报
写回复
用AI写文章
20 条回复
切换为时间正序
请发表友善的回复…
发表回复
中国风 2008-02-02
  • 打赏
  • 举报
回复
个人经历应用一个表来记录,建上外健关系和索引
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
>> qiuming0306

如果修改的话,你需要逐条检查:该记录是否已经存在于数据库,是否已经被修改过
qiuming0306 2008-02-02
  • 打赏
  • 举报
回复
to 楼主:
教育记录的修改,更多地使用了客户端修改,统一提交的方式。
前台使用javascript对记录进行增加、修改、删除(临时存储在一个 <table> 中),提交时一次提交了所有的修改。

这样,如果是逐条存储的话,就要将该用户的所有教育记录删除,再写入所有的新记录,哪怕用户只改了一条记录。
因为修改发生的客户端,逐条对比修改已经变得不可行。所以用户每次修改,只能删除所有以前的,写入所有现在的。

---为什么要都删除呢!
修改就用修改的存储过程啊!update不型吗!
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
如果没有其他办法,看来只能这样了
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
你主要要注意数据一致性问题。处理好主数据内容更新后的检索辅助数据库更新的机制。
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
存在业务需求,该需求对性能有要求,多花一点点$老板也不会有意见的
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
是啊
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
这个需求是你前台的应用么?
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
根据就读过的学校等教育情况,对会员进行搜索时,要检索这些内容
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
你的应用在什么情况下要进行检索?
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
话虽如此,但,我想这种矛盾在很多情况下都会遇到,总归有一个比较妥善的解决办法才好
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
现在的硬盘价格是多少钱($/G) ?
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
>>>>> tim_spac

如果信息检索的需求是后端的应用,不需要很快速地响应,那就这样吧,加个全文索引(全文索引我没用过不好说)。
如果信息检索的需求也比较明确,建一个结构化的关系型辅助表,当教育记录被修改时,对该记录进行内容解析后填充到新表中,检索的时候用这个新表的数据,前端应用还用你的" <table> .."信息


你说的这个办法,是我现在正在考虑的。就是把呈现的和搜索的分表存储,呈现的数据仍放在一个字段中,搜索的数据放在一个从表中建索引。
这样可以比较好地解决读取和搜索的问题,就是数据存储了两次
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
如果信息检索的需求是后端的应用,不需要很快速地响应,那就这样吧,加个全文索引(全文索引我没用过不好说)。
如果信息检索的需求也比较明确,建一个结构化的关系型辅助表,当教育记录被修改时,对该记录进行内容解析后填充到新表中,检索的时候用这个新表的数据,前端应用还用你的"<table>.."信息
昵称被占用了 2008-02-02
  • 打赏
  • 举报
回复
这样的增长速度,可以说不能不用表来存储
liuyann 2008-02-02
  • 打赏
  • 举报
回复
建议直接用数据库,而不是你的这种方法。

create table educationRecords (
personID ... reference personMasterData,
学校
专业
时间
etc
)
bizbuy 2008-02-02
  • 打赏
  • 举报
回复
>>>> tim_spac

赞同:在特定的需求下,是要考虑很多东西

1)数据增长速度比较快,每天近千条
2)数据读取的频度最高,修改的频度为其1/20左右;
3)之所以想存储到一个字段,是因为对教育记录的修改也是特定的

教育记录的修改,更多地使用了客户端修改,统一提交的方式。
前台使用javascript对记录进行增加、修改、删除(临时存储在一个<table>中),提交时一次提交了所有的修改。

这样,如果是逐条存储的话,就要将该用户的所有教育记录删除,再写入所有的新记录,哪怕用户只改了一条记录。
因为修改发生的客户端,逐条对比修改已经变得不可行。所以用户每次修改,只能删除所有以前的,写入所有现在的。
tim_spac 2008-02-02
  • 打赏
  • 举报
回复
参考几个问题:
1. 数据量、数据增长速度
2. 数据访问提取、修改的频度
3. 数据查询检索的应用方式、场景、频度
marco08 2008-02-02
  • 打赏
  • 举报
回复
晕,原来数据库是这样用的
昵称被占用了 2008-02-02
  • 打赏
  • 举报
回复
这个必须考虑清楚,放在一个字段对检索性能的影响确实很大,如果你的记录将来可能达到10W,那就不应该放在一个字段里。
我觉得会员的教育经历就是会员表的一个子表,设计符合范式,很少有“读取和存储的时候效率不好”的说法,主从表示非常常见的

34,590

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧