Note 2: the demo is self-updating, and on startup will generate sales data as necessary to bring entries current as of yesterday’s date. If you’re curious, you can see a complete list of FileMaker’s reserved SQL words here. Note 1: I’ve intentionally avoided using reserved SQL words as table or field names in the demo file to help keep the example syntax clean. …and just a reminder that SQL doesn’t care about joins on the graph all of today’s SQL examples would be equally valid if the graph looked like this. The remaining tables (types and dev) don’t concern us today. Here are table definitions, with over 100K sales records and 4.6K customer records, as well as a states table with one entry for each of the 50 U.S. I hope this can be the start of a conversation where others will chime in and share their knowledge. But first, I should point out that what follows reflects my current understanding of how things work. Well today we’re going to take a look at #3 and see what we can learn re: optimizing multi-table queries. If you’re querying multiple tables, make sure to construct the query to run optimally.Only query stored values - if you’re querying a single table it should be fast.Make sure there are no records open locally, i.e., on your machine, in the tables you are querying (for more information see this article by Wim Decorte: ExecuteSQL – The Good, The Bad & The Ugly).
Recently a colleague requested help w/ a SQL query that was performing slowly. Demo file: sql-multi-table-query-optimization-v2.zip
0 kommentar(er)
