Views (MySQL): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 11: Regel 11:
 
Een ''filter'' is een view met maar één tabel. In de tijd dat ik veel in Microsoft Access werkte, defineerde ik filters met de suffix </code>_f</code>. Ik had bv. tabel <code>order_tbl</code> en bijbehorend filter <code>order_f</code>. Vervolgens werkte ik ''nooit'' rechtstreeks op die tabel, maar altijd op het filter. Mocht de onderliggende tabel vervangen worden door een andere tabel of zoiets, dan had ik er op deze manier een abstractielaag tussenzitten.
 
Een ''filter'' is een view met maar één tabel. In de tijd dat ik veel in Microsoft Access werkte, defineerde ik filters met de suffix </code>_f</code>. Ik had bv. tabel <code>order_tbl</code> en bijbehorend filter <code>order_f</code>. Vervolgens werkte ik ''nooit'' rechtstreeks op die tabel, maar altijd op het filter. Mocht de onderliggende tabel vervangen worden door een andere tabel of zoiets, dan had ik er op deze manier een abstractielaag tussenzitten.
  
Of dit ooit van nut is geweest? ''Nee'' → ''Program today for today and tomorrow for tomorrow''
+
Of dit ooit van nut is geweest? Waarschijnlijk niet → ''Program today for today and tomorrow for tomorrow'' - Niet doen.
  
 
== Beperkingen ==
 
== Beperkingen ==

Versie van 10 mei 2018 12:32

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;

Waarom?

Er zijn verscheidende situaties waarin views handig zijn.

Abstractielaag tov. tabellen

Een filter is een view met maar één tabel. In de tijd dat ik veel in Microsoft Access werkte, defineerde ik filters met de suffix _f. Ik had bv. tabel order_tbl en bijbehorend filter order_f. Vervolgens werkte ik nooit rechtstreeks op die tabel, maar altijd op het filter. Mocht de onderliggende tabel vervangen worden door een andere tabel of zoiets, dan had ik er op deze manier een abstractielaag tussenzitten.

Of dit ooit van nut is geweest? Waarschijnlijk niet → Program today for today and tomorrow for tomorrow - Niet doen.

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.

Bronnen