|
Depending on your application and platform, response time may be an issue, particularly if you are running on a slower platform. LDSql performs well when browsed or queried on modern personal computers, but significantly slower on smartphones with less powerful CPUs and less memory. So here is some general optimization advice for application developers. Like many performance issues, there is a tradeoff between performance and convenience. Tables such as Mem are quite fast. Simple views, such as Membership or HomeTeaching, are a little slower. Somewhat complex views, such as Membership_ext, are slower still. And very complex views, such as HomeTeaching_ext, are the slowest. Developers are advised to use the tables or views that best fit the circumstances. The views perform worst with full scans, such as SELECT * FROM Membership_ext. But they perform much better when a subset is selected with a WHERE clause, especially if it uses an indexed key such as "Indiv ID" or "HofH ID". For example
As a practical case, if the user interface is designed to present a list of browsable household names
could be used to pull that data into a browsable cursor. After the user picks a household for detailed display, the next step would be a new cursor populated with
Or if you want detail for all members in that household
And, of course, the SELECT statements for a given application are better off specifying the fields for display, rather than just using SELECT *
Developers can also avoid using the most complex views entirely and write their own optimized SQL statements from scratch. |