W relacyjnych bazach danych dane są przechowywane w tabelach, bo cały model relacyjny opiera się właśnie na pojęciu tabeli (relacji). Tabela to po prostu uporządkowany zbiór wierszy i kolumn: kolumny opisują strukturę danych (np. id, imię, nazwisko, email), a wiersze przechowują konkretne rekordy, czyli pojedyncze wpisy. Każda kolumna ma określony typ danych, np. INTEGER, VARCHAR, DATE, co pozwala silnikowi bazy danych kontrolować poprawność zapisów i optymalizować zapytania. Tak to działa w typowych systemach jak MySQL, PostgreSQL, SQL Server czy Oracle – wszędzie podstawową jednostką przechowywania danych użytkownika jest tabela. W praktyce, kiedy projektujesz bazę dla sklepu internetowego, tworzysz tabele takie jak users, products, orders, order_items. Potem za pomocą języka SQL wykonujesz na tych tabelach operacje SELECT, INSERT, UPDATE, DELETE. Klucze główne i obce też odnoszą się do tabel – klucz główny jednoznacznie identyfikuje wiersz w tabeli, a klucz obcy wskazuje na wiersz w innej tabeli, tworząc relację między nimi. To właśnie dzięki tabelom i relacjom możesz łączyć dane z wielu miejsc, np. pobrać zamówienia wraz z danymi klienta jednym zapytaniem. Moim zdaniem warto od początku myśleć o tabeli jak o odpowiedniku arkusza w Excelu, tylko z dużo bardziej rygorystycznymi zasadami i możliwością zaawansowanych zapytań. Standard SQL zakłada, że operujemy na relacjach, a w implementacjach relacja = tabela. Dlatego odpowiedź „tabelach” jest zgodna zarówno z teorią modelu relacyjnego, jak i z praktyką codziennej pracy z bazami danych.
W modelu relacyjnych baz danych kluczowe jest zrozumienie, że podstawową strukturą przechowywania danych jest tabela, a nie ogólne pojęcia typu lista, kolejka czy wektor. Te inne struktury występują częściej w programowaniu, w kodzie aplikacji, a nie jako główny element fizycznej organizacji danych w systemach takich jak MySQL czy PostgreSQL. Lista kojarzy się z prostym zbiorem elementów zapisanych jeden po drugim, bez sztywnych kolumn i typów danych. W kodzie możemy mieć listę obiektów użytkowników, ale kiedy te dane trafiają do relacyjnej bazy, lądują w tabeli z jasno zdefiniowanymi kolumnami. Baza danych musi zapewnić integralność, indeksy, klucze, możliwość złożonych zapytań SQL – zwykła lista tego nie ogarnia. Kolejka z kolei to struktura typu FIFO, używana np. w systemach kolejkowania zadań, komunikatach między serwisami, przetwarzaniu asynchronicznym. W bazach danych można co najwyżej zaimplementować logikę działania kolejki na tabeli (np. kolumna status, czas dodania, pobieranie najstarszego zadania), ale fizycznie to dalej jest tabela, a nie specjalny typ „kolejka” w sensie modelu relacyjnego. Wektor natomiast to pojęcie bardziej z matematyki i programowania niskopoziomowego, czasem używane jako tablica dynamiczna. W silnikach baz danych oczywiście istnieją wewnętrzne struktury w pamięci, jakieś tablice, strony danych, indeksy, ale użytkownik pracuje z tabelami, relacjami, widokami. Typowym błędem myślowym jest przenoszenie pojęć z programowania obiektowego czy struktur danych 1:1 do świata relacyjnych baz. W praktyce, niezależnie od tego, czy obsługujesz system CRM, sklep internetowy czy prosty blog, zawsze kończysz z tabelami: użytkownicy, posty, komentarze, produkty itd. Reszta struktur, takich jak listy czy kolejki, to bardziej narzędzia w warstwie aplikacji, nie fundament modelu relacyjnego. Dlatego przy pytaniach o relacyjne bazy danych warto automatycznie myśleć o tabelach, kolumnach, wierszach i kluczach, bo to jest absolutna podstawa pracy z SQL.