Na początku lat 80. moc przetwarzania komputerów osobistych wzrosła na tyle, że zaczęto ich używać do obsługi niewielkich baz danych. Aby dane takie mogły być dostępne dla wielu użytkowników trzeba było poczekać na rozwój instalacji sieciowych. W takiej sieciowej konfiguracji bazy danych zostały zapisane na twardym dysku wyróżnionego komputera zwanego file-serwerem, czy składnicą plików. Podłączeni do file-serwera użytkownicy komputerów osobistych mogli wspólnie korzystać z jego zasobów.

Nie było to jednak rozwiązanie najszczęśliwsze. Wyobraźmy sobie, że chcemy przejrzeć plik 50 MB ze zbiorem transakcji przeprowadzonych przez firmę w celu znalezienia nazwisk tych klientów, których zamówienia przekraczały np. ustaloną kwotę pieniędzy. W tym celu cały plik 50 MB należy przesłać za pośrednictwem instalacji sieciowej do komputera PC, przy którym pracujemy i tam dopiero odpowiednio go posortować. Jednak nawet pomimo dużych szybkości przesyłania danych osiągniętych we współczesnych systemach sieciowych, sprawa zaczyna się bardzo komplikować, gdy podobny cel stawia sobie równocześnie np. 200 użytkowników sieci. Prowadzi to do nagłego spowolnienia, a praktycznie nawet zatrzymania działąnia instalacji sieciowej. Był czas najwyższy aby rozwiązać ten problem bez wracania do czasów, kiedy na Ziemi panowały dinozaury-mainframe'y.

W tym celu, w połowie dekady lat 80. opracowano standard języka SQL (wymawiamy jak sequel, Structured Query Language), za pomocą którego można wysłać do bazy danych zapytanie/problem, zaś przechowywanie danych i ich przetwarzanie dokonywane jest w tym samym miejscu - na tzw. serwerze SQL. Podobne zapytania przesyłać mogą i inni użytkownicy sieci - do każdego z nich po odpowiednim przetworzeniu danych zostanie wysłana krótka odpowiedź, nie blokująca całej instalacji sieciowej. IBM jako pierwszy użył SQL do swoich baz danych w DB/2.

Jak to bywa ze standardami - swój SQL ma IBM, ma i Microsoft, istnieją także i inne rodzaje tego języka. W zasadniczej koncepcji są one jednak podobne do siebie. Sama nazwa SQL wprowadza w błąd. Nie jest to narzędzie tylko do "kolejkowania" i przetwarzania rekordów w bazie danych. Zapewnia ono także inne możliwości, związane z budowaniem i obsługą systemów baz danych.

Część sprzętowa serwera SQL powinna mieć wystarczającą moc przetwarzania i odpowiednio dużą ilość miejsca na dysku twardym - może być to zarówno komputer PC, jak i unixowy. Serwer podłączony jest do sieci, zaś oprogramowanie SQL, zainstalowane na nim odbiera komendy SQL pochodzące od dołączonych stacji roboczych.

Po otrzymaniu polecenia SQL zostaje ono wykonane na bazie danych, a krótka odpowiedź wysyłana jest z powrotem.

Taki styl pracy powoduje znaczne zredukowanie obciążenia instalacji sieciowej, zaś duża moc przetwarzania jest wykorzystywana w pełni tam, gdzie jest naprawdę potrzebna - na serwerze SQL. W wypadku połączeń rozległych typu WAN (Wide Area Network) za pomocą których można np. łączyć kontynenty, jeden duży serwer SQL może obsłużyć działalność ponadnarodowej korporacji.

Aplikacje uruchamiane na komputerze PC mają często "wszyte" zapytania SQL (kod SQL można łączyć np. z kodem C lub Cobol), dzięki czemu można korzystać z zapytań SQL bez wchodzenia w zawiłości jego składni, używając do tego celu ustalonych poleceń. Odpowiedź jest prezentowana w sposób, jakiego oczekujemy od aplikacji i do którego jesteśmy przyzwyczajeni. Przykładem jest Lotus 1-2-3 ze sterownikami DataLens. Jednocześnie, korzystając z tej samej instalacji sieciowej jeden z użytkowników może używać arkusza kalkulacyjnego Lotus 1-2-3 z "wszytym" zapytaniem SQL, inny może korzystać z drugiego pakietu, mającego te same SQL-owe własności, aby zasięgnąć informacji z tej samej bazy danych.

Wiele aplikacji wymagających "sięgania" do danych umieszczonych na serwerze SQL, jest tworzonych przy użyciu narzędzi specjalnie budowanych jako oprogramowanie typu "front-end" (frontowe, czołowe). Są to zwykle aplikacje interaktywne, oparte na przyjaznym interfejsie graficznym użytkownika. Jako przykład może tu służyć Quest firmy Gupta. Jest to samodzielna aplikacja, przy używaniu której użytkownik powinien jednak rozumieć strukturę relacyjnej bazy danych, z informacji której chce korzystać.

Bardziej skomplikowane narzędzia, korzystające z SQL-owego łącza to zestawy dla programistów. Dzięki nim można "generować" interfejs dla użytkownika końcowego oraz dostosować go do poszczególnych zastosowań. Łatwość z jaką można korzystać z narzędzi typu SQL/Windows (także firmy Gupta), PowerBuilder czy EDA/SQL, pozwoliła na skrócenie czasu opracowania takiego SQL-owego interfejsu z miesięcy do kilku dni. Dopasowany do rzeczywistych potrzeb stanowiska pracy w firmie czy umiejętności użytkownika interfejs może wyraźnie skracać niezbędny czas szkolenia oraz zwiększać wydajność pracy na stanowisku. Taka aplikacja realizuje wszystkie możliwe ograniczenia, dotyczące bezpieczeństwa danych w sieci i na serwerze SQL.

Używanie graficznego interfejsu nie zmniejsza szybkości przetwarzania danych na serwerze SQL, ani ich przesyłania w sieci. Baza jest w dalszym ciągu tak samo obsługiwana, jak w przypadku wysłania poleceń za pomocą samego języka SQL. Graficzny interfejs jest obsługiwany przez procesor stacji roboczej, na której uruchomiono opracowaną aplikację.

Przy użyciu oprogramowania (zwanego także klientem), używającego języka SQL, można "sięgać" do danych w całej, często różnorodnej pod względem sprzętu i systemu sieci. Polecenia SQL mogą być przesyłane z platformy na platformę bez potrzeby naruszania kodu macierzystej aplikacji.

Teoretycznie, język SQL pozwala na wykonanie przez każdego z producentów takich narzędzi i systemów baz danych, które potrafią porozumiewać się między sobą. Prawie wszystkie narzędzia stosowane w układzie klient/serwer powinny znaleźć łączność z systemem baz danych, zainstalowanym na serwerze za pomocą interfejsu SQL. Oferowane obecnie relacyjne serwery DBMS (Data Base Managemnt Systems) "rozumieją" z reguły kilka "gwar" języka SQL, co przybliża tę teorię do rzeczywistości.