Views (MySQL): verschil tussen versies
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? | + | 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.