Knowledgebase

Working With Read-Only and Reporting Users Print

  • 0

Accounts for people, not applications.

WHY THEY NEED SEPARATE ACCOUNTS

Their queries are unpredictable, and they should not be able to change anything.

WHAT TO GRANT

Select only, on the specific tables or views needed.

WHAT TO PREFER OVER TABLE ACCESS

Views exposing only permitted columns.

WHY

Sensitive columns can be excluded entirely.

WHAT TO RESTRICT

Which server they connect to.

WHAT THAT SHOULD BE

A replica, never the primary.

WHY

One unbounded query would otherwise affect the live system.

WHAT LIMITS TO APPLY

Maximum query time Maximum rows returned Connection limits per account

WHY MAXIMUM QUERY TIME MATTERS MOST

It stops a runaway query automatically.

WHAT TO PROVIDE INSTEAD OF DIRECT ACCESS

Prepared reports An analytical copy Exports

WHY THAT IS FREQUENTLY BETTER

People want answers, not access.

WHAT TO LOG

What they ran, particularly against sensitive data.

WHAT TO REVIEW

Their queries, occasionally, for patterns worth optimising or productising.

WHAT TO DOCUMENT

What each view means, and what the figures represent.

WHY

Otherwise the same question gets several different answers.


Was this answer helpful?
Back

Are you happy with your experience? Leave us a review on Trustpilot.


Trustpilot