这是一个创建于 2419 天前的主题，其中的信息可能已经有所发展或是发生改变。
楼主是学生，不大懂。
服务器阿里云学生机。
用户表里存一堆用户信息，要求多个字段，这样检索会不会很慢。
还有几个问题:
类似用户发帖，是把所有用户发的帖子都放进一张表里吗。
用户的收藏字段，是不是按照一个字段存储多个文章 ID，违反第一范式的设计模式，有什么影响🤔。
如果要学习数据库相关设计，学习路线有哪些。
服务器阿里云学生机。
用户表里存一堆用户信息，要求多个字段，这样检索会不会很慢。
还有几个问题:
类似用户发帖，是把所有用户发的帖子都放进一张表里吗。
用户的收藏字段，是不是按照一个字段存储多个文章 ID，违反第一范式的设计模式，有什么影响🤔。
如果要学习数据库相关设计，学习路线有哪些。
第 1 条附言 · 2019-03-22 16:52:26 +08:00
没想到有人还提到了我有没有资格考虑检索速度的问题。
我阐述一下我的观点，我原本以为数据库可能在一万条数据的时候就会变得卡顿，没想到这么强大。
因为没接触过，没看过其他人网站的数据库，所以才提的问题。
见识浅了，真不好意思。
我阐述一下我的观点，我原本以为数据库可能在一万条数据的时候就会变得卡顿，没想到这么强大。
因为没接触过，没看过其他人网站的数据库，所以才提的问题。
见识浅了，真不好意思。
 |
1
ecrazy 2019-03-22 08:38:05 +08:00 via iPhone
字段长度和个数都会有影响。去读官方 documents。
|
 |
2
opengps 2019-03-22 08:41:40 +08:00
必然影响啊
|
 |
3
bokchoys OP 几个问题可能很低端，但是对我很有帮助。
有没有论坛的数据库模型可以参考？ |
 |
4
5G 2019-03-22 08:46:37 +08:00  2
|
 |
5
simuhunluo 2019-03-22 08:54:28 +08:00 via Android
KV 表去存用户 ID 和收藏帖子 ID 吧。我觉得这样比较好
|
 |
6
Mac 2019-03-22 09:01:50 +08:00 via Android
关键字:连表查询。虽然现在大数据并不提倡，但对于基础应用，还是很有用的。
|
 |
7
Felldeadbird 2019-03-22 09:14:54 +08:00 1
有影响，但不至于说想象中那么可怕。
数据库设计 我觉得更多是需要 看现有的开源系统，其次是自己工作中实践总结。只有不断踩坑才知道影响的。 我司有一个 150 个字段的单表，只存放了 10W 数据，在日常的频繁查询（连表查询），并没有体会出多大的影响。我觉得在百万内的数据影响都是可以忽略的。只有千万，或者上亿才真正体会到 时间的成本。 |
 |
8
Solace202 2019-03-22 09:17:03 +08:00
我们有个表，500 个字段，100w+的数据量，不是特别明显。不过肯定有影响，但是肯定比数据量多少的影响小
|
|
9
bokchoys OP @Felldeadbird #7 好的，谢谢
|
 |
12
F281M6Dh8DXpD1g2 2019-03-22 09:18:29 +08:00
行存储数据库每次读取的时候都是读一行,所以一行要是太长的话肯定对性能有影响的
|
 |
14
zcmxw1 2019-03-22 09:21:06 +08:00
1.用户表里存一堆用户信息，要求多个字段，这样检索会不会很慢。
会慢，但是不会那么慢。添加合理的索引。几百万以内的数量级没啥问题。 2.类似用户发帖，是把所有用户发的帖子都放进一张表里吗。 还是，几百万数量级内，这样没问题。 3.用户的收藏字段 我觉得还是单独一张表吧。因为用户可能会收藏很多很多文章。一条数据包含 1 个用户,1 个文章。 4.如果要学习数据库相关设计，学习路线有哪些。 我没学过，我不清楚。。 |
|
15
bokchoys OP @simuhunluo #5 KV 表是指什么？
|
 |
17
Mazexal 2019-03-22 10:13:18 +08:00
主要是对于磁盘 IO 不太好, 数据库是一条一条插入数据的, 一条数据大小和你字段多少是呈正相关的, 字段多的话两条数据之间间隔就大, 就需要更多资源去读取这条数据
|
 |
18
mazyi PRO |
 |
20
loading 2019-03-22 12:50:12 +08:00 via Android
必然影响，但是可忽略的。
不要啥都没整就关心太多的性能问题。 |
|
21
loading 2019-03-22 12:51:27 +08:00 via Android
等你真的遇到性能问题时，请个人优化就行，没访问量就不会有性能问题，有访问量就不缺钱了。
|
 |
23
yaozmban2 2019-03-22 13:50:20 +08:00
@Mazexal 那是否可以从机算计组原理和操作系统原理出发这样作答？
数据要先读进内存，而内存和硬盘的 IO 是直接读取一个分页，分页的大小又是固定的，因此查相同的记录数，字段多的表需要交换的分页数就多，时间损耗就大。 |
 |
24
zzzzzzZ 2019-03-22 16:13:07 +08:00
会，不过一般可以无视，表设计的时候注意一下即可
直接的解决方案了解一下“垂直分表” 在总的查询效率上字段数影响只占很小的一部分，只需要保证大数据字段尽可能少即可 决定查询效率大头的永远永远永远都是 SQL 的写法 其次才是索引、存储过程、读写分离、水平分表之类的数据库层面操作 大部分程序员写出来的 SQL 都有很高潜力的效率提升（数倍~数千倍的执行效率），只不过他们不知道而已，我目前开发的 SQL 也没有做到极致，这一门实践的少，只跟大神学过一些小技巧 |
 |
25
mumbler 2019-03-22 16:15:30 +08:00
你的数据量还没资格考虑性能问题,大多数产品失败就因为在只有 100 用户的时候考虑一亿用户的情况而死掉的
|
 |
30
lookatme 2019-03-22 16:53:27 +08:00
插入操作必然会慢，查询到话，走索引的话基本无差别，走全表查就凉凉了
|
 |
31
ihavecat 2019-03-22 19:39:42 +08:00
会的，垂直分表就是一种解决这个的办法
|
 |
32
zkeeper 2019-03-23 07:29:54 +08:00
楼上有几位同学说的好, 等真正有性能问题的时候再考虑性能其实也不晚.
但是有个很多人都会忽视的前提条件: 在初期设计的时候, 尽量做到各模块间低耦合性, 否则后期发现某个地方设计缺陷导致性能问题, 再想调整就麻烦了. |
Select Language