此数据库设计是典型/有利的吗？

Question

我知道这可能是基于意见的，但我正在看某人的数据库，我很好奇这是否是一种常用技术以及优点/缺点是什么，本着变得更好的精神。

基本上，他们有一组表，按月/年比较一个表存储货币交易（正如我个人原本所做的那样）。所以它看起来像这样：

所以我做了类似的事情：

PaymentTable
receiptNumber | Tendered | date 
      001     |    100   | 01/12/2017
      002     |    200   | 02/10/2017
      003     |    300   | 03/7/2017

他们做到了

 Payment0117
    receiptNumber | Tendered | date 
          001     |    100   | 01/12/2017

 Payment0217
    receiptNumber | Tendered | date 
          002     |    200   | 02/10/2017

 Payment0317
    receiptNumber | Tendered | date 
          003     |    300   | 03/7/2017

我会在前面说，与之合作很痛苦。他们没有设置所有表的视图，所以如果我正在寻找收据002，我必须检查每个表，直到找到它。但我想知道，这种方法有性能或其他优势，因为每个表的行数会减少吗？它们可以追溯到2006年，所以有10年* 12个月=这些表中的120多个......

Answer 1

看起来有人使用表名来存储信息。这显然不符合实体 - 关系 - 方法。

表格应代表实体，如付款，客户等...... 付款月是付款的财产，并且是付款日期中包含的冗余付款。

我可以想象这样做是为了获得更小的表，并且可能将活跃的会计月份与旧月的大量写入隔离开来，这基本上是只读的。无论如何，有更好的方法来解决这个问题。

如果月份是报告的常规参数，则应正确编入索引。

如果你只有当前月份的大量写入，并且只有旧月的大量读取，可能是当前日/月等的写入的缓冲表可能有意义或BI表服务报告。