Poprawna odpowiedź to „raport”, bo właśnie ten obiekt bazy danych jest przeznaczony typowo do estetycznego drukowania lub wyświetlania gotowych zestawień danych. W typowych systemach bazodanowych, takich jak Microsoft Access czy różne narzędzia klasy RAD, formularze służą głównie do wprowadzania i edycji danych, kwerendy do ich wyszukiwania i filtrowania, a raporty do prezentacji wyników w uporządkowanej, czytelnej formie. Raport ma własny projekt układu: nagłówki, stopki, grupowanie po polach (np. po kliencie, dacie, dziale), sumy częściowe i końcowe, numerację stron, a często także pola obliczeniowe. To jest dokładnie to, czego potrzebujemy, gdy chcemy przygotować np. wydruk faktur, miesięczne zestawienie sprzedaży, raport obecności pracowników albo raport kasowy do działu księgowości. Z mojego doświadczenia raport traktuje się jako końcowy produkt pracy z danymi – użytkownika końcowego zwykle nie interesują tabele czy relacje, tylko czy dostanie przejrzysty wydruk lub PDF, który można wysłać dalej. Dobre praktyki mówią, żeby w raportach nie upychać logiki biznesowej ani skomplikowanych obliczeń, tylko oprzeć je na dobrze przygotowanych kwerendach. Raport powinien być możliwie prosty, czytelny i stabilny – tak, żeby zmiana sposobu liczenia odbywała się w warstwie zapytań, a nie w każdym raporcie osobno. W narzędziach BI (np. Power BI, Tableau, ale też klasyczne Crystal Reports) idea jest podobna: raport to warstwa prezentacji, która korzysta z danych z bazy, modelu analitycznego albo widoków SQL. W praktyce w firmach raporty są podstawą podejmowania decyzji, więc poprawne zrozumienie ich roli w bazie danych jest naprawdę kluczowe.
W tym pytaniu łatwo się pomylić, bo w bazach danych mamy kilka typów obiektów, które „coś pokazują” użytkownikowi. Kluczowe jest jednak rozróżnienie: czym innym jest narzędzie do automatyzacji, czym innym interfejs do wprowadzania danych, a czym innym obiekt przeznaczony typowo do drukowania i prezentacji zestawień. Makro w bazie danych służy głównie do automatyzacji czynności: otwarcie formularza, uruchomienie kwerendy, wydruk raportu, eksport danych do pliku i tym podobne rzeczy. To jest taki prostszy mechanizm skryptowy, który pozwala zdefiniować sekwencję akcji bez pisania klasycznego kodu w języku programowania. Makro samo z siebie nie jest obiektem do drukowania danych, raczej „wywołuje” inne obiekty, na przykład raport, który dopiero generuje wydruk. Moduł z kolei to już typowo programistyczny element – w Accessie jest to moduł VBA (Visual Basic for Applications). Tam umieszcza się procedury, funkcje, bardziej złożoną logikę biznesową, obsługę zdarzeń. Moduł działa w tle, nie jest przeznaczony do bezpośredniej prezentacji danych użytkownikowi, tylko do ich przetwarzania, walidacji, sterowania działaniem aplikacji bazodanowej. Wybór modułu oznacza pomieszanie warstwy logiki z warstwą prezentacji. Formularz często kusi jako odpowiedź, bo też „wyświetla dane”. Jednak jego głównym celem jest interakcja: wprowadzanie, edycja, przeglądanie rekordów, czasem proste filtrowanie. Formularz jest zoptymalizowany do pracy na pojedynczych rekordach lub niewielkich listach, a nie do tworzenia eleganckich, wielostronicowych zestawień z nagłówkami, stopkami, grupowaniem i sumami. Typowy błąd myślowy polega na tym, że skoro coś widać na ekranie, to znaczy, że nadaje się do drukowania raportów. W praktyce w poprawnie zaprojektowanej bazie formularze służą do pracy bieżącej z danymi, a raporty – do tworzenia końcowych dokumentów: wydruków, plików PDF, załączników do maili. Właśnie dlatego właściwą odpowiedzią jest raport, bo to on jest standardowym obiektem bazy danych zaprojektowanym specjalnie do prezentacji zestawionych danych w formie wydruku lub podglądu.