KWALIFIKACJA INF3 - TEST WIEDZY NR 3

PYTANIE NR 27.
Załóż, że masz plik CSV, który chcesz zaimportować do bazy danych SQL. Które z poniższych poleceń jest poprawne do tego celu?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Poprawna składnia importu danych do tabeli w MySQL to LOAD DATA INFILE, które ładuje rekordy z pliku do wskazanej tabeli.
Polecenia typu "IMPORT INTO" nie są standardową składnią SQL, a "COPY" dotyczy m.in. PostgreSQL. W praktyce dla CSV często doprecyzowuje się separatory i cudzysłowy.

Pełne wyjaśnienie:

W MySQL (oraz zwykle w MariaDB) podstawowym poleceniem do masowego importu danych z pliku do tabeli jest LOAD DATA INFILE. Składnia w najprostszym wariancie wskazuje ścieżkę do pliku oraz tabelę docelową, np. LOAD DATA INFILE 'file.csv' INTO TABLE table_name;. To polecenie jest typowo używane do szybkiego zasilania tabel danymi, np. podczas inicjalizacji bazy lub migracji.

Warto pamiętać, że import CSV często wymaga doprecyzowania formatu: domyślne ustawienia nie muszą odpowiadać przecinkom i cudzysłowom typowym dla CSV. Dlatego w praktyce spotyka się opcje określające separator pól i znak otoczenia tekstu (np. rozdzielanie przecinkami, wartości w cudzysłowie) oraz polecenie pomijania nagłówka (IGNORE LINES). Dodatkowo mogą pojawić się wymagania środowiskowe, takie jak uprawnienie FILE czy włączenie obsługi importu lokalnego (LOCAL INFILE) w zależności od tego, skąd ma być czytany plik.

Dlaczego pozostałe propozycje są błędne?

  • IMPORT INTO ... wygląda wiarygodnie językowo, ale nie jest standardowym poleceniem importu w SQL ani typową składnią MySQL.
  • COPY ... FROM ... to składnia kojarzona m.in. z PostgreSQL, więc w kontekście MySQL nie będzie poprawna.
  • SELECT * FROM 'file.csv' INTO ... sugeruje traktowanie pliku jak tabeli/źródła zapytania, co w typowym SQL nie działa w ten sposób (CSV nie jest "tabelą" dostępną przez SELECT bez dodatkowych narzędzi/adapterów).

Na egzaminie zwracaj uwagę na to, dla jakiego silnika bazy danych jest pytanie: MySQL często używa LOAD DATA INFILE, podczas gdy inne systemy mają własne mechanizmy (np. COPY, BULK INSERT). To pomaga uniknąć pomyłek wynikających z mieszania składni.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
LOAD DATA INFILE to polecenie MySQL służące do masowego wczytania danych z pliku (np. CSV) bezpośrednio do tabeli. Jest używane do szybkiego importu dużych wolumenów rekordów, np. przy migracji danych lub inicjalizacji bazy danymi testowymi.
Polecenie COPY jest charakterystyczne m.in. dla PostgreSQL i nie stanowi standardowej składni MySQL. To typowy "haczyk" egzaminacyjny: różne silniki SQL mają różne narzędzia importu, więc trzeba dopasować komendę do konkretnego DBMS.
W praktyce przy CSV często doprecyzowuje się format, np. przez określenie separatora pól i znaków otaczających tekst. Robi się to opcjami definiującymi sposób rozdzielania danych (np. przecinkiem) oraz ewentualne cudzysłowy. Bez tego import może błędnie scalić kolumny.
LOCAL INFILE stosuje się wtedy, gdy plik CSV znajduje się po stronie klienta (na komputerze, z którego łączysz się z bazą), a nie na serwerze bazy danych. To rozróżnienie bywa kluczowe: bez LOCAL import może szukać pliku na serwerze i zakończyć się błędem.
Jeśli plik CSV ma nagłówek (nazwy kolumn w pierwszym wierszu), zwykle trzeba go pominąć podczas importu. MySQL udostępnia do tego opcję pomijania określonej liczby linii na początku pliku. To zapobiega zapisaniu nagłówka jako danych w tabeli.
Import z pliku wykonywany przez serwer bazy danych może wymagać specjalnych uprawnień dostępu do systemu plików. W MySQL bywa to uprawnienie FILE. Bez niego polecenie importu może zostać zablokowane ze względów bezpieczeństwa, nawet jeśli składnia SQL jest poprawna.
To częsty błąd polegający na wybieraniu "logicznie brzmiącej" komendy, która w rzeczywistości nie istnieje w danym DBMS. W SQL wiele poleceń jest specyficznych dla silnika, więc warto kojarzyć realne nazwy mechanizmów importu (np. LOAD DATA INFILE w MySQL).
Typowe problemy to: zła ścieżka do pliku, brak dostępu/uprawnień, mylenie pliku lokalnego z serwerowym (brak LOCAL), niewskazanie separatorów i cudzysłowów dla CSV oraz próba użycia składni z innego systemu (np. COPY). Warto je sprawdzić przed ponownym importem.
Nie zawsze. Domyślne ustawienia mogą nie pasować do formatu CSV (np. inny separator niż przecinek, różne znaki końca linii, wartości w cudzysłowie). Dlatego w praktyce często trzeba doprecyzować sposób rozdzielania pól i obsługę tekstu, aby kolumny trafiły we właściwe miejsca.
Najprościej skojarzyć "flagowe" mechanizmy: MySQL często używa LOAD DATA INFILE, PostgreSQL ma COPY, a SQL Server używa m.in. BULK INSERT. Na testach to klasyczne rozróżnienie składni zależnej od silnika, więc szukaj tych charakterystycznych nazw.
info

Około 45% zdających odpowiada poprawnie na to pytanie. trudne

W praktyce zawodowej kluczowe jest to, że w praktyce dla CSV często doprecyzowuje się separatory i cudzysłowy.

Źródła:

  • MySQL 8.0 Reference Manual: "LOAD DATA [LOCAL] INFILE Statement" (sekcja dot. składni i opcji importu)
  • PostgreSQL Documentation: "COPY" (opis polecenia COPY i składni importu/eksportu)
  • Microsoft Learn: "BULK INSERT (Transact-SQL)" (opis polecenia importu plików do SQL Server)

Materiały:

  • Dokumentacja MySQL: opis polecenia LOAD DATA INFILE i przykłady
  • Ćwiczenia laboratoryjne z importu CSV do tabel i ustawiania separatorów
  • Porównanie poleceń importu w różnych DBMS (MySQL vs PostgreSQL vs SQL Server)

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego