With the data driven approach I suggested, you would want your SQL query to return just one row of data. Each cell in that row can be compared to one piece of data displayed in the UI.
It would not work very well if the SQL query returns multiple rows of data. Test Studio will want to compare each column of data to the same UI element displayed in the browser N times, where N = number of rows of data returned by the SQL query. Thus the test would run N times comparing each column to just one UI element during each iteration.
I'm not even sure if Find.AllByExpression() or Find.AllByXPath() would work very well. This approach would only work if the expression is unique enough to get only the correct set UI elements to compare against, and all of these UI elements are contained in the DOM at once. If you have to click something to move from report A to report B in order to bring the UI element into the DOM so you can fetch it, then Find.AllByXXXX won't work since it can only fetch what's currently in the DOM.
However if you actually can get all the UI elements to validate all at once with Find.AllByXXXX, then yes using code you could iterate through the UI elements returned and compare them to the data set returned by your SQL query done in code.