Zeile 1: |
Zeile 1: |
| | | |
− | [https://github.com/surrealdb/surrealdb SurrealDB] ist v.a. eine Datenbank, kann aber auch als komplettes Backend für Webanwendungen fungieren. | + | [https://github.com/surrealdb/surrealdb SurrealDB] ist v.a. eine Datenbank, kann aber auch als komplettes Backend für Webanwendungen fungieren. Sein Alleinstellungsmerkmal ist der [https://surrealdb.com/docs/surrealdb/security/authentication#record-users Record User]. Damit können Regeln für die Aufnahme von neuen Usern und deren Anmeldungsverfahren in der Datenbank definiert werden. Für die |
| + | tatsächliche Aufnahme neuer Nutzer braucht man dann keinen "CREATE USER"-Befehl als vorhandener Nutzer auszuführen, sondern der neue Nutzer kann sich selbst anmelden. Dadurch kann man sich einen Applikationsserver sparen, der üblicherweise zwischen Datenbank und Frontend zu schalten ist. |
| | | |
| == Tools == | | == Tools == |
Zeile 19: |
Zeile 20: |
| Die HTTP-API von SurrealDB ist dokumentiert. | | Die HTTP-API von SurrealDB ist dokumentiert. |
| | | |
− | === Scope-User === | + | === JSON ohne beginnendes Leerzeichen === |
| + | |
| + | |
| + | In Version 1.2.1 dürfen die per POST übermittelten Daten NICHT mit einem Leerzeichen beginnen. |
| + | |
| + | === Record Links mit r etc. === |
| + | |
| + | Record IDs, die als JSON-String übermittelt werden, [https://surrealdb.com/docs/surrealql/datamodel/ids müssen mit einem "r" beginnen]. |
| + | |
| + | Das führt zu einem nicht standardmäßigen JSON: |
| + | |
| + | { "owner": '''r'''"user:tobie" |
| + | } |
| + | |
| + | Das gilt auch für die längere Variante mit <code><record></code>: |
| + | |
| + | { "owner": '''<record<user>>'''"user:tobie" |
| + | } |
| + | |
| + | Ergänzt man den Cast nicht, kommt etwa folgende Fehlermeldung: ''"{result: Found 'user:tobie' for field `owner`, with record `xy`, but expected a record<user>, status: ERR, time: 0.01 µs}"'' |
| + | |
| + | Die entsprechenden Buchstaben sind |
| + | * für [https://surrealdb.com/docs/surrealql/datamodel/ids RecordIDs] "r" |
| + | * für UUID "u" |
| + | * für [https://surrealdb.com/docs/surrealql/datamodel/datetimes DateTime] "d" |
| + | * für String "s" |
| + | |
| + | === Scope-User (V1.x) === |
| + | |
| + | '''Hinweis: Der Scope User wird in Version 2.0 durch den Record User abgelöst. Der Scope heißt jetzt Access Method. Siehe https://surrealdb.com/docs/surrealdb/security/authentication#record-users ''' |
| | | |
| Ein Scope wird mit DEFINE SCOPE angelegt. | | Ein Scope wird mit DEFINE SCOPE angelegt. |
Zeile 45: |
Zeile 75: |
| * https://ddlele.com/posts/surreal-db-row-security | | * https://ddlele.com/posts/surreal-db-row-security |
| * https://gist.github.com/koakh/fbbc37cde630bedcf57acfd4d6a6956b | | * https://gist.github.com/koakh/fbbc37cde630bedcf57acfd4d6a6956b |
| + | * https://www.linode.com/docs/guides/managing-security-and-access-for-surrealdb/ |
| | | |
| == SELECT - Besonderheiten == | | == SELECT - Besonderheiten == |
Zeile 84: |
Zeile 115: |
| === Keine VIEWs === | | === Keine VIEWs === |
| | | |
− | Auch wenn die Dokumentation behauptet, vorberechnete Tabellen (DEFINE TABLE ... AS SELECT ...) seien Views in rein relationalen Datenbanken vergleichbar<ref>Vgl. https://surrealdb.com/docs/surrealdb/surrealql/statements/define/table#pre-computed-table-views .</ref> handelt es sich dabei eher um Materialized Views. Die Ergebnisdaten werden also nicht erst bei der Abfrage einer precomputed table berechnet, sondern schon wenn die zugrunde liegenden Elemente geschaffen, aktualisiert oder gelöscht werden. | + | Auch wenn die Dokumentation behauptet, vorberechnete Tabellen (DEFINE TABLE ... AS SELECT ...) seien Views in rein relationalen Datenbanken vergleichbar<ref>Vgl. https://surrealdb.com/docs/surrealql/statements/define/table#pre-computed-table-views .</ref> handelt es sich dabei eher um Materialized Views. Die Ergebnisdaten werden also nicht erst bei der Abfrage einer precomputed table berechnet, sondern schon wenn die zugrunde liegenden Elemente geschaffen, aktualisiert oder gelöscht werden. |
| | | |
| Eigentlich könnte das einem von der Funktionalität egal sein, aber die precomputed tables scheinen etwas komplizierter zu programmieren zu sein, so dass sie aktuell (Stand: März 2024) noch nicht produktiv genutzt werden können.<ref>Vgl. https://github.com/surrealdb/surrealdb/issues/3546</ref> | | Eigentlich könnte das einem von der Funktionalität egal sein, aber die precomputed tables scheinen etwas komplizierter zu programmieren zu sein, so dass sie aktuell (Stand: März 2024) noch nicht produktiv genutzt werden können.<ref>Vgl. https://github.com/surrealdb/surrealdb/issues/3546</ref> |
Zeile 90: |
Zeile 121: |
| Wünschenswert wären daher herkömmliche - gerne auch nur lesbare, nicht beschreibbare - Views, die im Prinzip nur eine abgekürzte Schreibweise für umfangreichere SELECT-Statements darstellen. In der Zwischenzeit kann man sich produktiv nur mit komplexeren SELECT-Statements behelfen. | | Wünschenswert wären daher herkömmliche - gerne auch nur lesbare, nicht beschreibbare - Views, die im Prinzip nur eine abgekürzte Schreibweise für umfangreichere SELECT-Statements darstellen. In der Zwischenzeit kann man sich produktiv nur mit komplexeren SELECT-Statements behelfen. |
| | | |
| + | === KI-Suche === |
| + | |
| + | Da SurreaDB auch Vektoren beherrscht, kann man es auch mit Hilfe entsprechender KI-Datenmengen dazu bringen, semantische Suchen zu beherrschen. Siehe dazu: |
| + | |
| + | * https://surrealdb.com/blog/moving-from-full-text-search-to-vector-search-in-surrealdb |
| | | |
| == Nutzung mit TypeScript == | | == Nutzung mit TypeScript == |