Podczas importu danych z CSV do relacyjnej bazy danych kluczowa jest zgodność danych wejściowych ze schematem tabeli. Tabela "Klienci" ma kolumny: Id, Imię, Nazwisko, Email. Jeżeli wiersze w CSV zawierają dodatkowe pole "Telefon", to w typowym imporcie pojawia się problem: liczba pól w wierszu CSV jest większa niż liczba kolumn, do których mają zostać wstawione dane.
Odpowiedź "Import się nie powiedzie, ponieważ struktura pliku CSV nie pasuje do struktury tabeli." jest poprawna, bo wiele mechanizmów importu działa według zasady: każde pole z wiersza CSV musi zostać przypisane do konkretnej kolumny (po kolejności lub po mapowaniu). Nadmiarowe pole nie ma gdzie trafić, więc import jest odrzucany lub przerywany błędem walidacji.
Dlaczego pozostałe odpowiedzi są błędne:
- "Import się powiedzie, ale kolumna "Telefon" zostanie zignorowana." – ignorowanie nadmiarowych pól nie jest zachowaniem gwarantowanym; bez jawnego mapowania wiele narzędzi traktuje to jako błąd formatu.
- "Import się powiedzie, a kolumna "Telefon" zostanie automatycznie dodana do tabeli." – import danych nie powinien samodzielnie zmieniać schematu tabeli. Zmiany struktury wykonuje się świadomie poleceniami DDL (np. dodanie kolumny), a nie "przy okazji" importu.
- "Import się nie powiedzie, chyba że usuniesz kolumnę "Telefon" z pliku CSV." – to w praktyce opis możliwego rozwiązania, ale jest zbyt kategoryczne: alternatywą bywa też jawne mapowanie tylko wybranych kolumn podczas importu albo wcześniejsze przekształcenie danych (ETL). W kontekście pytania o skutki importu "bez modyfikacji" pliku, sedno pozostaje: struktura nie pasuje, więc import kończy się niepowodzeniem.
Wskazówka egzaminacyjna: jeśli w pytaniu nie ma informacji o mapowaniu kolumn, przyjmij najczęstszy scenariusz praktyczny – import wymaga dopasowania liczby kolumn i zgłosi błąd przy nadmiarowych danych.
