11.07.2015 Views

PHP MySQL - Stilson.net

PHP MySQL - Stilson.net

PHP MySQL - Stilson.net

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

www.it-ebooks.infoCHAPTER 34 • MYSQL VIEWSUNDEFINEDWhen a view is assigned the UNDEFINED algorithm (the default), <strong>MySQL</strong> attempts to determine which ofthe two algorithms (MERGE or TEMPTABLE) should be used. While there are a few specific scenarios in whichthe TEMPTABLE algorithm is preferred (such as when aggregate functions are used in the query), the MERGEalgorithm is generally more efficient. Therefore, unless the query conditions dictate that one algorithm ispreferred over the other, you should use UNDEFINED.If the UNDEFINED algorithm is assigned to the view, <strong>MySQL</strong> will choose TEMPTABLE if the query denotesa one-to-one relationship between its results and those found in the view.Using Security Options[DEFINER = { user | CURRENT_USER }][SQL SECURITY { DEFINER | INVOKER }]With <strong>MySQL</strong> 5.1.2, additional security features were added to the CREATE VIEW command that helpto control how privileges are determined each time a view is executed.The DEFINER clause determines which user account’s privileges will be examined at view executiontime to determine whether the privileges are sufficient to properly execute the view. If set to the defaultof CURRENT_USER, the executing user’s privileges are examined; otherwise, DEFINER can be set to a specificuser, with the user identified using the syntax 'user@host' (for example, 'jason@localhost'). Only userspossessing the SUPER privilege are able to set the DEFINER clause to another user.The SQL_SECURITY clause determines whether the view creator’s (DEFINER, which then looks to thesetting of the aforementioned DEFINER clause) or invoker’s (INVOKER) privileges should be examinedwhen the view is executed.Using the WITH CHECK OPTION ClauseWITH [CASCADED | LOCAL] CHECK OPTIONBecause it’s possible to create views based on other views, there must be a way to ensure thatattempts to update a nested view do not violate the constraints of their definitions. Furthermore,although some views are updatable, there are cases where it wouldn’t be logical to modify a columnvalue in such a way that it would break some constraint imposed by the view’s underlying query. Forexample, if the query retrieves only rows where city = "Columbus", then creating a view that includesthe WITH CHECK OPTION clause will prevent any subsequent view update from changing any value in thecolumn to anything other than Columbus.This concept and the options that modify <strong>MySQL</strong>’s behavior in this regard are perhaps bestillustrated with an example. Suppose that a view named experienced_age_view was defined with theLOCAL CHECK OPTION option and contains the following query:SELECT first_name, last_name, age, years_experienceFROM experienced_view WHERE age > 65;Note that this query refers to another view, named experienced_view. Suppose this view was definedlike so:SELECT first_name, last_name, age, years_experienceFROM employees WHERE years_experience > 5;665

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!