合并单独的贷款、购买和贷款销售表合并为一张交易表
INFORMIX-SE with ISQL 7.3：
我有单独的贷款、购买和贷款表。销售交易。每个表的行是 通过以下方式连接到各自的客户行：
customer.id [serial] = Loan.foreign_id [integer]; = buy.foreign_id [整数]; = sale.foreign_id [整数];
我想将三个表合并为一个名为“交易”的表， 其中“transaction.trx_type”列 [char(1)] {L=Loan, P=Purchase, S=Sale} 标识 交易类型。这是一个好主意还是将它们放在单独的表中更好？ 存储空间不是问题，我认为编程和存储会更容易。用户=明智的 一张表下有所有类型的交易。
INFORMIX-SE with ISQL 7.3:
I have separate tables for Loan, Purchase & Sales transactions. Each tables rows are
joined to their respective customer rows by:
customer.id [serial] = loan.foreign_id [integer];
= purchase.foreign_id [integer];
= sale.foreign_id [integer];
I would like to consolidate the three tables into one table called "transaction",
where a column "transaction.trx_type" [char(1)] {L=Loan, P=Purchase, S=Sale} identifies
the transaction type. Is this a good idea or is it better to keep them in separate tables?
Storage space is not a concern, I think it would be easier programming & user=wise to
have all types of transactions under one table.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个很好的解决方案。
您还可以创建三个视图，这样基本访问权限就不会改变。
顺便说一句：这是解决对象关系阻抗失配的典型方法。
您通常可以将贷款、购买和销售概括为：MoneyTransaction。
要获取所有信息，您可以像您所做的那样进行一些连接，或者像您现在所做的那样对整个系统进行非一般化。
好方法。
我可以推荐阅读
http://blogs.tedneward.com/ 2006/06/26/The+Vietnam+Of+Computer+Science.aspx
It´s a good solution.
You can also create three views so that basic access doesn´t change.
By the way: This is a typical approach to solve the object relational impedance mismatch.
You can normally generalise Loan, Purchase and Sale into something like: MoneyTransaction.
To get all information you can do some joins, as you did, or degeneralise the whole system, as you are now doing.
Good approach.
I can recommend reading
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
是的，根据我的经验，这是一个更好的解决方案。
大多数程序更多的是以报告为导向，而不是以输入为导向。在这种情况下，报告生成速度显着提高。
Yes, from my experience this is a better solution.
Most programs are more report-oriented than input-oriented. In this case report generation speeds increase dramatically.
由于某种原因，我无法对您的回复发表评论，因此我将在此答案空间中发表评论。 @帕特里克·索尔>创建单独的视图是没有必要的，甚至是不可取的。这是当铺应用程序的情况，例如，商品最初可以被典当，客户可以选择通过将其出售给当铺来转换典当，而当铺随后可以将其出售给另一个客户，因此类型最初为“L”（贷款）类型，转换为“P”（购买），转换为“I”（库存），然后转换为“S”（销售），在某些规则下，有许多不同的可能性。根据 tran 类型，只要有可能，我都会将相同的列重复用于不同的事物，例如：对于贷款，transaction.main_amount 用于本金；对于购买，transaction.main_amount 用于购买价格；对于销售，transaction.main_amount 用于销售价格。我正在存储同一商品的所有先前交易的历史记录，因为它通过不同的交易类型而变化。
For some reason, I'm unable to comment on your replies, therefore I'm going to comment in this answer space. @Patrick Sauerl> Creating separate views is not neccesary and even undesireable. This is the case of a Pawnshop application where, for example, merchandise can be initially pawned and the customer could opt to convert the pawn by selling it to the pawnshop, which in turn the pawnshop could later sell it to another customer, thus the tran type started out as type 'L'(Loan), converted to a 'P'(Purchase), converted to an 'I'(Inventory), then to converted to an 'S'(Sale), Under certain rules, there are many different sets of possibilities. Depending on the tran type, I'm re-using the same columns for different things, whenever possible, example: for Loans, transaction.main_amount is used for the Principal; for Purchase, transaction.main_amount is used for Purchase Price; for Sale, transaction.main_amount is used for Sale Price. I am storing a history of all previous transactions for the same merchandise as it morphs through different transaction types.