这是一个创建于 1190 天前的主题，其中的信息可能已经有所发展或是发生改变。
通常一个大的需求往往会拆分开给不同的人开发，其中往往少不了数据表，这时候问题来了，这表到底谁设计？
如果由开发人员自己设计，由于开发人员水平层次不齐，往往会出现很多渣设计。
如果由某个人全局把控去设计，有时候不懂业务不好去设计，必须深入理解需求才行。
所以，我想了想，最好的办法还是由开发各自去设计各自设计部分的表，然后在正式开始写代码之前统一评审，尽量避免渣表。
如果由开发人员自己设计，由于开发人员水平层次不齐，往往会出现很多渣设计。
如果由某个人全局把控去设计，有时候不懂业务不好去设计，必须深入理解需求才行。
所以，我想了想，最好的办法还是由开发各自去设计各自设计部分的表，然后在正式开始写代码之前统一评审，尽量避免渣表。
 |
1
yangjun 2021-08-27 14:18:11 +08:00  1
独立设计，一起评审
|
 |
2
luckyrayyy 2021-08-27 14:19:55 +08:00
独立设计，一起评审
|
 |
3
yousabuk 2021-08-27 15:40:34 +08:00 via iPhone 6
项目开始：
自己设计，自己开发。 自己埋坑，自己填坑。 几个月后： 项目屎山，项目爆炸。 |
 |
4
wangbenjun5 OP @luckyrayyy 有道理
|
 |
5
gollwang 2021-08-27 17:56:00 +08:00
谁开发，谁设计；
谁设计，谁背锅； 谁背锅，谁修复； 谁修复，谁开发。 你瞅瞅，这是一个环 |
 |
7
iovekkk 2021-08-27 18:24:43 +08:00
前端开发没搞过数据库，但是流程应该还是差不多的：
首先是拿到原始需求，据此做需求分析，此过程是把原始需求转化成技术性需求，需求分析文档，模块小的话一般就不评审了 输出技术性需求之后，技术选型以及方案基本上都能确定了，接下来就是写概要设计文档，这个是要评审的，不光是请大佬来把关，还要拉上相关模块的接口人，对接外部接口的调用 概要设计文档之后，要不要写详细设计文档，看自己，我们这边一般不评审，但是写完之后也要上传到项目文档库中 这个流程走下来，基本上不会出什么大问题 |
 |
8
wangkun025 2021-08-27 18:29:48 +08:00
同学，你听过迭代吗？谁负责就谁设计，谁负责就谁改。不是责任人，也做不了啥。
|
 |
9
thtznet 2021-08-27 18:31:53 +08:00
中小型项目面向领域设计，数据表自动生成，大型项目不用问了，肯定有专人负责。
|
 |
10
xiongshengyao 2021-08-27 18:52:11 +08:00
独立设计业务方案，包含接口、内部流程、表；
集体评审。 |
|
11
wangbenjun5 OP @wangkun025 从个人角度来说，比如容易分锅，但是从整体来说，项目容易做烂了，比如某个水平次的人埋个大坑
|
|
12
wangkun025 2021-08-27 23:47:56 +08:00
@wangbenjun5 大多数项目都会做烂，这是宿命。学会认命。
|
 |
13
waising 2021-08-28 07:27:10 +08:00
@wangkun025 #12 项目做到一定程度会重构 做烂 继续重构。。。
|
 |
14
guyueyiren 2021-08-28 09:54:10 +08:00
没做过大项目，都是芝麻绿豆的小项目，表结构自己搞
|
|
15
wangkun025 2021-08-28 16:58:58 +08:00
@waising 升职加薪就靠这个了。
|
 |
16
xuanbg 2021-08-29 06:17:05 +08:00 1
我们只有数据结构设计，不存在什么表设计。数据库表有什么好设计的，无非就是加上 id 这些固定的字段，把需要展开的集合作为子表，然后对象直接有多对多关系的加上关系表。
而且，我们做数据结构设计是要产品参与的，在产品出原型之前就会出来一个初步版本。后面如果在画原型时发现缺字段，加上也很方便。原型通过评审后，按数据结构直接出建表的 sql 脚本。 |
 |
17
noparking188 2021-08-29 09:24:13 +08:00 1
数据产品、数据开发负责
没有有专门的数据产品，就产品+数据开发负责 没有数据开发，就产品+后端开发负责 表的使用方，一般是后端，也要参与沟通 |
Select Language