On 2 August 2018 at 20:08, Keith Medcalf <kmedc...@dessus.com> wrote:
Further to this, you can "emulate" the current structure by creating multiple databases each containing only the tables needed for that "bit" of your application. For example, you can create a customers.db containing the customers table and all the indexes associated with the customers table. You can also create an accounting.db containing all the accounting tables (but not the customers table) and all the indexes that belong to those tables. Lather, Rinse, Repeat. Create multiple databases and do not duplicate table names -- that is each table goes in one and only one database). You then "open" a :memory: database and "ATTACH" your other database hunks as required for the application. You refer to the tables only by table name and provided that you have not duplicated tables in multiple database files, then SQLite3 will operate on the appropriate attached database. Since the indexes associated with a table must be stored in the same database file as the data table itself, all the indexes will be kept up-to-date. You will not be able to have the database enforce referential integrity across multiple "attached" databases, nor use cross "attachment" triggers (but you cannot do that now anyway). --- If you do, for some reason, choose this approach then by default SQLite limits the number of attached databases to 10, you can adjust this up to a max of 125. More info below: https://www.sqlite.org/limits.html Paul www.sandersonforensics.com SQLite Forensics Book <https://www.amazon.co.uk/dp/ASIN/1980293074> _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
