Home/ Questions/Q 553075
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T11:34:02+00:00

I’m using MS Visio to model a database and part of the model contains

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0