Designing a prefs system:
It would be easiest to use a table, with the load & save functions already in place, either as key pairs, or as a single row, with columns for each pref.
Questions:
What is the overhead (memory space/access time) of a table, compared to using an array?
Is that overhead different for, say, 2 columns by 10 rows compared to 10 columns with 1 data row?
Given that there is a table.dispose method, is there a runtime table.create so that the load/save routines could be used to deal with an array of prefs (if that is lower in persistent runtime overhead)?
Maybe someone's done this before - I can't see an obvious example in the fora or example files.
Arrays are more efficient than tables.
However you can't sort an array, filter it or show it in a table.
LoadCSV and SaveCSV will be quicker than implementing your own load / save mechanism.
I recommend you to use tables for databases with less than 50,000 records. Larger databases should be handled with the SQL library.
I take it that there is no runtime table creation - which would be handy here. That or the option to save the filtered part of a table directly, without copying to a temporary table.