The 13 Kinds of Business Application Tables
I've spent 15 years designing, developing, and maintaining dozens of business applications.
During that time, I've noticed the database tables in a business application typically fall into one of the following categories:
- Main tables: these are the tables that sit in the middle of a database diagram with multiple connections to detail tables, lookup tables, bridge tables, and large-field tables (these tables get Tabbed Master-Detail Forms in my applications)
↳e.g.: Invoice table - Detail tables: think of these as "sub-tables" of the Main tables (these tables populate subforms on the tabs to the right of a Master-Detail form in my apps)
↳e.g.: InvoiceItem table - Lookup tables: in my apps, these tables typically have three fields: (1) an autonumber primary key, (2) an abbreviated 2-5 character code, and (3) a full description; they are usually represented with combo boxes
↳e.g.: luProductCategory table - Bridge tables: the tables that sit in the middle of a many-to-many relationship
↳e.g.: Product_Supplier table - Large field tables: one-to-one tables that hold things like BLOBs (varbinary(max)) and non-indexable nvarchar(max) fields; these generally have only two fields: the primary key of the associated table and the large object/text
↳e.g.: Dwelling-Sketch table - Temporary tables: used for performance reasons or as a workaround for non-updateable query errors
↳e.g.: tempInvoiceAgingReport table - Denormalized tables: these are tables whose values have a dependency on data in other tables; may be used in rare situations for performance reasons; they require special care to maintain, so should be avoided if at all possible
↳e.g.: CurrentInventory table - Settings tables: single-row tables used to hold global client settings, such as network folder locations
↳e.g.: GlobalParams table - Staging tables: temporary tables specifically used to support data validation and cleanup processes when importing from external sources;
↳e.g.: StripeTransactionImport table - System tables: local tables whose data impact program logic; I export the contents of these tables into version control
↳e.g.: eSyncTables table (note: the "e" prefix stands for "embedded" in my table naming convention) - Audit tables: tables that track changes to data over time for auditing purposes; these generally include a date/timestamp of when the change was made and by whom
↳e.g.: VendorHistory table - Log tables: "used to maintain a log of imported files so the user can see what they imported over time" -Laurie Almoslino
↳e.g.: FileImportLog table - Version/Changelog tables: a table to track changes made to the front-end application over time; change notes may be user- and/or developer-centric
↳e.g.: Changelog table
Special thanks to Joakim Dalby, Ben Clothier, and Laurie Almoslino for contributing additional categories beyond my original list of seven.
What did I miss? Let me know in the comments below.
Referenced articles
Image by Lubos Houska from Pixabay
UPDATED [2022-05-27]: Added category 8, "Settings tables." (h/t Joakim Dalby on LinkedIn)
UPDATED [2022-05-29]: Added category 9, "Staging tables." (h/t Ben Clothier in comments below)
UPDATED [2022-05-29]: Added categories 10 - 13, "System, Audit, Log, Changelog tables." (h/t Laurie Almoslino in comments below)