Also the desire to have more than "The Ozar 5" indexes on a table _probably indicates_ that you have lots of different kinds of read-heavy queries on the table.  

Which _probably indicates_ that you could benefit from a clustered or non-clustered [columnstore index][1] on the table.  

Instead of having the optimtimal index for each of N different access paths, a columnstore gives you super-fast scanning and the ability to skip unneeded columns, and row segments.  So you can have a small number of BTree indexes for super-critical transactions, and fall back to the columnstore for everything else.

Columnstore indexes are designed to work in OLTP-heavy workloads with SQL Server 2016+. See the documentation for [Real-time operational analytics][2].

  [1]: https://learn.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview?view=sql-server-2017
  [2]: https://learn.microsoft.com/en-us/sql/relational-databases/indexes/get-started-with-columnstore-for-real-time-operational-analytics?view=sql-server-2017