SQL: jak jeden papier z 1970 roku opanował świat danych

Edgar F. Codd i rewolucyjny papier z 1970 roku

Edgar Frank Codd urodził się w 1923 roku w Anglii, ale to w laboratoriach IBM w San Jose zmienił historię informatyki. W czerwcu 1970 roku opublikował artykuł zatytułowany A Relational Model of Data for Large Shared Data Banks w prestiżowym piśmie Communications of the ACM. Liczył zaledwie kilkanaście stron. Zrewolucjonizował cały świat danych.

Codd był matematykiem z wykształcenia i podszedł do problemu przechowywania danych jak do zagadnienia algebry. Zaproponował, by dane były przechowywane w tabelach (zwanych relacjami) z wierszami i kolumnami, a nie w hierarchicznych strukturach, które dominowały w ówczesnej branży. Każda tabela miała klucz główny, tabele mogły być ze sobą powiązane za pomocą kluczy obcych. Operacje na danych miały opierać się na algebrze relacji – precyzyjnym matematycznym fundamencie.

Brzmi znajomo? Właśnie tak działają do dziś wszystkie popularne bazy danych – od MySQL przez PostgreSQL po Microsoft SQL Server. Codd stworzył model, który przetrwał próbę czasu dłużej, niż ktokolwiek mógł się spodziewać. W 1981 roku otrzymał za to Nagrodę Turinga – informatyczny odpowiednik Nagrody Nobla.

IBM kontra własny wynalazek – historia korporacyjnej krótkowzroczności

Tu zaczyna się zaskakująca część historii. IBM – firma, która zatrudniała Codda – nie spieszyła się z wdrożeniem jego odkrycia. Powód był prosty i bardzo ludzki: strach przed kanibalizacją własnego produktu.

W 1970 roku IBM zarabiał krocie na hierarchicznym systemie baz danych IMS (Information Management System), który powstawał jeszcze przy programie Apollo NASA. Klientami IMS były największe banki i korporacje świata. Uruchomienie relacyjnej bazy danych – lepszej od IMS – oznaczało uderzenie we własny, dochodowy biznes.

IBM zezwolił Coddowi na badania, ale projekt relacyjnej bazy danych – wewnętrznie nazwany System R i towarzyszący mu język SEQUEL – traktował jako akademicki eksperyment, bez priorytetowego finansowania. Codd przez wiele lat bezskutecznie walczył o komercjalizację swojego wynalazku we własnej firmie. Kiedy IBM w końcu wydał DB2 w 1983 roku, konkurencja była już daleko z przodu. Historycy IT uznają tę decyzję za jeden z najdroższych błędów strategicznych w historii branży.

Larry Ellison: człowiek, który przeczytał właściwy artykuł

W 1977 roku Larry Ellison – sprzedawca oprogramowania z San Francisco, bez dyplomu wyższej uczelni – natknął się na artykuł opisujący projekt System R IBM i język SEQUEL. Ellison zrozumiał coś, czego IBM zdawał się nie dostrzegać: to jest przyszłość przechowywania danych, a IBM sami nie chcą jej zbudować.

Razem z Bobem Minerem i Edem Oatesem założył firmę Software Development Laboratories (późniejszą Relational Software Inc., a w końcu Oracle Corporation). Cel był jasny: stworzyć komercyjną relacyjną bazę danych, zanim IBM zdąży to zrobić.

Oracle Database 2.0 – pierwsza wersja sprzedawana komercyjnie – ukazała się w 1979 roku. IBM wydał własny produkt komercyjny cztery lata później. Ellison wygrał wyścig z firmą, która wynalazła samą technologię. Dziś Oracle Corporation jest warta ponad 400 miliardów dolarów.

Mała ciekawostka: Oracle Database 2.0 był pierwszą wersją sprzedawaną publicznie – wersja 1.0 nigdy nie istniała oficjalnie. Ellison obawiał się, że klienci nie zaufają produktowi oznaczonemu jako pierwsza wersja, więc po prostu zaczął numerację od dwójki.

SEQUEL staje się SQL – narodziny języka dla niewtajemniczonych

Język, który Codd koncepcyjnie opisał, IBM rozwinął w ramach projektu System R jako SEQUEL – Structured English QUEry Language. Nazwa była jednak zarejestrowanym znakiem towarowym brytyjskiej firmy lotniczej Hawker Siddeley, więc IBM skrócił ją do SQL (Structured Query Language). Wymowa sequel pozostała do dziś u milionów programistów na całym świecie.

SQL miał być językiem dla osób nieznających programowania – czymś w rodzaju angielskiego dla baz danych. Polecenie SELECT * FROM zamowienia WHERE kwota > 1000 było zrozumiałe nawet bez technicznego wykształcenia. To był przełom: wcześniejsza praca z bazami danych wymagała znajomości skomplikowanych, niskopoziomowych interfejsów programistycznych.

W 1986 roku American National Standards Institute (ANSI) uznał SQL za oficjalny standard języka relacyjnych baz danych. Rok później zrobiło to ISO. Od tej chwili SQL przestał być produktem jednej firmy – stał się otwartym standardem całej branży informatycznej i fundamentem, na którym każdy mógł budować własne systemy.

NoSQL kontra SQL – starcie, którego wynik cię zaskoczy

W latach 2000–2010 wydawało się, że SQL ma poważnego konkurenta. Ruch NoSQL (Not Only SQL) przyniósł bazy danych takie jak MongoDB, Cassandra czy Redis, które porzucały tabelaryczną strukturę na rzecz dokumentów, par klucz-wartość lub grafów. Twórcy gigantycznych aplikacji internetowych – Facebook, Amazon, Google – chwalili sobie ich elastyczność i skalowalność przy miliardach rekordów.

Jednak SQL nie zniknął. Stało się coś zaskakującego: wiele systemów NoSQL w końcu samo dodało obsługę SQL. Amazon Redshift, Google BigQuery, Apache Spark – wszystkie przyjęły SQL jako główny język zapytań dla analityki. Okazało się, że dekady szkolenia programistów i analityków danych w SQL to zbyt duży kapitał ludzkości, by go porzucić.

Dziś SQL jest dosłownie wszędzie:

• MySQL i PostgreSQL napędzają miliony stron internetowych i aplikacji
• Microsoft SQL Server stoi za systemami ERP i CRM w firmach na całym świecie
• SQLite jest wbudowany w każdy iPhone, każde urządzenie z Androidem i każdą przeglądarkę Chrome – to prawdopodobnie najszerzej wdrożona baza danych w całej historii informatyki
• Nowoczesne narzędzia AI korzystają z SQL do odpytywania hurtowni danych i warstw analitycznych

Co historia SQL mówi firmom o wyborze technologii

Historia SQL to doskonała lekcja dla każdego, kto zarządza IT w firmie. Technologia, która przetrwała ponad 50 lat, zawdzięcza sukces nie tylko technicznej doskonałości – lecz otwartej standaryzacji, szerokiej adopcji i czytelności dla człowieka. SQL był zaprojektowany tak, by mogli go rozumieć ludzie, a nie tylko maszyny.

Dla małych i średnich firm ta historia niesie konkretny wniosek: warto stawiać na sprawdzone, standaryzowane technologie z szerokim ekosystemem wsparcia. Relacyjne bazy danych napędzają większość systemów ERP, CRM, aplikacji fakturowania i platform branżowych. Niezależnie od tego, czy korzystasz z oprogramowania pudełkowego, czy zamawiasz rozwiązanie szyte na miarę – za kulisami niemal na pewno pracuje SQL.

Warto wiedzieć, jak te bazy danych są skonfigurowane, kto ma do nich dostęp i czy są objęte kopią zapasową. Jeśli nie jesteś tego pewien, audyt IT od NovaSys pozwoli sprawdzić nie tylko warstwę bazodanową, ale całe środowisko technologiczne Twojej firmy – zanim ewentualny problem stanie się kosztowną awarią.