Views query building internals I have looked at the source code, briefly, and the problem is that the module is a complex "beast" that relies heavily on the core's API which I am not currently familiar with.

I have a kind of pieced together on how Drupal assembles a completed node object by traversing the various tables (node, node_type, field_config, field_config_instance, etc).

What confuses me is the data abstraction layer. field_config has a storage_type which appears to indicate whether a field is stored in SQL or not.

From what I have read and interpreted, Drupal is flexible enough to have a system which is data store agnostic, so if I had a products content type and capacity out-grew what MySQL was capable of, I could (in theory) switch to MongoDB or similar DBMS which allows better scaling.


So, how would I attach a field to a content type, which let's say was stored in Mongo, but the remaining fields stayed in SQL?
More interesting, how does VIEWS deal with this disconnection in data storage? If I store some fields for a given type in MongoDB and some in SQL how does VIEWS handle the JOINS and filtering capability?
As it currently stands it is not possible for Drupal to run a pure MongoDB installation with Drupal. Drupal has made a lot of progress towards abstracting out database connectivity into a central model layer with Drupal 7 and Drupal 8 promises even more. However it is still a work in progress and while a majority of the functionality is available as MongoDB backend, as it stands today a few of the components remain dependant on SQL.

As most of the work to port Drupal to MongoDB has been towards scalability and performance, it is possible to have a site where public page views are 100% on MongoDB. Performance benchmarks on a MongoDB backed Drupal instance are quite impressive.