Is it better to have a wider single table or "child" tables based on business processes?
I am a fan of separating items that truly have separate purposes (given that this is an OLTP system, as stated by the O.P.).

Please see my answer to the following DBA.SE question that covers this in more detail, and has links to more of my answers on this same topic showing various examples of implementing this:

Abstract classes in SQL Server. Are they even possible?

The general reasoning is this:


Performance is generally better when normalizing to separate tables. After all, we are working in a "Relational" Database Management System, right? Yes, there will be JOINs require by some consumers of this data, but less data per row = more rows per data page = more data loaded into memory per each read = more efficient I/O and memory usage.
Maintainability is better when normalizing out. It is easier to explain to new members of the team that data comes from related tables (explicitly denoted by the PK -&gt; FK relationship(s)) than it is for them to remember all of the whacky rules for which columns pertain to which teams / consumers.
It is not difficult to adjust the data model if / when business rules change. Yes, things always change. However, it is fairly easy to move a column from a related table back into the main table (simplified here):


ALTER main table to ADD new column
UPDATE main table with values from related table
Adjust / create indexes, if new column should be indexed
ALTER procs to reference new location
ALTER related table to DROP column (might need to drop indexes that use this column beforehand)