[development] Database / SQL future thoughts

[Michael Favia]

Jeff Eaton wrote:
> I'm not sure you understood what Earl was saying. Views does not store 
> serialized PHP, nor does it store serialized SQL.
What exactly is serialized PHP? Does he mean serialized 
objects/variables because views DOES store those (in views_object_cache) 
but I suppose it is irrelevant anyway. The real meat of the topic you 
mention below.
>
> Views stores descriptive metadata based on high-level Drupal entities 
> (nodes, comments, users, etc), and at runtime builds an appropriate 
> query. Oftentimes they are constructed based on contextual information 
> available only at runtime (the current date, the ID of the currently 
> logged in user, the page that the user is currently on). A stored view 
> in a database is useful, but not at all the same thing. Some plugins 
> for Views take advantage of the ability to modify the query at runtime 
> based on those conditions, so even stored procedures would be an 
> uncomfortable fit. Perhaps Views could *build* stored procs and save 
> them to the database?
There would have to be some significant performance improvements to 
justify pushing these views into the database in this developers 
opinion. To do so effectively views would have to actually monitor 
database schema changes (either through a DBTNG callback or another 
observable method) and change the stored database VIEWS so that they 
remain valid queries. This is opposed to the way it conveniently and 
intelligently "ignores" non conforming views object data presently. It 
would also prohibit the dynamic adjustment of views at runtime to a 
certain extent. I DO like how sucha  solution would push caching 
upstream where it can be argued it belongs but I don't know if its worth 
it with the mysql query cache, etc.
> Let's have these discussions! But also let's make sure that we know 
> what we're talking about, and we're accurate.
Thank you Jeff for seeing the issue past the person who poorly raised 
it. There is possible value in part of his argument but, is it enough to 
justify the opportunity cost of working on it and the sacrificed 
functionality we'd be asking of the views module? Views generation isn't 
much of a lag on my sites because they don't have millions of nodes, 
etc. So for me the answer is no, Earls solution to date fits my use case 
very well, but perhaps I'm an outlier.