Using SQL is much faster as it allows you to only load the required data from the database.
I have spent some weeks changing a program of mine from table-only to SQL with a table used solely for display. (In fact the table only ever contains a screen-full of data, though there are thousands of rows.)
I'm not sure what difference it will make to speed of loading of the program, but then you have not told us how volatile or static your data is. In my case it comes from a text file written by an old program of mine that reads GPS log data, so there are only a few columns (lat, long, time and so forth). The output data is KML (or KMZ) so I don't really have a need to store the SQL for very long, if at all.
The table filtering that I used to use is easily converted to SQL "WHERE" commands. I also use OFFSET and LIMIT to extract just the portion of SQL to display in the table (and to scroll this up and down). Sorting is also as easy in SQL as the table.
One minor irritation is that if you (as user) adjust the width of a table column, the next time the table is loaded from SQL this adjustment vanishes. So when scrolling I keep reading column widths before re-loading and then resetting them afterwards. Also, similarly, if you scroll the table horizontally the re-loaded table returns to column #1. I only partly corrected this by re-selecting the same column as was selected before re-loading. This demands that when scrolling horizontally the user must highlight a right-hand column is so that it is still visible after the re-load.
The major complication that I found was in doing updates (which you have also not told us whether you do this). It is not possible (at least using one Reader object, and I do not know if I could use two) to read data from SQL while also updating it. However if the conditions governing the update can be expressed in an SQL SELECT command then that condition can be put in an UPDATE instead.
I could publish the two versions of this program, but they have rather grown-like-Topsy (and they both do stuff like plotting out the GPS tracks) and hence may not be easy to follow. And would need some sample data (easily supplied!) to perform trial runs.
Finally, I note that while the SQL version is only slightly larger as compiled, when running on my device it takes about 150% of the memory usage as reported by a task manager.
HTH, Mike.
