Share
De MySQL 5-serie introduceerde nogal wat veranderingen. Triggers en opgeslagen procedures waren twee van de grote ticketitems. Een van de minder bekende toevoegingen, althans van de hoeveelheid schrijven over het onderwerp, is de introductie van visies. Hoewel je na een snelle blik op MySQL-views, je misschien niet de voor de hand liggende voordelen ziet, ze zijn er als je er een beetje over nadenkt.
"Een weergave is niets meer dan een pseudo-tabel die het werk van een gedefinieerde query doet."
Kortom, de gemakkelijkste manier om naar een weergave te kijken, is dat het slechts een opgeslagen query is die een tabel nabootst. Het is niets meer dan een pseudo-tabel die het werk van een gedefinieerde query doet. Het voegt geen functionaliteit toe, zoals het veranderen van variabelen, en het vuurt ook geen andere vragen af als er iets anders gebeurt. Opvattingen zitten er gewoon, dik en stom en doen graag wat je hebt bepaald.
Op het eerste gezicht klinkt dit niet zo heel erg, maar als je langs de oppervlakte graaft, kun je beginnen aan het zien van een deel van de kracht van het lage zicht. Ik ga niet zeggen dat opvattingen je leven zullen veranderen, maar ik zal je vertellen dat ze de taak van database-interactie een beetje gemakkelijker maken om mee te werken. Ze zullen uw taak een beetje gemakkelijker maken wanneer u belangrijke versiewijzigingen aanbrengt in uw interactielaag. Ze zullen ook een aantal moeilijke taken uitvoeren, zoals dynamische rapportage iets efficiënter en een beetje gemakkelijker om mee te werken. Ik doe het een beetje makkelijker elke dag van de week.
Met alles zijn er compromissen.
"Het bekijken en waarschijnlijk verminderen van uw prestaties."
Zoals ik in het verleden heb geschreven, ben ik een voorstander van afwegingen, zolang je begrijpt wat er op tafel ligt. Meer dan waarschijnlijk zal iemand langs deze paragraaf heen bladeren en een opmerking maken dat je nooit een weergave zou moeten gebruiken vanwege de prestatieshit. Ben ik het niet mee eens. U moet elk hulpmiddel in uw gereedschapskist gebruiken, maar als ze logisch zijn. Je gebruikt geen hamer om een schroef in een muur te steken, net zoals je geen zicht zou gebruiken als je echt een hoop / geheugentabel nodig hebt. De keerzijde is de ontwikkelbaarheid voor uw toepassingen. Wanneer het zinvol is om tijd, inspanning en energie te besparen ten opzichte van de prestatieshit die u zou kunnen maken, moet u die keuze maken. Ontwikkeling draait niet alleen om de prestaties van uw applicaties, er zijn ook andere overwegingen, zoals ondersteuning, time to market en totale waarde van uw tijd.
De tools waarmee ik werk in deze tutorial zijn redelijk standaard. Ik gebruik phpMyAdmin voor de database-interactie voor verklarende doeleinden. Ik zal ook zeer rudimentaire tafelstructuren gebruiken, uitsluitend voor het gemak van uitleg. Ik verwacht niet dat deze tafelstructuren ooit in een productieomgeving zullen worden gebruikt, omdat ik ze alleen maar ter illustratie gebruik.
Nog een opmerking. Er is geen goede of foute manier om een mening te benoemen. Ik geef mijn weergaven echter de syntaxis van view_ * primary_table * _ * what_the_view_is_used_for * tenzij ik werk aan achterwaartse compatibiliteitsveranderingen. Als ik dus een weergave maakte voor statistische rapportagedoeleinden in mijn verkooptest-tabel, zou mijn weergavenaam zijn: view_salesforce_statistical_report. Dat kan vrij lang zijn en je hebt maar 64 tekens om mee te werken, dus houd dat in gedachten. Het werkt voor mij en mijn stijl, het werkt misschien niet voor jou.
"Ik ga niet zeggen dat views je leven zullen veranderen, maar ik zal je vertellen dat ze de taak van database-interactie een beetje gemakkelijker maken om mee te werken. Ze zullen je taak een beetje gemakkelijker maken wanneer je grote wijzigingen in de versie aanbrengt in uw interactielaag. Ze zullen ook enkele moeilijke taken uitvoeren, zoals dynamische rapportage iets efficiënter en een beetje gemakkelijker om mee te werken. "
Zoals ik al zei, een weergave is slechts een query. Er zijn een paar kleine configuraties die we moeten maken bij het maken van een weergave, dus laten we dat eerst bespreken. In phpMyAdmin ziet u op de tabelpagina "bladeren" een koppeling met de naam "Weergave maken".
Als u op die link klikt, ziet u iets dat er als volgt uitziet:
Dit, mijn vrienden, is waar de magie gebeurt. Er is niet veel te verklaren op de pagina, maar laten we even kijken naar de definities die we moeten begrijpen om een weergave te maken.
Eerst is er "Create View" gevolgd door "OF REPLACE". Als u op OF VERVANG klikt, doet het precies wat u denkt, en wordt een bestaande weergave overschreven. Kolomnamen is de naam van de kolommen in uw tabel. Elk is gescheiden door een komma, dus het lijkt op first_name, second_name, etc. AS is de query.
Er zijn nog twee dingen om uit te leggen, maar de concepten zijn niet moeilijk. ALGORITHM heeft de selecties van undefined, merge en temp table. Als u "Samenvoegen" selecteert wanneer er een een-op-een relatie is, combineert dit de inkomende query met de weergave. De Temp-tabel is minder efficiënt, maar als u geen één-op-één-relatie gebruikt, zoals een aggregatiefunctie zoals SUM () of als u bepaalde zoekwoorden zoals GROUP BY of HAVING of UNION gebruikt, moet u het temp-tabelalgoritme gebruiken. Dat gezegd hebbende, je kunt doen wat ik doe, en het algoritme als "undefined" laten en MySQL zal het beste algoritme selecteren om te gebruiken.
Ten slotte hebben we CASCADED CHECK OPTION en LOCAL CHECK-opties. De check-opties vertellen MySQL om de weergave-definitie te valideren als er een voorwaarde is voor de query, zoals WHERE. Als de WHERE-component gegevens uitsluit, voorkomt dit updates of invoegen van die rijen waar deze moet worden uitgesloten. De LOCAL CHECK behandelt alleen de weergave die u definieert, waarbij CASCADED CHECK voor weergaven is die u vanuit andere weergaven hebt gedefinieerd. Het zal de cheque voor die ook cascade.
Dat is een overzicht in een notendop. Laten we een paar gebruikscasussen bekijken om ze in actie te zien en waar ze uw ontwikkelingsinspanningen kunnen helpen.
Ik heb het vaker gehad dan ik zou willen vermelden wanneer ik een tafel voor eenmalig gebruik ontwerp waarvan ik nooit denk dat die genormaliseerd moet worden, dat is onvermijdelijk. Laten we het voorbeeld nemen dat eerder werd getoond met een paar meer records.
Het is duidelijk dat mijn normalisatievaardigheden in dit voorbeeld te wensen overlaten. Wat ik waarschijnlijk had moeten doen toen ik deze tabel voor het eerst maakte, had een aparte tabel voor adressen, en dan gewoon een adres-ID in mijn verkoopteam-tabel. Het probleem is dat zodra ik naar een databasewijziging overga, ik door mijn logische interactielaag heen moet en een groot aantal querywijzigingen moet aanbrengen. In plaats van zoveel werk te doen, waarom niet een uitzicht laten komen om te helpen.
Laten we eerst de wijziging in mijn tabelstructuur aanbrengen. Ik kopieer mijn tabelstructuur en gegevens naar mijn nieuwe tabel, adressen en maak de tabel goed, zoals het toevoegen van address_id en het verwijderen van de onnodige structuur:
Dan moet ik gewoon de beledigende kolommen verwijderen en mijn adres_id toevoegen aan mijn verkooptabel.
Dit is een vrij algemene verandering die je op semi-regelmatige basis maakt, hoewel nogal simplistisch van aard. Je komt erachter dat je iets kunt normaliseren vanwege een nieuwe functie. In dit geval kunnen we onze adressen hergebruiken voor klanten of voor andere werknemers, of voor wat we adressen opslaan. Dit werk is niet zo moeilijk, maar afhankelijk van uw hergebruik van zoekopdrachten, kan het vinden van alle plaatsen die u onze oude sales_force-tabel noemt, een veel grotere wijziging in de reikwijdte zijn. In komt een weergave.
In plaats van terug te gaan naar onze code, en in plaats daarvan te wachten op een normale release-cyclus, kunnen we een weergave maken om onze oude functionaliteit intact te houden. Ik heb de naam van onze sales_force-tabel gewijzigd in sales_force_normalized:
Nu kunnen we ons beeld creëren om compatibiliteit met eerdere versies te behouden:
En we hebben onze achterwaartse compatibiliteit met alleen het extra werk van het creëren van één query in MySQL:
Zelfs als ik een nieuwe verkoopmedewerker betreed, zal mijn mening de verandering weerspiegelen:
En, presto:
Ongeveer twee minuten werk om onze achterwaartse compatibiliteit met onze vorige datastructuur te behouden. Er zijn nadelen aan deze methode, omdat u geen index tegen uw weergave kunt definiëren, wat belangrijk is wanneer u trapsgewijze views gebruikt. Bovendien moet u nog steeds uw vragen wijzigen voor INSERT, DELETE en UPDATE, maar dit bespaart u wat werk. Uw prestaties kunnen een beetje dalen, maar als een stopgap is er geen eenvoudigere manier om een wijziging aan te brengen in uw gegevensstructuur om uw codebasis voor die wijziging te vereenvoudigen. Uw query's in uw logische laag blijven onaangeroerd omdat ze, voor zover ze weten, de oorspronkelijke tabel bekijken.
Nu we ons proof-of-concept onder onze gordels hebben, laten we eens kijken naar een ander gebruik. Ik heb een andere tabel gemaakt om de verkoopgegevens uit mijn verkooptestentabel vast te leggen en deze te vullen met wat willekeurige informatie. Het ziet er zo uit:
Het is een extreem vereenvoudigde tabel om de verkopen van de verkopers te illustreren. Er zijn altijd dingen die we willen extraheren voor meting op een tafel als deze. Ik wil waarschijnlijk de totale verkoop weten. Ik zou waarschijnlijk de totale verkoop per persoon willen weten. Ik zou ook de rang van de verkoopprestaties willen weten. Ik zou queries in mijn database-logica kunnen schrijven om elk van deze taken uit te voeren wanneer ik ze nodig heb, of ik zou gewoon een weergave kunnen schrijven om de gegevens naar behoefte te grijpen. Aangezien dit een tutorial over views is, denk ik dat de keuze op dit moment vrij eenvoudig is welke tactiek te nemen.
Laten we beginnen met het evalueren van de totale verkoop, samen met enige andere relevante informatie:
Dat geeft ons een beeld van:
Ik heb ook de querytijd op deze opgenomen, want als we 200 records bekijken, is dit bliksemsnel, maar de prestaties zullen variëren. Merk op dat ik de CHECK-functies niet gebruik omdat ik de informatie in een WHERE-clausule niet discrimineer. Nu we deze informatie netjes hebben verpakt, is het alleen maar zaak om ons rapportagemechanisme in onze logica op te nemen.
Het verkrijgen van deze informatie is niet zo moeilijk. Laten we nog een stap verder gaan en een GROUP BY-functie en een join-functie gebruiken tegen de verkopers. Nogmaals, ik gebruik vereenvoudigde vragen om te illustreren. In dit geval willen we dezelfde informatie als bij de totale verkoop ontvangen, maar deze keer wordt deze opgesplitst door onze individuele verkoper.
Dat geeft ons een beeld van:
Nogmaals, heel eenvoudig om deze waarden uit uw database te halen. Laten we nog een voorbeeld bekijken, dat de twee weergaven combineert. Ik wil de totalen vergelijken met het individu, en daarom zullen we twee standpunten bekijken:
Dat geeft ons een beeld van:
Een ander voordeel van meningen is dat ze een ander niveau van beveiliging bieden voor uw toepassingen. U stelt uw tabelstructuur niet bloot aan uw toepassing. In plaats daarvan stel je iets bloot dat niet echt bestaat, behalve als een pseudo-tafel. Ik zou een opinie geen best practice willen noemen en ze vooral gebruiken voor het schrijven van beveiligde applicaties, maar ik zou het als een extra voordeel beschouwen.
Ik gebruik op beperkte wijze weergaven. Waar ik weergaven gebruik, is zoals hierboven aangetoond, met name in de rapportagemechanismen in mijn applicaties. Het schrijven van een vraag om het zware werk voor mij uit te voeren, is veel gemakkelijker dan het schrijven van de logica over moeilijkere vragen. Ik neem af en toe een beetje een hit op mijn prestaties, die ik vaak probeer te verhelpen door de originele gegevensstructuur te optimaliseren. Ik moet nog een showstopper hebben in termen van prestaties, maar de dag is jong. Heel erg bedankt voor het lezen.
Accentsconagua