MS Visio 类别与 SQL Server 的关系

发布于 2024-08-19 02:50:46 字数 384 浏览 9 评论 0原文

我正在使用 MS Visio 对数据库进行建模,模型的一部分包含事务类别 - 父表具有事务 ID、时间戳、金额和事务类型。共有三个子表 - 支票、银行转帐和信用卡,所有子表均通过 transactionId 与父表相关。

在 SQL Server 中是否有实现这种关系的特定方法,或者它只是一个概念模型,由我来实现?如果是后者,如果这些表都与 transactionId 相关,为什么在父表中有一个 transactionType 列 - 这只是为了缩小我的查询范围吗?也就是说,如果父表中的一行指定“cheque”作为 transactionType,我知道我只需查询/加入 check 子表?

我突然想到 - 这只是一个 ISA 层次结构吗?在这种情况下,我将创建三个不同的表,每个表都包含 ISA 父实体中标识的列?

I'm using MS Visio to model a database and part of the model contains Transaction categories - the parent table has a transactionId, timestamp, amount, and transactionType. There are three child tables - cheque, bank transfer, and credit card, all related to the parent by transactionId.

Is there a specific way this kind of relationship is implemented in SQL Server, or is it just a conceptual model leaving the implementation up to me? If the latter, why have a transactionType column in the parent table if the tables are all related with transactionId - is it just to narrow my queries? That is, if a row in the parent table specifies "cheque" as the transactionType I know that I only have to query/join the cheque child table?

It just occurred to me - is this just an ISA hierarchy, in which case I'd create three distinct tables each containing the columns identified in the ISA parent entity?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

蒲公英的约定 2024-08-26 02:50:46

这本质上是多表继承,尽管您可以根据需要在域中将其建模为简单的引用关系。

拥有选择器字段/属性有很多充分的理由。显而易见的是,应用程序或服务可以获得有关如何加载详细信息的提示,因此它不必从每个可以想象的表中加载每个可以想象的行(当您有 20 种不同类型的事务时尝试此操作)。

另一个原因是,很多时候最终用户不一定需要知道交易的详细信息,但确实需要知道交易的类型。如果您正在查看某些财务或计费系统的应收账款报告,大多数情况下,您需要了解基本报告的只是之前的余额、金额、后续余额以及交易类型嗯>。如果没有这些信息,阅读起来非常困难。分类账不一定显示每笔交易的详细信息,有些系统甚至可能根本不跟踪详细信息。

此类模型最常见的替代方案是单个表,其中针对每种不同的事务类型都有一大堆可为空的列。尽管我个人鄙视这种模型,但它是许多仅支持单表继承的对象关系映射器的要求。这是您想要(或不想要)在数据库中对此进行建模的唯一其他方式。

This is essentially multiple-table inheritance, although you can model it in the domain as a simple reference relationship if you want.

There are many good reasons to have the selector field/property. The obvious one is so an application or service gets a hint as to how to load the details, so it doesn't have to load every conceivable row from every conceivable table (try this when you have 20 different types of transactions).

Another reason is that much of the time the end user doesn't necessarily need to know the details of a transaction, but does need to know the type. If you're looking at an A/R report from some financial or billing system, most of the time all you need to know for a basic report is the previous balance, amount, subsequent balance, and the transaction type. Without that information, it's very hard to read. The ledger doesn't necessarily show the details for every transaction, and some systems may not even track the details at all.

The most common alternative to this type of model is a single table with a whole bunch of nullable columns for each different transaction type. Although I personally despise this model, it's a requirement for many Object-Relational Mappers that only support single-table inheritance. That's the only other way you'd want (or not want) to model this in a database.

孤单情人 2024-08-26 02:50:46

如果您想查询所有交易,例如对每种交易类型的金额求和,则父表中的 transactionType 非常有用:如果

select transactionType, sum(amount)
from transactions 
group by transactionType

没有该列,您仍然可以通过查询子表来完成此操作:

select 
    case when c.transactionId is not null then 'CHEQUE'
         when cc.transactionId is not null then 'CREDIT CARD'
         ...
    end
,   sum(amount)
from transactions t
left join cheque c on t.transactionId = c.transactionId
left join creditcard cc on t.transactionId = cc.transactionId
...
group by 
    case when c.transactionId is not null then 'CHEQUE'
         when cc.transactionId is not null then 'CREDIT CARD'
         ...
    end

如您所见,这要困难得多,并且需要扩展您添加的每种交易类型的查询。

The transactionType in the parent table is useful if you'd like to query over all transactions, for example to sum the amounts per transaction type:

select transactionType, sum(amount)
from transactions 
group by transactionType

Without the column, you could still do that by querying on the child tables:

select 
    case when c.transactionId is not null then 'CHEQUE'
         when cc.transactionId is not null then 'CREDIT CARD'
         ...
    end
,   sum(amount)
from transactions t
left join cheque c on t.transactionId = c.transactionId
left join creditcard cc on t.transactionId = cc.transactionId
...
group by 
    case when c.transactionId is not null then 'CHEQUE'
         when cc.transactionId is not null then 'CREDIT CARD'
         ...
    end

As you can see, that's much harder, and requires extending the query for each type of transaction you add.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文