作为一个稍微有点产品思维的程序员，都很难理解做数据存储的时候还需要分表甚至是分库的这种设置，数据库分表或者分库主要解决的就是数据库连接数不够、单表数据量太大导致的吞吐量不够的问题，数据库本身就是一个产品，所以，如果因为上述问题导致业务需要分表或者分库，那么首先这个数据库的设计就是有问题的。

说白了，数据库作为一个工具，我认为它在设计的时候就应该考虑到这些，而不是等到连接数不够了、数据吞吐量太大了，这时候需要程序员或者程序架构的设计者去进行分表、分库的设计来避免数据库的访问受限或者性能下降等问题。

再抛开数据库不谈，我们在写一个软件产品的时候，首先需要考虑的就是尽量避免把问题抛给用户，虽然程序员是程序的编写者，有一定的技术能力去解决数据库并发问题，但是，程序员说白了也是数据库的用户，所以这也不是一些数据库在并发吞吐量大的时候把麻烦丢给程序员的理由。

但从另外一种角度来讲，一个项目如果真的出现了需要分表、分库才能解决数据库性能下降的问题，那么在有选择的情况下，说明这个项目的数据库选型就是错的，所谓有选择，比如当项目的数据吞吐量较大的时候，我们可以选择分布式数据库系统，当然了，分布式数据库其实也是一种设计。

这也得排除一些程序员本身就不具备一些数据库基础使用知识，比如说现在的数据库从种类和特性来说，像关系数据库、非关系数据库、分布式数据库、时序数据库、本地数据库等等，每种类型的数据库对应着不同的使用场景。

拿本地数据库来说吧，像Sqlite，他本身就不太具备处理大量数据的能力，所以，如果拿Sqlite在本地存储大量数据，可能就会导致数据库的性能越到后面越差，如果此时再把问题抛给数据库本身的设计问题，显然就有点说不过去了。

但是抛开像Sqlite这种特殊的轻型数据库不谈，我觉得既然程序的设计者知道分表、分库能解决单表数据量过大导致的性能下降问题，那么一些常用的大型数据库的设计者也应当考虑到这些才是。

或者换句话说，恰恰是因为很多程序员他们不懂数据库选型、不懂分布式数据库的设计，只会写一些数据库的常用Sql语句，所以，数据库的开发者才更要考虑到这部分“用户”的情况才对！

因为，在一个程序的设计中，大量的代码用来处理数据库的连接并发量和数据库数据吞吐并发量这些问题，本身就已经让程序员不能够专注于代码编写，这就像一个作家在写书的时候还要考虑书里面的字体大小是否合适一样！但是，其实这些应该是书的发行方应该考虑的问题！

结语

所以，我的看法是，至少很多程序员使用的工具是缺少用户和产品设计思维的，导致现在程序员在写程序的时候或者说程序的架构师在设计程序架构的时候还需要使用分表、分库来解决并发量，影响了程序员的专注力，这只是程序员使用的工具中的无奈点之一。

如果您认同我的观点，欢迎您留下您的意见，您还认为哪些程序员使用的工具不符合产品设计思维？