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

时间:2013-01-06 23:47:54

标签: database database-design database-schema accounting

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

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

问题:

是否可以合并2个表格,并将每个交易分类为Transaction_Type,其值为Acnt_Payableacnt_Receivable

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

1 个答案:

答案 0 :(得分:1)

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

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

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

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

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

相关问题