你们团队开发是用一个数据库还是各自用自己电脑的数据库？

[小程序袁]

rt
如果用各自的 说说为啥，有啥好处？

[bdmh]

尽量用同一个，如果不行，也要在保证数据库结构，表结构等同步的情况下，各自开发，或者每个人只负责自己模块的表，最后再合并

[bdmh]

尽量用同一个，如果不行，也要在保证数据库结构，表结构等同步的情况下，各自开发，或者每个人只负责自己模块的表，最后再合并

[bdmh]

尽量用同一个，如果不行，也要在保证数据库结构，表结构等同步的情况下，各自开发，或者每个人只负责自己模块的表，最后再合并

[小程序袁]

引用 1 楼 bdmh 的回复:

尽量用同一个，如果不行，也要在保证数据库结构，表结构等同步的情况下，各自开发，或者每个人只负责自己模块的表，最后再合并

哥 ，你这是重要的事情说3遍的意思？

[娃都会打酱油了]

同一个数据库，必须的！！！

[以专业开发人员为伍]

这个不需要纠结。 纠结时，可能主要是考虑到“谁去手工设置库结构？”的问题。也就是DB First 还是 Code First 的问题（我不是仅仅说的EF，我是说的是模式）。 假设你们的开发中将（关系）数据库结构更新升级作为一个开发时自动的行为，例如应用程序自动运行关系数据库的脚本文件而自动升级，或者并不是所有开发者都只是在一个办公室里访问同一个关系数据库（例如在不同城市、在不同时间、在家里，等等），或者有大量自动化测试数据可能随时对数据库进行剧变，或者就是懒得总是动不动就去手动修改配置文件中的数据库连接串，等等原因，这就需要能够分开数据库而互不干扰。 如果是因为其中有大量“手工操作”、开发者不能自己部署和升级的服务才只好让所有人都跑到一个地方去访问你的公共的东西，这说明了你们的团队的一个“懒得自动化”的效率和“相互牵制”的风格而已。

[以专业开发人员为伍]

基本上，这是遇到了一个开发技术的瓶颈，不习惯于对许多东西进行开发自动化，才会有不同的观点。 至于说在团队中，有些人跑到老板那里告状说“根本用不着那么高的开发技术，其实用最低级的技术也能照样开发出刚好够用的软件”的逻辑去最终降低一个公司的长期竞争实力和投入产出效率，这也会产生开发模式上的保守和简单化。

[software_artisan]

公共的必须要有一个，出问题的时候才好判断是数据问题还是逻辑问题。至于开发人员自己的数据库，你觉得不装一个能行么？

[winner2050]

新系统最好各用个的。 成熟的系统可以共用。 新系统数据库变动快，现在数据库结构是自动维护的。 如果甲码农开发A功能，乙码农开发B功能，共用数据库随时导致反复升级降级。

[小程序袁]

[小程序袁]

引用 9 楼 winner2050 的回复:

新系统最好各用个的。 成熟的系统可以共用。 新系统数据库变动快，现在数据库结构是自动维护的。 如果甲码农开发A功能，乙码农开发B功能，共用数据库随时导致反复升级降级。

我只是感觉数据不统一，我的功能拿过去别人那里用的时候很麻烦，数据都要重新插入，修改

[Aucor]

同一个