应付帐款/应收帐款数据库架构

Question

我搜索了这个主题，有很多解释要收集。主要是为/ p和/ r做单独的表。

我正在考虑将两个表合并为1的另一种方法，因为a / c和a / r是98％相似的，只有1或2个属性（例如a / p：供应商/供应商）不同。

问题：

是否可以合并2个表格，并将每个交易分类为Transaction_Type，其值为Acnt_Payable或acnt_Receivable？

我知道这是可能的，但这是一个好习惯吗？在处理Reports时，我的系统将面临什么情况？

Answer 1

您的问题是：“另一个表格或其他列”。鉴于我已经完成了大量的MySql和会计数据库操作，我会毫不犹豫地将type作为额外的列。

处理报告的过程是，您需要重新编写提取报告的代码。拥有额外的列意味着更少的连接（如果你现在有它们）。您需要加强错误检查，因为对已经设计的软件进行更改似乎总是让我措手不及，因为我之前没有考虑到设计的细微差别，这突然成为逻辑的范式转变。

我要说从空白画布重写报告代码;在你从“上一次”增加的经验到这一次的新面貌之间，你可能会做得更好。

恕我直言，对于性能方面，大多数企业和大多数普通编码员都可以通过现成的MySql或PostgreSQL安装。当我观察查询花费的时间超过一秒时，通常是因为我需要添加一个索引。鉴于此，您可以使用另一个表格，其中ID代表AR与AP（或任何其他人类术语），因为我认为数字会提高性能。

一旦公司到达性能真正成为问题的地方，他们就会有资源雇用一个真正的MySql人进来并搞砸它。 讽刺： 当然，除非您正在使用快速书，否则，一旦您超过了每天20次交易的妈妈和流行音乐联合，你正在使软件负担过重。