Does it make sense to NOT use Views?

I use very few Views, and the ones I do use are all supplied by other modules. I am going to learn Views myself soon (I promise, Kenn). But I have to agree that I prefer doing things as "sleekly" as possible; that means my own queries or using already-existing Drupal functions (e.g. taxonomy_get_terms). The only drawback I can see is that Drupal could change the tables around and that would require extra work on my part, whereas Merlin would be the one to have to change Views to keep up.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

Whether to use views or not depends on what you are doing. The question I always ask is, will the site be high traffic? If the answer is yes than not using views is a way to tweak performance. If the site is smaller than views is a way to build queries quickly, reuse them, and manage them through upgrades.

Many of the sites I deal with are small (hundreds of visitors per day) and views seems to work fine for them. They are on a small budget and working with views seems to be fairly quick compared to hand coding which makes them more cost effective for these groups.

When a project gets big (and has the money and time) hand coding may be the more optimized way to go.

From a developer point of view I have a love/hate relationship with views. It makes some rudimentary tasks much easier. Yet, I don't get to code as often meaning my skills improve at less of a pace.

Just my 2 cents.

--
Matt
http://www.mattfarina.com

Actually, I'm struggling with how to use Views to create a nicely paginated layout of results of a SQL query from an EXTERNAL source.

You can redefine $db_url to point to an external database. It is likely that the external database does *not* have Drupal. I want to execute some custom queries on that external source, but have the result set be represented in a custom View.

Interesting times...

-b

OK then! I wonder if someone can enlighten me on this!

1) is there ANY hook in Views 2.0 that enables you to alter the SQL query before it is executed? Note that this SQL query cannot be saved as a fixed string anywhere, as I have some exposed filters that can be changed by the user.

2) what methodology would one use instead of Views, if you wanted an exposed filter and pagination displaying a view of resulting nodes? would you have to:

a) define a form for your exposed filters, and all the necessary form validation and submit handling
b) write all the code to translate the filter values into an SQL query
c) and after executing the query... then what? is there some way to get a Views-like display of the output of a query (assuming that the field being selected was the node id)? or would I have to code that from scratch too?

Here's my problem. We have a View with three exposed filters (all of them optional):

- one of them just searching for a word in the node body,

- one of them matching on multivalued CCK field with an "allowed values" list (where all values checked off in the exposed filter must be set for the record to match, so ANDing the values, not ORing)

- and one of them a "taxonomy depth search", implemented with this code patch here: http://drupal.org/files/issues/taxonomy_filter_with_depth.patch

This View was working fine in develoment, but now that it's in production, with hundreds of users registered, we are getting cases where the queries from this view are just too complex and are bogging down the MySQL server, and the web hosting company is not happy.

I looked at some of these queries and it seems that the way that the matching on the multivalued CCK field is implemented once translated to SQL by Views is not as efficient as it could be (it results in lots of table joins that may not be needed, if for example one was using the primary keys of the values, rather than their values as displayed), and if I could control the SQL I could probably make it work faster.

I am also aware that the taxonomy depth search may be the culprit, and that warnings were attached to that patch that indicated that it might not always be efficient. Well, our taxonomy is pretty small (about 100 terms split over four levels of nesting) and the depth search is a MUST-HAVE requirement, so if I can prove to myself that this is the root of our problem, I could use a temp table approach that would help me get the descendants of the term selected in the filter and turn them into possible match values... but again, I still need the ability to hand-tool my own SQL to do this.

Any help on this topic would be much appreciated, we are in a bit of a bind here!

cheers
Peter 'Fish' Fisera
GoatVirus Technologies
http://goatvirus.com/resume