I agree with Jack. The Data Record tables are the consolidation tables and are extremely active tables. These tables are part of the DataRecordAll view. The DataRecordAll view is taking all the data records across over 100+ Data Record tables to join in one view. We should never query directly against these tables or view. There are several alternatives that you could look into to address your situation depending on your needs:
1. Develop a Method Query Data Adapter using the JournalForWorkflowUnit Method Type. This can be tied into Workflows to accommodate security requirements as well.
2. Build a Data Management Export Sequence with a Data Mgmt Export Data Step to store journal data in Stage. Then you can query the data safely from the Staging tables.
3. Use one of the FDX functions to export data from the Cube and store in BI Blend table. Then you can query the data safely from a BI Blend table.
4. Use one of the FDX functions to export data from the Cube and store in a custom table other than BI Blend table or Staging tables.
5. Build a Data Mgmt Export Data Step and export journal data into CSV file
6. Create Cube View or Cube View MD Data Adapters with journal detail
7. Leverage the JournalHeader, JournalLineItem, and Member tables to join into a Data Adapter
I would suggest that there is a proper data preparation strategy in place for journals. If journal reporting process requires a more enhanced version than the standard journal reporting, then find a place to organize these journal records in a way that meets your reporting requirements ( whether organizing data in new tables or dynamically creating in Data Adapters ) and optimizes query performance.
