One problem with SQL-based analytical privileges, for example, is that they use dynamic SQL that has to be analyzed by the database optimizer each time it is called, leading to longer runtimes. 

In addition, privilege problems are difficult to detect because the SQL code is not generated until runtime, so it is not tangible to the SQLScript debugger. 

Row-level security, on the other hand, is general-purpose and transparent: It works as follows:

1. The PROJECTION in the SELECT statement optionally contains the USER ID and the authorized data views (DATAVIEW) in addition to the required columns in the report.

2. an INNER-JOIN links the protected transaction data B -- here receipt data -- with the authorization matrix A.

3. In the WHERE clause, the authorized data views are selected via the USER ID. 

4. The authorization matrix A contains the USER ID and the data view as well as the values of the authorization fields, which can also contain patterns like "%1_01" to authorize any store ID that ends with a 1 followed by any single character followed by 01.

5. The OR concatenation of the data views ensures that authorizations are additive and duplicates are excluded.