> The table name should not be meaningful to your application; nothing in > your application should conjure up a table name.
I can't get my head around this advice. Is this just for this occasion, or for every application? What if I'm writing a customer address book? Am I allowed a table called 'customers' ? Thats meaningful to my application. Not sure what your trying to advise here. On Mon, Jan 28, 2019 at 6:59 PM James K. Lowden <jklow...@schemamania.org> wrote: > On Mon, 28 Jan 2019 16:28:41 +0000 > Simon Slavin <slav...@bigfraud.org> wrote: > > > SQL is not designed to have a variable number of tables in a > > database. All the optimization is done assuming that you will have a > > low number of tables, and rarely create or drop tables. > > This. > > The table name should not be meaningful to your application; nothing in > your application should conjure up a table name. It's an external > factor your application is configured to use. > > If you're generating table names based on application data, you're > insinuating data in the metadata. When Simon says "SQL is not > designed" for that, he's referring to the fact that the schema is > expected to be relatively stable because it *describes* the data. The > system is designed to search for data in the tables, not among their > names. > > --jkl > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
