 describing tables to views tables are described to views via hookviewsdata which returns an array of table information keyed by the name of the table for example if your module is describing three tables foo bar and baz your array will look like this data array foo array info here bar array info here baz array info here the key should be the actual database name of the table not including prefix but it can be an alias as long as the join information explained later contains the real name of the table each item in the array should be a field in the table with the exception of a special information section called table example data foo array table array info about the table described later bar array info about the field named bar ie foobar baz array info about the field named baz ie foobaz once you get down to an array that contains actual data that piece of the array will often be referred to as the definition the table section each table should have a table section in it which is used to set default information for the table such as the group as well as the very important joins and whether or not this is a base table first there are several items that are actually for fields but can be placed here so that all fields within the table inherit them group the name of the group this item will be with in the ui this is displayed as group title for example node node id taxonomy term description etc it is important to be consistent with groups because the ui sorts by group and allows filtering by group to find fields as well title the actual name of the field it should be concise and descriptive help a longer description to help describe what the field is or does it should try to be only a line or two so as not to clutter the ui in general having title and help at the table level doesn t make a lot of sense but usually every item in a table is in the same group thus it is very common to define the group data foo table group t foo  base table if your table is a base table meaning it can be the primary central table for a view to use you can declare it to be a base table this primarily provides ui information so that it can be selected for example advertise this table as a possible base table data node table base array field nid title t node help t nodes are a drupal site s primary content weight 10 the following tags are available in the field the primary key field for this table for views to treat any table as a base table it must have a primary field for node this is the nid for users this is the uid etc without a single primary key field ie not a composite key views will not be able to utilize the table as a base table if your table does not have a primary key field it is not too difficult to just add a serial field to it usually title the title of this table in the ui it should be singular and describe the object that this table contains from the perspective of the user help a short piece of text to describe what object this table contains database if this table is held in a different database from your drupal database specify it as a string in the exact same format as the settingsphp file this is a special purpose variable that will probably be only used in site specific code and it must be the same database type as your drupal database  also don t try to join it to any table that isn t in the same database that ll just create all kinds of silly errors for example in settingsphp for your site your drupal site database needs to be called default dburl default mysqli user pass host drupaldb dburl budget mysqli user pass host otherdb then when you are describing the external database in your base table you would write something like this data table table base array field primary key title t field name help t field description database budget weight 10  linking your table to existing base tables for views to use your table it has to either be a base table or know how to link to an existing base table or sometimes both views uses this information to create a path to the base table when the table is added to the query views will walk along this path adding all tables required into the query how termdata joins to node in the above example to use these with node as the base table both termdata and termnode need to be defined and they each need a join handler for node data termdata table join node array lefttable termnode leftfield tid field tid the above can be read as in order to join to the node table the termdata table must first link to the termnode table and they join on the tid field when adding this table to the query for a node view views will look at this and then look for the termnode table data termnode table join node array leftfield nid field nid above the fact that lefttable is left out lets us know that termnode links directly to the node table using the nid field on both sides of the join quite a few more fields are available in this definition handler the name of the handler object to use defaults to viewsjoin you may create custom join handlers that may or may not use any of the data below as they see fit table table to join this is optional and should only be used if the table being referenced is an alias field field to join on this is required lefttable the next step toward the final destination if this is the final destination it may be omitted leftfield the field to join to on the left side this is required type either left default or inner extra either a string that s directly added or an array of items each item is itself an array field field or formula operator similar to filters this is the operator such as etc defaults to or in value must be set if an array operator will be defaulted to in numeric if true the value will not be surrounded in quotes and d will be used for its placeholder extra type how all the extras will be combined either and or or defaults to and describing fields on tables aside from the special table tag each table can also have an unlimited number of field designations these correspond roughly to fields on the table though it is very common to use nonfields to display data that isn t directly in a field such as data arrived from formulae or special links related to the object the table is part of each field is described in the view data with an array keyed to the database name of the field this array may contain some information fields plus an entry in each of the five types of items views has per field argument field filter relationship sort for example data node nid array title t nid help t the node id of the node the help that appears on the ui information for displaying the nid field array handler viewshandlerfieldnode click sortable true information for accepting a nid as an argument argument array handler viewshandlerargumentnodenid name field title the field to display in the summary numeric true validate type nid information for accepting a nid as a filter filter array handler viewshandlerfilternumeric information for sorting on a nid sort array handler viewshandlersort the above example describes the nid field on the node table providing 4 of the 5 handlers note that while field is normally expected to be the database name of the field it doesn t have to be you can use an alias which is how you get multiple handlers per field or something completely made up for items that aren t tied to the database for example data node editnode array field array title t edit link help t provide a simple link to edit the node handler viewshandlerfieldnodelinkedit the above handler definition an edit link to a node but this isn t a field in and of itself for aliased fields here is another example data users uidcurrent array real field uid title t current help t filter the view to the currently logged in user filter array handler viewshandlerfilterusercurrent the above definition provides an alternate filter handler on the uid field for the current user the following items are allowed in the field definition group title help as above these fields are for the ui if placed here any of these fields will override a setting on the base table real field if this field is an alias the real field may be placed here and the handler will never know the difference field a handler definition for the field section which is a field that may be displayed in a view the definition is an array the contents of the array are completely up to the handler other than the handler definition if omitted handler will default to viewshandlerfield filter a handler definition for the filters section which will be used to apply where clauses to the view the definition is an array the contents of the array are completely up to the handler other than the handler definition if omitted handler will default to viewshandlerfilter sort a handler definition for the sort criteria section which will be used to add an order by clause to the view the definition is an array the contents of the array are completely up to the handler other than the handler definition if omitted handler will default to viewshandlersort relationship a handler definition for the field section which is a way to bring in new or alternative base tables in the view the definition is an array the contents of the array are completely up to the handler other than the handler definition if omitted handler will default to viewshandlerrelationship the basic relationship handler requires base and base field to be set base and base field represent the right half of the join that will use this field as the left side argument a handler definition for the field section which is method of accepting user input from the url or some other source the definition is an array the contents of the array are completely up to the handler other than the handler definition if omitted handler will default to viewshandlerargument for more information about what handlers need use what data visit the views api site and check out the available handlers  