I will try to give you a different view angle of this problem by separating _write_ and _read_ operations and their respective stores. A big red warning before diving into this in more depth: that is, while you can optimize for performance you are also introducing complexity which you should _understand_ and consider and talk about with your business/operations managers.

### Write operation 
As you mention your "transaction with a subset of functionality", these are your use cases/models for write operations. This way you can optimise the write models as your business drives you. Your write models could be still stored in your current RDMS choice. 

The first important distinction and added value here is that you allow yourself to:

- Separate the write concern from reads (and its persistence store)
- Ease of adding cross cutting concerns like testing, logging, auditing, deadlock management, authorising, scaling, etc.

Your writes and basically _commands_ that originates from your clients requests. These commands contain all the neccessary payload for storing your use-case optimised model to the write persistence store.

### Read operation
Depending on your data structure and relations, read models are a way to store data in a _denormalized_ way. As you wrote: a current read operation consists of 14 SQL joins which could be a nightmare to deal with. This is where use-case optimised read models can step in. 

Your read models are the _queries_ that serve the denormalised data (maybe from its separate data store). While using separate read models you optimise for performance but also add neccessary complexity. 

- Separate the read concern from writes (and its persistence store)
- Ease of adding cross cutting concerns like testing, logging, auditing, caching, authorising, scaling, etc.

Storage of the read side could be ranging from RDMS to fast NoSQL solutions like document db's and key-value stores.

### Synchronisation between the data stores

The way I do it is: whenever a _command_ executes it publishes an _event_ containing the payload of id's neccessary to start the operation of reconstituting the read store -to be in sync with the write side.

### Conclusion

All this above is nothing new. I like to call this [CQRS Lite](https://msdn.microsoft.com/en-us/magazine/mt147237.aspx) - a term I have borrowed from [Dino Esposito](https://msdn.microsoft.com/en-us/magazine/mt149362?author=dino+esposito). He has a very comprehensive tutorial [course](https://www.pluralsight.com/courses/modern-software-architecture-domain-models-cqrs-event-sourcing) on this at PluralSight, I recommend it wholeheartedly to watch it there is a lot learn from him.

Another good source in subject is [CQRS Performance Engineering: Read vs Read/Write Models](https://lostechies.com/derickbailey/2010/03/08/cqrs-performance-engineering-read-vs-read-write-models/) from Derick Bailey.