Generator widoku SQL (CREATE VIEW)

Generator widoku SQL

Widok (VIEW) to zapytanie SELECT zapisane pod nazwą, którego używasz jak tabeli. Nie przechowuje danych: za każdym razem wykonuje zapytanie, więc zawsze zwraca aktualny wynik. Generator widoku SQL składa gotową instrukcję CREATE VIEW dla MySQL/MariaDB, PostgreSQL, SQL Server lub SQLite z nazwy widoku, tabeli źródłowej i kolumn, a opcjonalnie także z JOIN, WHERE, GROUP BY i HAVING.

Składnia CREATE VIEW

Domyślny przykład w narzędziu (MySQL) daje taki kod:

CREATE VIEW `active_users_view` AS
SELECT
id,
name,
email,
created_at
FROM `users`
WHERE status = 'active';

Ogólny wzór: CREATE [OR REPLACE] VIEW nazwa AS SELECT kolumny FROM tabela [JOIN …] [WHERE …] [GROUP BY …] [HAVING …] [WITH CHECK OPTION];

Zalety widoków

• ukrywają złożoność zapytań przed aplikacją,
• ograniczają dostęp do wybranych kolumn (GRANT SELECT na widoku zamiast na całej tabeli),
• upraszczają raportowanie i integracje,
• pozwalają zmienić logikę bez zmian w kodzie.

OR REPLACE i WITH CHECK OPTION

CREATE OR REPLACE VIEW (MySQL, PostgreSQL) i CREATE OR ALTER VIEW (SQL Server 2016 SP1 i nowszy) nadpisują istniejący widok bez jego usuwania i zachowują nadane uprawnienia. SQLite nie ma takiej składni, dlatego po zaznaczeniu opcji „Nadpisz istniejący widok” generator dopisuje przed CREATE VIEW polecenie DROP VIEW IF EXISTS. W PostgreSQL OR REPLACE pozwala tylko dopisywać kolumny na końcu listy; zmiana nazw lub typów istniejących kolumn wymaga DROP VIEW i ponownego utworzenia widoku.

WITH CHECK OPTION blokuje INSERT i UPDATE wykonane przez widok, jeśli zmieniony wiersz przestałby spełniać warunek WHERE widoku. Działa tylko w widokach aktualizowalnych. W SQLite widoki są tylko do odczytu, więc generator pomija tę opcję i informuje o tym w uwagach pod kodem.

Jak działa generator widoku SQL

Narzędzie nie łączy się z żadnym serwerem i nie wykonuje zapytań. Pobiera nazwę widoku, tabelę źródłową z opcjonalnym aliasem, listę kolumn (po jednej w linii, puste pole oznacza *) oraz warunki, a następnie składa z nich tekst SQL. Nazwy widoku i tabeli cytuje według wybranej bazy: `nazwa` w MySQL, [nazwa] w SQL Server, "nazwa" w PostgreSQL i SQLite; przyjmuje też zapis schemat.nazwa. Przecinki między kolumnami dodaje sam, a powtórzone słowo WHERE czy GROUP BY na początku pola i średnik na końcu usuwa.

Wszystko, co wpiszesz w formularzu, trafia do trzech bloków: SELECT (kolumny, wyrażenia, aliasy), FROM (tabela i złączenia JOIN) oraz WHERE, opcjonalnie GROUP BY i HAVING. Z nich powstaje definicja, którą baza zapisuje w słowniku danych.

Przy każdym odwołaniu do widoku baza rozwija zapisaną definicję i wykonuje zapytanie na tabelach źródłowych, dlatego wynik jest zawsze aktualny. Część baz, np. MySQL, potrafi scalić definicję z zapytaniem zewnętrznym (algorytm MERGE) albo wykonać ją jako tymczasową tabelę (TEMPTABLE) — na sam wynik to nie wpływa, zmienia się tylko sposób realizacji. Kolejność i nazwy kolumn widoku odpowiadają dokładnie kolejności z części SELECT, a przy braku aliasu dziedziczą nazwy kolumn źródłowych.

Pod gotowym kodem pojawiają się uwagi o typowych przyczynach błędów: SELECT * zamieniane na listę kolumn w chwili tworzenia widoku, funkcja agregująca bez GROUP BY, średnik wewnątrz pola, wielkie litery w nazwach w PostgreSQL czy WITH CHECK OPTION w widoku z agregacją. Dostajesz też trzy polecenia na później: podgląd 10 wierszy, odczyt definicji i DROP VIEW IF EXISTS. Cztery gotowe przykłady, w tym widok z JOIN i podsumowanie zamówień, wypełniają formularz jednym kliknięciem.

Przykład krok po kroku

1. Tabela źródłowa orders ma 6 wierszy i kolumny id, customer_id, status, amount: (1, 10, 'paid', 120.00), (2, 11, 'new', 80.50), (3, 10, 'paid', 200.00), (4, 12, 'cancelled', 45.00), (5, 11, 'paid', 60.00), (6, 10, 'paid', 99.50).
2. W formularzu wpisujesz nazwę paid_orders, tabelę orders, kolumny id, customer_id i amount (każdą w osobnej linii) oraz warunek status = 'paid'. Dla MySQL generator składa polecenie: CREATE VIEW `paid_orders` AS SELECT id, customer_id, amount FROM `orders` WHERE status = 'paid';
3. Uruchamiasz SELECT * FROM paid_orders; Baza filtruje 6 wierszy i zwraca 4: id 1, 3, 5 oraz 6. Wiersz 2 (status 'new') i wiersz 4 (status 'cancelled') odpadają, bo nie spełniają warunku widoku.
4. Suma kolumny amount w widoku wynosi 120.00 + 200.00 + 60.00 + 99.50 = 479.50. To samo zapytanie na całej tabeli daje 605.00, a różnica 125.50 to suma dwóch odfiltrowanych wierszy (80.50 + 45.00).
5. Dodajesz do orders nowy wiersz (7, 11, 'paid', 40.00) i nie zmieniasz definicji widoku. SELECT * FROM paid_orders zwraca teraz 5 wierszy, a suma rośnie do 519.50 (479.50 + 40.00) — dowód, że widok nie przechowuje danych, tylko wykonuje zapytanie na bieżąco.
6. Zaznaczasz WITH CHECK OPTION, generujesz widok ponownie i próbujesz zapisać przez widok wiersz ze statusem 'new'. Baza odrzuci taką operację, bo nowy wiersz nie spełniałby warunku status = 'paid' zapisanego w widoku.

Elementy polecenia CREATE VIEW — ściągawka

Praktyczne wskazówki

• Nazywaj widoki od przeznaczenia. Przedrostek v_ lub końcówka _view porządkuje listę obiektów w bazie i od razu odróżnia widoki od tabel.
• Wypisuj kolumny jawnie zamiast SELECT *. Baza rozwija gwiazdkę na listę kolumn w chwili tworzenia widoku, więc kolumna dodana później do tabeli nie pojawi się w widoku. Jawna lista ułatwia też kontrolę nad danymi wrażliwymi.
• Trzymaj powtarzalny filtr w widoku: warunek status = 'active' wpisany raz nie musi być kopiowany do każdego zapytania aplikacji.
• Podczas pracy nad definicją nadpisuj widok przez OR REPLACE (lub OR ALTER) zamiast usuwać go i tworzyć od nowa. Unikniesz przerwy, w której widok nie istnieje, i nie stracisz nadanych uprawnień.
• Najpierw przetestuj samo SELECT, bez CREATE VIEW. Jeśli zwraca właściwe kolumny i właściwą liczbę wierszy, opakowanie go w widok jest już tylko formalnością.
• W SQL Server CREATE VIEW musi być jedyną instrukcją w partii: oddziel ją od innych poleceń separatorem GO.

Czego generator nie uwzględnia

• Nie zna Twojego schematu. Sprawdza tylko format nazw (litery łacińskie, cyfry i _, do 64 znaków), więc nie wie, czy tabela i kolumny istnieją ani czy typy danych się zgadzają. Literówka w nazwie ujawni się dopiero przy wykonaniu SQL.
• Nie weryfikuje uprawnień: prawo CREATE VIEW (a przy OR REPLACE w MySQL także DROP) zależy od konfiguracji serwera.
• Wyrażenia przepisuje dosłownie. Do wybranej bazy dopasowuje cytowanie nazw, składnię nadpisania i polecenia pomocnicze (LIMIT albo TOP), ale funkcje wpisane w kolumnach, WHERE czy JOIN, np. NOW(), DATEADD() lub INTERVAL, trafiają do kodu bez zmian. Oracle nie jest obsługiwany.