Views (MySQL)

Views zijn virtuele tabellen. Een view wordt samengesteld als een select query, inclusief gebruik van joines. Simpel voorbeeld, afkomstig uit Drupal 7:

create view semaphore as select * from mb7semaphore;

Parsed & backup-issue

• Een vervelende eigenschap van views: Ze worden geparsed, herschreven en van commentaar ontdaan. Ik vind het altijd vervelend om zulke geparste views te moeten teruglezen. Helaas is het niet anders
• Nog een vervelende eigenschap van views: Als een view defect is, kun je de betreffende database niet backuppen.

Een workaround die beide problemen min-of-meer oplost: De broncode van views in een apart bestand Bijhouden. Dat bestand zou je zelfs kunnen incorporeren in de betreffende database. Mocht een defecte view een backup tegenhouden, dan kun je de betreffende view ongestraft verwijderen. Vanuit de broncode kun je later het probleem oplossen.

Beperkingen

Niet goed bij te werken

Als je eenmaal een view hebt aangemaakt, en je wilt deze naderhand bijwerken, dan gaat dat niet lekker: De SQL-code wordt door MySQL in geparste vorm opgeslagen (oa. worden alle objectnamen binnen `backticks` geplaatst). Deze geparste code vind ik vervelend om mee te werken. Hier is geen directe oplossing voor [1].

Workarounds:

• View aanmaken in SQL, dus in een gewoon script, of zelfs in een sproc - Is goed te doen. Zie het voorbeeld elders in dit artikel van de Drupal-view
• De broncode van de view in een apart bestand bij te houden, of zelfs in een tekstveld in dezelfde database. Erg vrolijk word ik daar echter niet van.

Geen indices

Je kunt geen indices defineren op een view. Vermoedelijk werken indices op de oorspronkelijke tabel wél in bijbehorende views.

Verandert niet mee

[2]:

The view definition is “frozen” at creation time and is not affected by subsequent changes to the definitions of 
the underlying tables. For example, if a view is defined as SELECT * on a table, new columns added to the table 
later do not become part of the view, and columns dropped from the table will result in an error when selecting 
from the view. 

Dit vind ik altijd tricky, omdat de gevolgen vermoedelijk desastreus kunnen zijn.

Oplossing: Views steeds opnieuw defineren als je 'm gaat gebruiken. Net als wat ik doe met tmp-tabellen. Echter: Waarom dan nog views gebruiken?

Verstoort backups

Als een view defect is, kan er geen backup gemaakt worden van de betreffende database. Als je je daar niet van bewust bent of daar niet op controleert, kan het gebeuren dat je al tijden geen backup hebt gemaakt. Ik vermoed dat defecte views vrij gemakkelijk kunnen ontstaan, itt. defecte sprocs.

Wanneer een view gebruiken?

Als je anders ingewikkelde inline queries zou krijgen. Voorbeeld: Bij het samenstellen van een export-bestand, moet er soms flink wat gegoocheld worden met onderliggende data. Dat kan mooi in een view.

Bronnen

• http://www.w3schools.com/sql/sql_view.asp
• http://rpbouman.blogspot.nl/2006/05/mysql-view-metadata-original-source.html