Was ist SQL?

Mit SQL kann man re­la­tio­na­le Da­ten­ban­ken erstellen sowie auf be­stehen­den Da­ten­ban­ken diverse Ope­ra­tio­nen ausführen, inklusive Da­ten­ab­fra­gen. Die Sprache gehört zum Stan­dard­re­per­toire von Web­ent­wick­le­rin­nen und -ent­wick­lern, Daten-Ana­lys­tin­nen und -Analysten und For­schen­den. Im Vergleich zu anderen Pro­gram­mier­spra­chen ist SQL speziell. Wir erklären die Merkmale der Sprache.

Was ist SQL?

Bei SQL handelt es sich um die „Struc­tu­red Query Language“ (deutsch: „struk­tu­rier­te Ab­fra­ge­spra­che“). Damit kann man Abfragen an Da­ten­ban­ken stellen, die struk­tu­rier­te bzw. re­la­tio­na­le Daten enthalten. Die Sprache baut auf der „re­la­tio­na­len Algebra“ auf. Dabei handelt es sich um eine ma­the­ma­ti­sche Theorie, Daten zu struk­tu­rie­ren und die Er­geb­nis­se von Abfragen zu errechnen. Aus dieser ma­the­ma­ti­schen Grundlage leiten sich viele der Be­son­der­hei­ten von SQL als Pro­gram­mier­spra­che ab. Mitte der 1970er Jahre ent­stan­den, gilt SQL heute als Stan­dard­pro­gram­mier­spra­che für Da­ten­bank­an­wen­dun­gen.

Ein wichtiges Detail über SQL ist, dass es sich um eine reine Abfrage- bzw. Pro­gram­mier­spra­che handelt, nicht um ein um­fas­sen­des Datenbank-Ma­nage­ment-System (DBMS). Einige beliebte DBMS, die SQL im­ple­men­tie­ren, sind MySQL, Oracle SQL und SQLite. Al­ler­dings verwenden diese DBMS meistens Dialekte von SQL, die zu­sätz­li­che und/oder ab­wei­chen­de Befehle haben können.

SQL als do­mä­nen­spe­zi­fi­sche und de­kla­ra­ti­ve Sprache

Im Vergleich zu den meisten eta­blier­ten Pro­gram­mier­spra­chen ist SQL speziell, da es sich um eine do­mä­nen­spe­zi­fi­sche Sprache (Domain-Specific Language, DSL) handelt. Im Gegensatz zu den General Purpose Languages (GPLs), die sich für den Einsatz in vielen un­ter­schied­li­chen An­wen­dun­gen eignen, kann SQL in nur einem Szenario ein­ge­setzt werden, nämlich bei Da­ten­ban­ken.

Zudem handelt es sich bei SQL um eine de­kla­ra­ti­ve Pro­gram­mier­spra­che. Das heißt, dass die Pro­gram­mie­re­rin oder der Pro­gram­mie­rer ein ge­wünsch­tes Ergebnis als Befehl eingibt und das System dafür sorgt, dass dieses Ergebnis erzielt wird. Dies steht im Gegensatz zur so­ge­nann­ten im­pe­ra­ti­ven Pro­gram­mie­rung, bei der die einzelnen Schritte zum Erreichen der Ziele explizit im Code fest­ge­legt werden.

Wozu wird SQL ein­ge­setzt?

Vor allem dient SQL als Schnitt­stel­le zur In­ter­ak­ti­on mit re­la­tio­na­len Datenbank-Ma­nage­ment-Systemen (RDBMS). Eine re­la­tio­na­le Datenbank kann man sich als Tabelle vor­stel­len, in der jeder Zei­len­ein­trag eine vor­be­stimm­te Menge von At­tri­bu­ten besitzt, die mit Werten auf­ge­füllt werden. Der SQL-Code kann entweder vom Menschen über eine text­ba­sier­te Schnitt­stel­le ein­ge­ge­ben oder in API-Zugriffe in­te­griert werden.

Vor- und Nachteile von SQL

Vorteile von SQL

Der größte Vorteil von SQL liegt in der hohen Be­kannt­heit und weiten Ver­brei­tung der Tech­no­lo­gie. Seit ihrem Ursprung in den 1970er Jahren stellt SQL den In­dus­trie­stan­dard für Da­ten­bank­an­wen­dun­gen dar. So ist es relativ einfach, erfahrene SQL-Pro­gram­mie­re­rin­nen und -Pro­gram­mie­rer zu finden, ebenso Schnitt­stel­len mit anderen gängigen Tech­no­lo­gien und Sprachen.

Außerdem ist SQL nicht ohne Grund zum In­dus­trie­stan­dard geworden – die Sprache basiert auf einer robusten ma­the­ma­ti­schen Grundlage, die eine optimale Spei­che­rung von Daten erlaubt. Al­ler­dings erfordern re­la­tio­na­le Da­ten­ban­ken ein fun­dier­tes Ver­ständ­nis der Tech­no­lo­gie und Theorie sowie Geschick und Planung bei der Mo­del­lie­rung. Doch ein gut designtes Da­ten­bank­sche­ma er­mög­licht es, über ent­spre­chen­de Abfragen neue Er­kennt­nis­se aus den Daten zu gewinnen.

Nachteile von SQL

Ein Nachteil von SQL und re­la­tio­na­len Da­ten­ban­ken im All­ge­mei­nen ist die hohe Kom­ple­xi­tät der Tech­no­lo­gie. SQL umfasst hunderte von Befehlen und Klauseln, die für Neu­an­fän­ge­rin­nen und Neu­an­fän­ger eine große Her­aus­for­de­rung dar­stel­len. Er­schwe­rend kommt hinzu, dass viele davon im­ple­men­ta­ti­ons­spe­zi­fisch sind.

Zudem erfordert der Aufbau einer re­la­tio­na­len Datenbank eine Reihe von Annahmen über die zu spei­chern­den Daten. Diese dienen dazu, die Qualität der ge­spei­cher­ten Daten zu sichern, bringen aber auch einige Ein­schrän­kun­gen mit sich, die bei einem schlecht ent­wor­fe­nen Schema für dau­er­haf­te Probleme sorgen. Än­de­run­gen des Schemas im laufenden Betrieb können eine ernst­haf­te Her­aus­for­de­rung dar­stel­len. Zu­sätz­lich zu dieser man­geln­den Fle­xi­bi­li­tät ist es meistens sehr her­aus­for­dernd, eine SQL-Datenbank geo­gra­fisch zu verteilen. Daher ist es alles andere als trivial, durch De­zen­tra­li­sie­rung die Per­for­manz einer Datenbank zu op­ti­mie­ren.

Ein ab­schlie­ßen­der Nachteil von SQL ist die Un­ver­ein­bar­keit mit der weit ver­brei­te­ten ob­jekt­ori­en­tier­ten Pro­gram­mie­rung, die immer mehr an Relevanz gewinnt. In der ob­jekt­ori­en­tier­ten Pro­gram­mie­rung werden Daten sowie „Verhalten“ (Methoden) in Objekten gekapselt. Diese Daten und Methoden werden durch Klas­sen­hier­ar­chien vererbt. Der re­la­tio­na­le Ansatz ist grund­sätz­lich un­ter­schied­lich, da Daten über mehrere Tabellen verteilt werden können. Zudem ist es unmöglich, das Verhalten eines Objekts zu mo­del­lie­ren. Deshalb lassen sich Objekte nicht 1:1 auf re­la­tio­na­le Da­ten­bank­struk­tu­ren über­tra­gen.

Al­ter­na­ti­ven zu SQL

Seit SQL zum Anfang der digitalen Re­vo­lu­ti­on erfunden wurde, hat die Sprache nicht an Relevanz verloren. Es haben sich aber in­zwi­schen einige al­ter­na­ti­ve Schemata gezeigt, die für manche An­wen­dun­gen passender sein können.

Ob­jekt­re­la­tio­na­le Datenbank-Ma­nage­ment-Systeme

Ob­jekt­re­la­tio­na­le Datenbank-Ma­nage­ment-Systeme (ORDBMS) wie Post­greS­QL nutzen SQL als Ab­fra­ge­spra­che, un­ter­stüt­zen jedoch auch Kern­kon­zep­te der ob­jekt­ori­en­tier­ten Pro­gram­mie­rung. So lassen sich Ob­jekt­hier­ar­chien, Vererbung und Ob­jekt­ver­hal­ten ohne Einsatz einer ob­jekt­re­la­tio­na­len Abbildung (Object-Re­la­tio­nal Mapping, ORM) nutzen. Ins­be­son­de­re nut­zer­de­fi­nier­te und zu­sam­men­ge­setz­te Da­ten­ty­pen ver­rin­gern die Kom­ple­xi­tät der Schemata und Abfragen.

NoSQL

SQL-basierte DBMS sind haupt­säch­lich für die Spei­che­rung struk­tu­rier­ter Daten gedacht, doch nicht alle Daten folgen einem festen Schema. In solchen Fällen kommen NoSQL-Da­ten­ban­ken ins Spiel. Der Begriff NoSQL be­zeich­net eine Familie von nicht­re­la­tio­na­len DBMS. Anstatt Daten als Felder in einer Tabelle zu mo­del­lie­ren, kommen ver­schie­de­ne Ansätze zum Einsatz.

Ein populärer Ansatz ist die do­ku­men­ten­ba­sier­te Spei­che­rung von Daten – anstatt Daten in einer Tabelle zu speichern, werden sie in in­di­vi­du­el­len Do­ku­men­ten ge­spei­chert. Ein Vorteil des do­ku­men­ten­ba­sier­ten Ansatzes ist, dass die Daten selbst­schrei­bend sein können. Das heißt, dass das Schema der Daten vom in­di­vi­du­el­len Dokument bestimmt wird, nicht von der Datenbank – Da­ten­ein­trä­ge können also un­ter­schied­li­chen Schemata folgen.

Für ge­wöhn­lich sind NoSQL-Lösungen weniger komplex und bringen Vorteile in Bezug auf Ska­lie­rung und Per­for­mance-Op­ti­mie­rung. Ferner ist es in der Regel einfacher, im laufenden Betrieb das Schema zu ändern bzw. Daten flexibel zu speichern. Dafür ergeben sich u. U. weniger starke Garantien in Bezug auf die Qualität der Daten.