Przejrzysta historia relacyjnych baz danych — od Codda i SQL, przez ACID i ERP — wyjaśniająca, dlaczego napędzają większość aplikacji biznesowych i gdzie mają ograniczenia.
Aplikacja biznesowa to każdy system, który utrzymuje codzienne operacje: przyjmuje zamówienia, wystawia faktury, śledzi klientów, zarządza zapasami, płaci dostawcom i raportuje, co się wydarzyło w zeszłym tygodniu (albo dziś rano). Niezależnie od tego, czy to system ERP obsługujący zakupy i finanse, czy oprogramowanie CRM porządkujące aktywność sprzedaży, wszystkie te aplikacje mają wspólny wymóg: liczby i zapisy muszą odpowiadać rzeczywistości.
Relacyjna baza danych przechowuje informacje w tabelach — pomyśl o arkuszach, ale z surowszymi zasadami. Każda tabela ma wiersze (pojedyncze rekordy) i kolumny (pola takie jak nazwa klienta, data zamówienia czy cena). Tabele łączą się ze sobą za pomocą kluczy: identyfikator klienta w tabeli Customers może być odwołany przez tabelę Orders, dzięki czemu system wie, które zamówienia należą do którego klienta.
Ta struktura wydaje się prosta, ale jest potężna: pozwala aplikacji biznesowej utrzymać porządek w danych, nawet gdy wiele osób i procesów jednocześnie je modyfikuje.
Relacyjne bazy danych stały się standardowym fundamentem aplikacji biznesowych z kilku praktycznych powodów:
Systemy relacyjne mają wyraźne mocne strony — zwłaszcza integralność danych i niezawodne transakcje — ale też kompromisy w zakresie elastyczności i skalowania. Omówimy, dlaczego dobrze pasują do klasycznej pracy OLTP, gdzie alternatywy wypadają lepiej i co się zmienia wraz z zarządzanymi bazami w chmurze oraz nowymi potrzebami danych.
Zanim relacyjne bazy stały się powszechne, większość danych biznesowych żyła w patchworku plików: arkusze na współdzielonych dyskach, pliki tekstowe eksportowane z narzędzi księgowych i niestandardowe formaty stworzone przez dostawców lub programistów wewnętrznych.
To działało, gdy firma była mała i tylko kilka osób potrzebowało dostępu. Ale gdy sprzedaż, finanse i operacje zaczęły polegać na tych samych informacjach, przechowywanie w plikach zaczęło się kruszyć.
Wiele organizacji polegało na:
Największym problemem nie była tylko niedogodność — chodziło o zaufanie. Duplikaty danych były wszędzie: ten sam klient mógł występować trzykrotnie z lekko różnymi nazwami, adresami lub warunkami płatności.
Aktualizacje były niespójne, bo zależały od pamiętania przez ludzi, by zmienić każdą kopię. Nowy numer telefonu mógł zostać zaktualizowany w arkuszu sprzedaży, ale nie w rozliczeniach, co prowadziło do przegapionych płatności lub opóźnień w wysyłce.
Raportowanie było trudne, ponieważ pliki nie były zaprojektowane do pytań typu "Którzy klienci zalegają i mają jednocześnie otwarte zamówienia?". Odpowiedź wymagała ręcznych wyszukiwań, długich formuł w arkuszach lub skryptów, które psuły się przy zmianie układu plików.
Pliki słabo radzą sobie z jednoczesnymi edycjami. Dwie osoby edytujące ten sam rekord mogły nadpisać swoje zmiany, a "blokowanie" pliku często oznaczało, że wszyscy inni musieli czekać. Wydajność też malała wraz ze wzrostem rozmiaru plików, zwłaszcza w sieci.
Firmy potrzebowały wspólnego źródła prawdy z zasadami (by dane pozostały poprawne) i niezawodnych aktualizacji (by zmiany albo zachodziły w całości, albo wcale). To przygotowało grunt pod relacyjne bazy danych i przesunięcie od "danych w dokumentach" do "danych jako zarządzanego systemu".
W 1970 roku badacz IBM Edgar F. "Ted" Codd zaproponował model relacyjny — pomysł, który zmienił sposób, w jaki firmy przechowują i wykorzystują dane. Przełom nie polegał na nowym nośniku czy szybszym komputerze. To była prostsza metoda myślenia o danych, dzięki której można je zarządzać spójnie, nawet gdy potrzeby biznesowe się zmieniają.
W centrum modelu relacyjnego jest proste pojęcie: organizuj informacje w relacjach, które dziś większość osób rozumie jako tabele. Tabela zawiera wiersze (rekordy) i kolumny (pola). Klienci trafiają do jednej tabeli, faktury do innej, produkty do kolejnej.
Co sprawiło, że to było potężne, to nie tylko sam format tabeli — to zasady wokół niej:
Taka struktura ułatwiła walidację danych, łączenie ich i utrudniła przypadkowe sprzeczności.
Wcześniejsze systemy często „wbudowywały" reguły biznesowe i formaty danych w samą aplikację. Jeśli zmieniałeś oprogramowanie, ryzykowałeś zepsucie sposobu odczytu plików. Jeśli zmieniałeś format pliku, trzeba było przepisać część oprogramowania.
Model relacyjny zachęcał do czystego rozdziału: baza danych zarządza danymi i ich integralnością; aplikacje żądają danych i aktualizują je przez dobrze zdefiniowane operacje.
To ma znaczenie, bo biznesy rzadko stoją w miejscu. Zmieniają się zasady cenowe, pola klienta ewoluują, rosną wymagania raportowe. Dzięki relacyjnej bazie wiele zmian można wprowadzić w schemacie bazy lub w zapytaniach bez przebudowy całej aplikacji.
Gdy dane są przechowywane w tabelach ze spójnymi zasadami, stają się bardziej przenośne i trwałe:
Dlatego model relacyjny stał się naturalnym wyborem dla oprogramowania biznesowego: przemienił nieuporządkowane, specyficzne dla aplikacji dane w uporządkowany system, który przetrwa lata wzrostu i zmian.
Relacyjne bazy zdobyły zaufanie, bo dają danym niezawodną „tożsamość" i kontrolowany sposób łączenia rekordów. Tą tożsamością jest klucz, a połączeniami są relacje.
Primary key jednoznacznie identyfikuje wiersz w tabeli. W tabeli Customers może to być CustomerID.
Customers(CustomerID, Name, Email)Orders(OrderID, CustomerID, OrderDate, Total)Tu CustomerID to stabilny identyfikator klienta, a nie coś, co się zmienia (jak nazwa) albo nie jest unikatowe (jak email).
Foreign key to pole odwołujące się do primary key w innej tabeli. W Orders, CustomerID wskazuje na Customers.CustomerID.
Taka struktura zapobiega powielaniu danych klienta w każdym wierszu zamówienia. Zamiast kopiować Name i Email do każdego zamówienia, przechowujesz je raz i łączysz zamówienia z właściwym klientem.
Skoro baza zna powiązania między tabelami, możesz je łączyć (join), by odpowiadać na codzienne pytania:
Dostajesz kompletne wyniki przez łączenie tabel w czasie zapytania, zamiast utrzymywać wiele kopii tych samych faktów.
Bazy relacyjne mogą wymuszać integralność referencyjną: zamówienie nie może wskazywać klienta, który nie istnieje. To zapobiega rekordom-sierotom (zamówienia bez ważnego klienta) i blokuje przypadkowe usunięcia, które pozostawiłyby uszkodzone powiązania.
Gdy klucze, relacje i zasady integralności są na miejscu, raporty przestają się kłócić z operacjami. Sumy nie zmieniają się z powodu zduplikowanych rekordów klientów, a zespoły wsparcia spędzają mniej czasu na tropieniu „tajemniczych błędów" spowodowanych brakującymi lub niepasującymi identyfikatorami.
Normalizacja to w zasadzie projektowanie danych tak, by unikać powielania faktów. To zestaw praktyk, które zapobiegają kopiowaniu tej samej informacji w wielu miejscach — bo każda kopia to kolejna szansa na jej rozjechanie się.
Wyobraź sobie aplikację biznesową przechowującą zamówienia. Jeśli każdy wiersz zamówienia zawiera pełny adres wysyłkowy klienta, ten adres będzie się powtarzał wielokrotnie. Gdy klient się przeprowadzi, ktoś musi zaktualizować wszystkie stare i przyszłe rekordy (albo aplikacja musi zgadywać, które wiersze zmienić). Jeśli przegapisz choć jeden, raporty zaczną pokazywać dwie różne wersje tej samej prawdy.
Przy normalizacji zwykle przechowujesz adres klienta raz w tabeli Customers, a każde zamówienie odwołuje się do klienta przez identyfikator. Teraz jest jedno miejsce do aktualizacji i każde zamówienie pozostaje spójne.
Kilka elementów powtarza się w większości systemów biznesowych:
order_status z "Pending", "Shipped", "Cancelled"). Redukują literówki i pozwalają kontrolować zmiany.OrderItems łączy je czytelnie.Większa normalizacja zwykle poprawia spójność, ale może oznaczać więcej tabel i więcej joinów. Nadmierna normalizacja może utrudnić pisanie niektórych zapytań i spowolnić ich wykonanie — więc zespoły często balansują między "czystą strukturą" a praktycznymi potrzebami raportowania i wydajności aplikacji.
Relacyjne bazy nie tylko schludnie przechowywały dane — uczyniły je też możliwymi do zapytania wspólnym językiem. SQL (Structured Query Language) dał firmom wspólny sposób wyciągania odpowiedzi z tabel bez przepisywania programu dla każdego nowego raportu.
Zanim SQL się upowszechnił, zapytania często oznaczały polecenia specyficzne dla dostawcy lub jednorazowe skrypty, które rozumiał tylko nieliczny zespół. Standardowy język zapytań to zmienił. Analitycy, programiści i narzędzia raportowe mogli wszyscy "mówić" do tej samej bazy tym samym rdzeniem składni.
Ta standaryzacja zmniejszyła tarcie między zespołami. Zapytanie napisane dla finansów mogło być użyte przez operacje. Narzędzie raportowe mogło łączyć się z różnymi bazami przy minimalnych zmianach. Z czasem umiejętność SQL stała się przenośna między stanowiskami i branżami — co przyspieszyło jej adopcję.
SQL błyszczy, bo dobrze odwzorowuje typowe pytania biznesowe:
To podstawowe operacje filtrowania, sortowania, grupowania i łączenia powiązanych danych — dokładnie to, do czego zaprojektowano SQL.
Gdy SQL stał się powszechny, wyrosło wokół niego całe ekosystemy: pulpity BI, harmonogramy raportów, konektory do arkuszy i później hurtownie danych oraz narzędzia ETL. Nawet gdy firmy dodawały wyspecjalizowane systemy analityczne, SQL często pozostawał mostem między danymi operacyjnymi a decyzjami — bo już był językiem, na którym można polegać.
Gdy aplikacja biznesowa "wydaje się" niezawodna, zwykle dlatego, że baza potrafi bezpiecznie obsłużyć zmiany — szczególnie gdy w grę wchodzą pieniądze, zapasy i zobowiązania wobec klientów.
Wyobraź sobie zamówienie online:
Transakcja oznacza, że wszystkie te aktualizacje traktowane są jako jedna jednostka pracy. Jeśli coś zawiedzie w połowie (odrzucona płatność, awaria systemu, brak towaru), baza może cofnąć zmiany i pozostawić zapisy w czystym, spójnym stanie — bez "zapłacono, ale brak zamówienia", bez ujemnego stanu, bez brakującej faktury.
Firmy ufają relacyjnym bazom, ponieważ większość z nich wspiera zachowania zgodne z ACID — proste zasady utrzymujące niezawodność zapisów:
W oprogramowaniu biznesowym wiele osób pracuje jednocześnie: handlowcy przygotowują oferty, magazynierzy kompletują zamówienia, finanse zamykają księgi, wsparcie wystawia zwroty. Bez solidnej kontroli współbieżności dwie osoby mogłyby sprzedać ostatni egzemplarz albo nadpisać nawzajem swoje zmiany.
Integralność danych to praktyczny efekt: sumy finansowe się zgadzają, stany magazynowe odpowiadają rzeczywistości, a raporty zgodne z przepisami mają ślad, kto i kiedy co zmienił. Dlatego RDBMS są domyślnym miejscem dla danych będących systemem zapisu.
Większość aplikacji biznesowych nie próbuje odpowiadać na pytanie "Co się wydarzyło w tym kwartale?" za każdym razem, gdy ktoś klika przycisk. Chodzi o proste, częste operacje: tworzenie faktury, aktualizacja statusu wysyłki, rezerwacja towaru, zapis płatności. Ten wzorzec to OLTP (Online Transaction Processing) — dużo małych odczytów i zapisów z wielu źródeł przez cały dzień.
W OLTP celem są szybkie, spójne interakcje: "znajdź tego klienta", "dodaj tę pozycję", "oznacz zamówienie jako zapłacone". Zapytania zwykle dotykają niewielkiej części danych i muszą zwracać wyniki szybko.
Obciążenia analityczne są inne: mniej zapytań, ale cięższych — agregacje, skanowanie dużych zakresów i łączenia na szeroką skalę. Wiele organizacji trzyma OLTP w RDBMS i wykonuje analizy w oddzielnych systemach lub replikach, żeby nie spowalniać operacji dnia codziennego.
Indeks to spis treści tabeli. Zamiast skanować każdy wiersz, baza może szybko skoczyć do pasujących rekordów, np. customer_id = 123.
Koszt: indeksy trzeba utrzymywać. Każdy insert/update może też aktualizować indeksy, więc zbyt wiele indeksów spowalnia zapisy i zwiększa zużycie miejsca. Sztuka polega na indeksowaniu tego, po czym najczęściej filtrujesz i łączysz.
W miarę wzrostu danych i ruchu, bazy relacyjne polegają na planowaniu zapytań (wyborze efektywnego sposobu wykonania), ograniczeniach (utrzymujących poprawność danych) i narzędziach operacyjnych jak kopie zapasowe i odzyskiwanie do punktu w czasie. Te „nudne" funkcje często są tym, co pozwala systemom codziennym pozostać niezawodnymi podczas skalowania.
Brak indeksów na często używanych filtrach/łączeniach to klasyczny problem: strony szybkie przy 10k wierszy stają się wolne przy 10M.
Wzorce aplikacyjne też mają znaczenie. N+1 queries (jedno zapytanie do listy elementów, potem jedno zapytanie na element, by pobrać szczegóły) potrafią przytłoczyć bazę. A nadmierne łączenie wielu tabel "na wszelki wypadek" często tworzy zbędną pracę. Utrzymywanie zapytań celowych i testowanie na danych przypominających produkcję zwykle daje największe korzyści.
ERP i CRM nie przyjęły relacyjnych baz tylko dlatego, że były popularne — potrzebowały rodzaju spójności, którą wymuszają tabele, klucze i relacje.
Większość kluczowych procesów biznesowych jest ustrukturyzowana i powtarzalna: klient składa zamówienie, wystawiana jest faktura, rejestrowana płatność, towar jest kompletowany, wysyłany i zwracany. Każdy krok naturalnie mapuje się na byty opisane w wierszach i kolumnach — klienci, produkty, faktury, płatności, pracownicy, lokalizacje.
Relacyjny projekt ułatwia też wzajemne kontroli: faktura nie może istnieć bez klienta; pozycja wysyłki powinna odnosić się do rzeczywistego produktu; płatność powinna wiązać się z fakturą. Systemy ERP (finanse, zaopatrzenie, zapasy) i CRM (konta, kontakty, szanse, zgłoszenia wsparcia) polegają na tych "to musi odnosić się do tamtego" regułach, by utrzymać zgodność zapisów między zespołami.
W miarę wzrostu organizacji stawiano pytanie:
Oba podejścia zyskują na jasnych schematach: gdy pola i relacje są explicite, łatwiej synchronizować identyfikatory klientów, kody produktów i wymiary księgowe bez ciągłych ręcznych poprawek.
Gdy dostawcy ERP i CRM ujednolicili fundamenty relacyjne, firmy zyskały przenośność umiejętności. Zatrudnienie analityka znającego SQL — i szkolenie zespołów operacyjnych w korzystaniu ze standardowych raportów — stało się znacznie łatwiejsze niż uczenie narzędzi własnych każdego dostawcy.
Ta standaryzacja obniżyła koszty długoterminowe: mniej niestandardowych eksportów danych, więcej wzorców raportowania do ponownego użycia i prostsze przekazy zadań między administratorami, konsultantami i zespołami wewnętrznymi. Dla wielu firm to właśnie przemieniło relacyjne bazy danych z wyboru technicznego w operacyjny domyślny standard.
Relacyjne bazy wygrały nie tylko dzięki modelowaniu danych — pasowały też do sposobu, w jaki organizacje prowadzą systemy produkcyjne. Od początku RDBMS dostarczały przewidywalne procedury operacyjne: zaplanowane kopie zapasowe, role użytkowników, katalogi systemowe, logi i narzędzia, które ułatwiały utrzymanie bezpiecznych i rozliczalnych danych biznesowych.
Baza biznesowa jest tak wiarygodna, jak jej odzyskiwanie. Narzędzia RDBMS standaryzowały podejścia jak pełne kopie, kopie przyrostowe i odzyskiwanie do punktu w czasie przy użyciu logów transakcyjnych. Dzięki temu zespoły mogły testować procedury przywracania, dokumentować je i powtarzać podczas incydentów — to krytyczne dla list płac, fakturowania, zapasów i zapisów klientów.
Monitorowanie też stało się normalną częścią pracy: śledzenie wzrostu przestrzeni, wolnych zapytań, konfliktów blokad i stanu replikacji. Gdy problemy można zmierzyć, można nimi zarządzać.
Większość platform RDBMS uczyniła kontrolę dostępu funkcją pierwszej klasy. Zamiast przekazywać wspólne hasło, administratorzy mogą tworzyć konta, grupować je w role i nadawać uprawnienia na poziomie bazy, tabeli, a czasem nawet wiersza.
Dwa podstawy nadzoru są szczególnie ważne:
Ta struktura wspiera zgodność bez zamieniania codziennej pracy w ciąg wyjątków.
Audyt RDBMS — przez logi, tabele systemowe i czasem wbudowane funkcje audytu — pomaga odpowiedzieć na pytanie "kto, co i kiedy zmienił". To przydatne przy rozwiązywaniu problemów, dochodzeniach bezpieczeństwa i procesach regulacyjnych.
W zakresie zmian dojrzałe zespoły polegają na powtarzalnych migracjach: skryptowane zmiany schematu przeglądane w kontroli wersji i stosowane konsekwentnie w środowiskach. W połączeniu z akceptacją i planami rollbacku zmniejsza to ryzyko nocnych poprawek, które cicho psują raportowanie lub integracje.
Praktyki administracyjne przekształciły się w wzorce, które firmy mogły ustandaryzować: replikacja dla redundancji, failover dla wysokiej dostępności i plany odzyskiwania po katastrofie zakładające utratę całego centrum danych lub regionu chmurowego. Te elementy operacyjne uczyniły relacyjne bazy bezpiecznym wyborem dla krytycznych systemów.
Usługi chmurowe nie zastąpiły relacyjnych baz tak bardzo, jak zmieniły sposób ich prowadzenia. Zamiast kupować serwery, instalować oprogramowanie i planować okna konserwacji, wiele firm korzysta z zarządzanych ofert RDBMS, gdzie dostawca przejmuje część prac operacyjnych.
Zarządzane bazy relacyjne zazwyczaj obejmują automatyczne kopie zapasowe, odzyskiwanie do punktu w czasie (przewiń bazę do momentu przed błędem), automatyczne łatki i monitorowanie. Dla wielu aplikacji biznesowych to oznacza mniej nocnych prób odzyskiwania i bardziej przewidywalne plany przywracania po awarii.
Skalowanie też stało się bardziej elastyczne. Często można zwiększyć CPU, pamięć i przestrzeń przez parę ustawień zamiast migracji sprzętowej. Niektóre platformy wspierają też skalowanie odczytów — dodawanie replik do odczytu, by pulpity i ciężkie wyszukiwania nie spowalniały rejestracji zamówień czy obsługi klienta.
Replikacja to utrzymywanie kopii bazy w synchronizacji. Wysoka dostępność używa replikacji, by zmniejszyć czas przestoju: jeśli główna baza padnie, zapasowa przejmuje pracę. To ma znaczenie dla systemów, które muszą dalej przyjmować płatności, rejestrować wysyłki lub aktualizować zapasy, mimo awarii.
Gdy firmy obsługują użytkowników na całym świecie, opóźnienia stają się realnym problemem: im dalej klienci, tym wolniejsze odczucia przy żądaniach. Równocześnie mikroserwisy i systemy oparte na zdarzeniach dzielą jedną dużą aplikację na wiele mniejszych usług, z własnymi potrzebami danych i cyklami wydawniczymi.
Wiele zespołów trzyma RDBMS jako źródło prawdy dla kluczowych zapisów (klienci, faktury, salda) i dodaje inne narzędzia do konkretnych zadań — silniki wyszukiwania do szybkiego przeszukiwania tekstu, cache do przyspieszania odczytów czy hurtownie analityczne do dużego raportowania. Dzięki temu integralność danych jest tam, gdzie ma znaczenie, a jednocześnie spełniane są nowe potrzeby wydajności i integracji. Więcej o spójności znajdziesz we wpisie o transakcjach i ACID.
W praktyce to też kształtuje sposób budowania nowych narzędzi wewnętrznych. Platformy takie jak Koder.ai wykorzystują podejście "relacyjne jądro + nowoczesna aplikacja": możesz vibe-code'ować aplikacje webowe (React), backendy (Go) i systemy zapisu oparte na PostgreSQL za pomocą interfejsu czatu — a następnie iterować bezpiecznie ze snapshotami i rollbackiem przy zmianach schematu, migracjach czy przepływach pracy.
Relacyjne bazy nie są idealne do każdego obciążenia. Ich siła — silna struktura, spójność i przewidywalne zasady — może być też ograniczeniem, gdy dane lub wzorzec użycia nie pasują do tabel.
Niektóre scenariusze wystawiają model RDBMS na próbę:
Systemy NoSQL zyskały popularność, ponieważ często łatwiej przechowują elastyczne kształty danych i skalują horyzontalnie. Wiele z nich rezygnuje z części gwarancji spójności lub bogactwa zapytań, by osiągnąć prostszą dystrybucję, szybsze zapisy lub łatwiejszą ewolucję schematu — przydatne w produktach konsumenckich, pipeline'ach analitycznych i zbieraniu dużych wolumenów zdarzeń.
Współczesne stosy danych mieszają podejścia:
Jeśli śledzisz pieniądze, zamówienia, zapasy, konta klientów lub cokolwiek wymagającego jasnych reguł i niezawodnych aktualizacji, RDBMS zwykle jest najbezpieczniejszym punktem wyjścia. Alternatywy warto stosować, gdy obciążenie naprawdę tego wymaga — nie tylko dlatego, że są modne.
W oprogramowaniu biznesowym potrzebujesz jednego źródła prawdy dla takich rzeczy jak klienci, zamówienia, faktury, płatności i stan magazynu.
Relacyjne bazy danych zostały zaprojektowane tak, by utrzymywać spójne zapisy podczas gdy wielu użytkowników i procesów jednocześnie czyta i zapisuje dane — dzięki temu raporty zgadzają się z operacjami, a liczby się bilansują.
Relacyjna baza danych przechowuje dane w tabelach (wiersze i kolumny) z jasno określonymi zasadami.
Tabele łączą się przy pomocy kluczy (na przykład Orders.CustomerID odwołuje się do Customers.CustomerID), dzięki czemu baza może niezawodnie łączyć powiązane rekordy bez kopiowania tych samych szczegółów w wielu miejscach.
Przechowywanie w plikach nie sprawdza się, gdy wiele działów potrzebuje tych samych danych.
Typowe problemy to:
Głównego klucza (primary key) używa się jako unikatowego, stabilnego identyfikatora wiersza (np. CustomerID).
Klucz obcy (foreign key) to pole, które wskazuje na primary key w innej tabeli (np. Orders.CustomerID wskazuje na Customers.CustomerID).
Razem zapobiegają „mystery links” i pozwalają łączyć dane w sposób wiarygodny.
Integralność referencyjna oznacza, że baza wymusza poprawne relacje.
W praktyce pomaga to przez:
Normalizacja to projektowanie tabel tak, aby ta sama informacja nie była przechowywana w wielu miejscach.
Typowy przykład: adres klienta przechowujesz raz w Customers, a zamówienia odnoszą się do niego przez CustomerID. Dzięki temu jedna aktualizacja poprawia dane we wszystkich miejscach i zmniejsza dryft między kopiami tej samej prawdy.
SQL uczynił dane biznesowe możliwymi do zapytania w ustandaryzowany sposób między dostawcami i narzędziami.
Szczególnie dobrze nadaje się do codziennych pytań, które obejmują filtrowanie, grupowanie i łączenie, na przykład:
Transakcja grupuje wiele zmian w jedną operację typu wszystko albo nic.
W procesie zamówienia może to obejmować utworzenie zamówienia, zapis płatności i zmniejszenie stanu magazynowego. Jeśli coś zawiedzie w połowie, baza potrafi cofnąć zmiany, by nie mieć sytuacji typu zapłacono, ale nie ma zamówienia lub ujemny stan magazynu.
OLTP (Online Transaction Processing) to wzorzec dla większości aplikacji biznesowych: wiele małych, szybkich odczytów i zapisów wykonywanych przez wielu użytkowników.
Relacyjne bazy danych dobrze sobie z tym radzą dzięki indeksom, kontroli współbieżności i przewidywalnemu wykonywaniu zapytań — więc podstawowe operacje (realizacja zamówienia, wystawienie faktury, aktualizacja) są szybkie i niezawodne.
Relacyjne bazy mogą mieć trudności w scenariuszach takich jak:
W praktyce wiele zespołów stosuje podejście hybrydowe: RDBMS jako system zapisu, a dodatkowe magazyny (wyszukiwarki, cache, hurtownie danych) tam, gdzie są potrzebne.