I am considering using SQLite temporary views in a current project. The sqlite.org documentation of the CREATE VIEW command says:
I’d like to know if there are any downsides to using temporary views (as opposed to persistent views), either performance or memory-related, or other issues? I assume that there is a bit of overhead every time the client creates one, but a little testing on our real database shows that overhead to be quite acceptable from a performance standpoint.
[quote=61912:@Peter Truskier]
I’d like to know if there are any downsides to using temporary views (as opposed to persistent views), either performance or memory-related, or other issues? [/quote]
Views tend to be read only
Yes; my bad for not mentioning that in this case, that’s all I need. Views will work here, but I want to make sure there’s no downside to creating temporary views. Anything else come to mind?
Not that I can think of
But if you already know you’re going to need them why not just crate them as permanent ones ?
Temporary views make some sense if you create tables on the fly & may not know the table names ahead of time - so you have to write code to create the view once the tables are created.
But if you already do know the base table names I’d just create the views right off & be done with it
Interesting question, Norman. The idea was to store the view creation code in a table in the database, and allow a normal admin (non-dba) user to edit it. That way, when a view is needed during a session, it can be created (“if not exists”) as a temporary view using the code that is stored in the database. It may or may not be worth it…
Do you really want to let your end her write views ?
Are they database savvy enough for this ?
Or a structured editor of some kind that hand holds them through it ?