Speichern von Daten in MySQL als JSON

Ich dachte, das wäre eine n00b-Sache. Und so habe ich es nie gemacht. Dann sah ich, dass FriendFeed dies tat und die DB-Skalierung tatsächlich verbesserte und die Latenz verringerte. Ich bin gespannt, ob ich das machen soll. Und wenn ja, wie geht das richtig?

Was ist im Grunde ein guter Ort, um zu lernen, wie man alles in MySQL als CouchDB-DB speichert? Das Speichern von JSON scheint einfacher und schneller zu sein (nicht zu erstellen, weniger Latenz).

Ist es auch einfach, Dinge zu bearbeiten, zu löschen usw., die als JSON in der Datenbank gespeichert sind?

CouchDB und MySQL sind zwei sehr unterschiedliche Tiere. JSON ist die native Methode zum Speichern von Inhalten in CouchDB. In MySQL können Sie JSON-Daten am besten als Text in einem einzigen Feld speichern. Dies würde den Zweck der Speicherung in einem RDBMS völlig zunichte machen und jede Datenbanktransaktion erheblich erschweren.

Tu es nicht.

Trotzdem schien FriendFeed ein extrem benutzerdefiniertes Schema zusätzlich zu MySQL zu verwenden. Es hängt wirklich davon ab, was genau Sie speichern möchten. Es gibt kaum eine eindeutige Antwort darauf, wie ein Datenbanksystem missbraucht werden kann, sodass es für Sie sinnvoll ist. Angesichts der Tatsache, dass der Artikel sehr alt ist und ihr Hauptgrund gegen Mongo und Couch Unreife war, würde ich diese beiden neu bewerten, wenn MySQL ihn nicht für Sie schneidet. Sie sollten inzwischen sehr gewachsen sein.

Jeder, der dies kommentiert, scheint dies aus dem falschen Blickwinkel zu betrachten. Es ist in Ordnung, JSON-Code über PHP in einer relationalen Datenbank zu speichern, und es wird tatsächlich schneller sein, komplexe Daten wie diese zu laden und anzuzeigen Suchen, Indizieren usw.

Der beste Weg, dies zu tun, ist die Verwendung von Hybriddaten. Wenn Sie beispielsweise nach Datums- und Uhrzeitangaben suchen müssen, ist MySQL (leistungsoptimiert) viel schneller als PHP, und für so etwas wie die Suchentfernung von Veranstaltungsorten sollte MySQL auch viel sein schneller (beachten Sie, dass die Suche keinen Zugriff bietet). Daten, nach denen Sie nicht suchen müssen, können dann in JSON, BLOB oder einem anderen Format gespeichert werden, das Sie wirklich für notwendig halten.

Daten, auf die Sie zugreifen müssen, können sehr einfach als JSON gespeichert werden, beispielsweise als grundlegendes Rechnungssystem für jeden Fall. Sie profitieren überhaupt nicht sehr von RDBMS und können in JSON nur durch json_encoding ($ _ POST ['entires']) gespeichert werden, wenn Sie die richtige HTML-Formularstruktur haben.

Ich bin froh, dass Sie mit MongoDB zufrieden sind, und ich hoffe, dass es Ihnen weiterhin gute Dienste leistet, aber denken Sie nicht, dass MySQL immer von Ihrem Radar abweicht, da Ihre App immer komplexer wird und Sie möglicherweise ein RDBMS benötigen einige Funktionen und Merkmale (auch wenn nur archivierte Daten oder Geschäftsberichte gelöscht werden sollen)

MySQL 5.7 unterstützt jetzt einen nativen JSON-Datentyp, der MongoDB und anderen schemenlosen Dokumentdatenspeichern ähnelt:

JSON-Unterstützung

Ab MySQL 5.7.8 unterstützt MySQL einen nativen JSON-Typ. JSON-Werte werden nicht als Zeichenfolgen gespeichert, sondern verwenden ein internes Binärformat, das einen schnellen Lesezugriff auf Dokumentelemente ermöglicht. In JSON-Spalten gespeicherte JSON-Dokumente werden bei jedem Einfügen oder Aktualisieren automatisch überprüft, wobei ein ungültiges Dokument einen Fehler verursacht. JSON-Dokumente werden bei der Erstellung normalisiert und können mit den meisten Vergleichsoperatoren wie =, <, <=,>,> =, <> ,! = Und <=> verglichen werden. Informationen zu unterstützten Operatoren sowie Vorrang und andere Regeln, denen MySQL beim Vergleichen von JSON-Werten folgt, finden Sie unter Vergleichen und Ordnen von JSON-Werten.

MySQL 5.7.8 bietet außerdem eine Reihe von Funktionen für die Arbeit mit JSON-Werten. Diese Funktionen umfassen die hier aufgeführten:

1. Funktionen, die JSON-Werte erstellen: JSON_ARRAY (), JSON_MERGE () und JSON_OBJECT (). Siehe auch Abschnitt 12.16.2, „Funktionen zum Erstellen von JSON-Werten“.
2. Funktionen, die JSON-Werte durchsuchen: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () und JSON_SEARCH (). Siehe Abschnitt 12.16.3, „Funktionen zum Suchen von JSON-Werten“.
3. Funktionen, die JSON-Werte ändern: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () und JSON_UNQUOTE (). Siehe Abschnitt 12.16.4, „Funktionen zum Ändern von JSON-Werten“.
4. Funktionen, die Informationen zu JSON-Werten bereitstellen: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () und JSON_VALID (). Siehe Abschnitt 12.16.5, „Funktionen, die JSON-Wertattribute zurückgeben“.

In MySQL 5.7.9 und höher können Sie column-> path als Abkürzung für JSON_EXTRACT (column, path) verwenden. Dies funktioniert als Alias ​​für eine Spalte, wenn eine Spaltenkennung in einer SQL-Anweisung vorkommen kann, einschließlich der Klauseln WHERE, ORDER BY und GROUP BY. Dies umfasst SELECT, UPDATE, DELETE, CREATE TABLE und andere SQL-Anweisungen. Die linke Seite muss eine JSON-Spaltenkennung (und kein Alias) sein. Die rechte Seite ist ein JSON-Pfadausdruck in Anführungszeichen, der anhand des als Spaltenwert zurückgegebenen JSON-Dokuments ausgewertet wird.

Weitere Informationen zu -> und JSON_EXTRACT () finden Sie in Abschnitt 12.16.3, „Funktionen zum Durchsuchen von JSON-Werten“. Informationen zur Unterstützung von JSON-Pfaden in MySQL 5.7 finden Sie unter Suchen und Ändern von JSON-Werten. Siehe auch Sekundärindizes und virtuell generierte Spalten.

Mehr Info:

https://dev.mysql.com/doc/refman/5.7/en/json.html

JSON-Zeichen sind nichts Besonderes, wenn es um Speicher geht, Zeichen wie

{, }, [, ], ', a-z, 0-9.... sind wirklich nichts Besonderes und kann als Text gespeichert werden.

Das erste Problem, das Sie haben werden, ist dieses

{profile_id: 22, Benutzername: 'Robert', Passwort: 'skhgeeht893htgn34ythg9er'}

Das in einer Datenbank gespeicherte ist nicht so einfach zu aktualisieren, es sei denn, Sie hatten Ihr eigenes Verfahren und haben einen JSON-Code für MySQL entwickelt

UPDATE users SET JSON(user_data,'username') = 'New User';

Da Sie dies nicht tun können, müssen Sie zuerst den JSON AUSWÄHLEN, dekodieren, ändern, aktualisieren, sodass Sie theoretisch genauso gut mehr Zeit damit verbringen können, eine geeignete Datenbankstruktur aufzubauen!

Ich verwende json, um Daten zu speichern, aber nur Metadaten, Daten, die nicht häufig aktualisiert werden und nicht benutzerspezifisch sind. Beispiel: Wenn ein Benutzer einen Beitrag hinzufügt und in diesem Beitrag Bilder hinzufügt, werden die Bilder analysiert und Daumen und erstellt Verwenden Sie dann die Daumen-URLs in einem JSON-Format.

Um zu veranschaulichen, wie schwierig es ist, JSON-Daten mithilfe einer Abfrage abzurufen, werde ich die Abfrage freigeben, die ich dazu erstellt habe.

Arrays oder andere Objekte werden nicht berücksichtigt, sondern nur grundlegende Datentypen. Sie sollten die 4 Instanzen der Spalte in den Spaltennamen ändern, in dem der JSON gespeichert ist, und die 4 Instanzen von myfield in das JSON-Feld ändern, auf das Sie zugreifen möchten.

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'

Es hängt wirklich von Ihrem Anwendungsfall ab. Wenn Sie Informationen speichern, die für die Berichterstellung absolut keinen Wert haben und nicht über JOINs mit anderen Tabellen abgefragt werden, ist es möglicherweise sinnvoll, Ihre Daten in einem einzigen Textfeld zu speichern, das als JSON codiert ist.

Dies könnte Ihr Datenmodell erheblich vereinfachen. Erwarten Sie jedoch nicht, wie von RobertPitt erwähnt, diese Daten mit anderen normalisierten Daten kombinieren zu können.

Dies ist eine alte Frage, aber ich kann sie immer noch oben im Suchergebnis von Google sehen. Ich denke, es wäre sinnvoll, 4 Jahre nach dem Stellen der Frage eine neue Antwort hinzuzufügen.

Erstens gibt es eine bessere Unterstützung beim Speichern von JSON in RDBMS. Sie können in Betracht ziehen, zu PostgreSQL zu wechseln (obwohl MySQL JSON seit Version 5.7.7 unterstützt). PostgreSQL verwendet sehr ähnliche SQL-Befehle wie MySQL, außer dass sie mehr Funktionen unterstützen. Eine der hinzugefügten Funktionen besteht darin, dass sie den JSON-Datentyp bereitstellen und Sie nun den gespeicherten JSON abfragen können. ( Einige Hinweise dazu ) Wenn Sie die Abfrage nicht direkt in Ihrem Programm erstellen, z. B. mit PDO in PHP oder eloquent in Laravel, müssen Sie lediglich PostgreSQL auf Ihrem Server installieren und die Einstellungen für die Datenbankverbindung ändern. Sie müssen nicht einmal Ihren Code ändern.

Wie die anderen Antworten andeuteten, ist es meistens keine gute Idee, Daten als JSON direkt in RDBMS zu speichern. Es gibt jedoch einige Ausnahmen. Eine Situation, die ich mir vorstellen kann, ist ein Feld mit variabler Anzahl verknüpfter Einträge.

Zum Speichern eines Tags eines Blogposts benötigen Sie normalerweise eine Tabelle für einen Blogpost, eine Tag-Tabelle und eine passende Tabelle. Wenn der Benutzer einen Beitrag bearbeiten möchte und Sie anzeigen müssen, welches Tag mit diesem Beitrag verknüpft ist, müssen Sie 3 Tabellen abfragen. Dies beeinträchtigt die Leistung erheblich, wenn Ihre passende Tabelle / Tag-Tabelle lang ist.

Durch Speichern der Tags als JSON in der Blogpost-Tabelle erfordert dieselbe Aktion nur eine einzige Tabellensuche. Der Benutzer kann dann sehen, dass der Blog-Beitrag schneller bearbeitet werden kann. Dies beeinträchtigt jedoch die Leistung, wenn Sie einen Bericht darüber erstellen möchten, welcher Beitrag mit einem Tag verknüpft ist, oder nach Tag suchen möchten.

Sie können auch versuchen, die Datenbank zu de-normalisieren. Wenn Sie die Daten duplizieren und auf beide Arten speichern, können Sie beide Methoden nutzen. Sie benötigen nur ein wenig mehr Zeit zum Speichern Ihrer Daten und mehr Speicherplatz (was im Vergleich zu den Kosten für mehr Rechenleistung günstig ist).

Ich würde sagen, die einzigen zwei Gründe, dies in Betracht zu ziehen, sind:

• Leistung ist mit einem normalisierten Ansatz einfach nicht gut genug
• Sie können Ihre besonders fließenden / flexiblen / sich ändernden Daten nicht ohne weiteres modellieren

Ich habe hier ein wenig über meinen eigenen Ansatz geschrieben:

Welche Skalierbarkeitsprobleme sind bei der Verwendung eines NoSQL-Datenspeichers aufgetreten?

(siehe die obere Antwort)

Selbst JSON war nicht schnell genug, daher haben wir einen Ansatz im benutzerdefinierten Textformat verwendet. Arbeitete / arbeitet weiterhin gut für uns.

Gibt es einen Grund, warum Sie so etwas wie MongoDB nicht verwenden? (könnte sein, dass MySQL "erforderlich" ist; nur neugierig)

Es scheint mir, dass jeder, der diese Frage beantwortet, das eine kritische Problem außer @deceze irgendwie vermisst - verwenden Sie das richtige Werkzeug für den Job . Sie können eine relationale Datenbank zwingen, fast alle Arten von Daten zu speichern, und Sie können Mongo zwingen, relationale Daten zu verarbeiten, aber zu welchem ​​Preis? Am Ende führen Sie Komplexität auf allen Ebenen der Entwicklung und Wartung ein, vom Schemadesign bis zum Anwendungscode. ganz zu schweigen vom Performance-Hit.

Im Jahr 2014 haben wir Zugriff auf viele Datenbankserver, die bestimmte Datentypen außergewöhnlich gut verarbeiten.

• Mongo (Dokumentenspeicherung)
• Redis (Schlüsselwert-Datenspeicherung)
• MySQL / Maria / PostgreSQL / Oracle / etc (relationale Daten)
• CouchDB (JSON)

Ich bin sicher, ich habe einige andere vermisst, wie RabbirMQ und Cassandra. Mein Punkt ist, verwenden Sie das richtige Tool für die Daten, die Sie speichern müssen.

Wenn Ihre Anwendung das Speichern und Abrufen einer Vielzahl von Daten sehr, sehr schnell erfordert (und wer nicht), scheuen Sie sich nicht, mehrere Datenquellen für eine Anwendung zu verwenden. Die gängigsten Webframeworks unterstützen mehrere Datenquellen (Rails, Django, Grails, Cake, Zend usw.). Diese Strategie begrenzt die Komplexität auf einen bestimmten Bereich der Anwendung, das ORM oder die Datenquellenschnittstelle der Anwendung.

Hier ist eine Funktion zum Speichern / Aktualisieren von Schlüsseln eines JSON-Arrays in einer Spalte und eine andere Funktion zum Abrufen von JSON-Werten. Diese Funktionen werden unter der Annahme erstellt, dass der Spaltenname zum Speichern des JSON-Arrays json lautet . Es wird PDO verwendet .

Funktion speichern / aktualisieren

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

Dabei ist $ uid die Benutzer-ID, $ key - der zu aktualisierende JSON-Schlüssel und sein Wert wird als $ val angegeben .

Wertfunktion abrufen

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

Dabei ist $ key ein Schlüssel des JSON- Arrays, von dem wir den Wert benötigen.

Die JSON Labs-Version von MySQL 5.7.7 ( Linux-Binärdateien , Quelle ) wurde um die frühzeitige Unterstützung für das Speichern von JSON in MySQL erweitert ! Die Veröffentlichung scheint aus einer Reihe von JSON-bezogenen benutzerdefinierten Funktionen hervorgegangen zu sein, die 2013 veröffentlicht wurden .

Diese aufkommende native JSON-Unterstützung scheint in eine sehr positive Richtung zu gehen, einschließlich der JSON-Validierung in INSERT, einem optimierten Binärspeicherformat mit einer Nachschlagetabelle in der Präambel, mit der die JSN_EXTRACT-Funktion Binärsuchen durchführen kann, anstatt bei jedem Zugriff zu analysieren. Es gibt auch eine ganze Reihe neuer Funktionen zum Behandeln und Abfragen bestimmter JSON-Datentypen:

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

Meiner Meinung nach ist das oben Genannte ein großartiger Anwendungsfall für diese neue Funktionalität. Viele SQL-Datenbanken verfügen bereits über eine Benutzertabelle. Anstatt endlose Schemaänderungen vorzunehmen, um den sich ändernden Benutzereinstellungen Rechnung zu tragen, JOINist es perfekt , eine einzelne JSON-Spalte in einer Entfernung zu haben. Zumal es unwahrscheinlich ist, dass es jemals nach einzelnen Artikeln abgefragt werden muss.

Während es noch zu früh ist noch, tut das MySQL - Server - Team einen guten Job die Änderungen der Kommunikation auf dem Blog .

Ich glaube, dass das Speichern von JSON in einer MySQL-Datenbank tatsächlich den Zweck der Verwendung von RDBMS, wie es verwendet werden soll, zunichte macht. Ich würde es nicht in Daten verwenden, die irgendwann manipuliert oder gemeldet würden, da es nicht nur die Komplexität erhöht, sondern auch die Leistung je nach Verwendung leicht beeinträchtigen könnte.

Ich war jedoch neugierig, ob jemand anderes an einen möglichen Grund dachte, dies tatsächlich zu tun. Ich dachte daran, eine Ausnahme für Protokollierungszwecke zu machen. In meinem Fall möchte ich Anforderungen protokollieren, die eine variable Anzahl von Parametern und Fehlern aufweisen. In dieser Situation möchte ich Tabellen für den Anfragetyp und die Anforderungen selbst mit einer JSON-Zeichenfolge mit verschiedenen Werten verwenden, die erhalten wurden.

In der obigen Situation werden die Anforderungen protokolliert und niemals im JSON-Zeichenfolgenfeld bearbeitet oder indiziert. In einer komplexeren Umgebung würde ich jedoch wahrscheinlich versuchen, etwas zu verwenden, das eher für diese Art von Daten gedacht ist, und es mit diesem System speichern. Wie andere gesagt haben, hängt es wirklich davon ab, was Sie erreichen möchten, aber das Befolgen von Standards hilft immer bei Langlebigkeit und Zuverlässigkeit!

JSON ist auch in der PostgreSQL-Datenbank ein gültiger Datentyp. Die MySQL-Datenbank hat JSON jedoch noch nicht offiziell unterstützt. Aber es wird gebacken: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Ich stimme auch zu, dass es viele gültige Fälle gibt, in denen einige Daten besser in eine Zeichenfolge in einer Datenbank serialisiert werden. Der Hauptgrund kann sein, dass es nicht regelmäßig abgefragt wird und dass sich das eigene Schema möglicherweise ändert. Sie möchten das entsprechende Datenbankschema nicht ändern. Der zweite Grund ist, dass Sie, wenn die serialisierte Zeichenfolge direkt aus externen Quellen stammt, möglicherweise nicht alle analysieren und um jeden Preis in die Datenbank einspeisen möchten, bis Sie eine verwenden. Ich werde also darauf warten, dass die neue MySQL-Version JSON unterstützt, da es dann einfacher ist, zwischen verschiedenen Datenbanken zu wechseln.

Ich benutze json, um alles für ein Projekt aufzuzeichnen, ich benutze tatsächlich drei Tabellen! eine für die Daten in json, eine für den Index aller Metadaten der json-Struktur (jedes Meta wird durch eine eindeutige ID codiert) und eine für den Sitzungsbenutzer, das ist alles. Der Benchmark kann in diesem frühen Codezustand nicht quantifiziert werden, aber zum Beispiel war ich Benutzeransichten (innerer Join mit Index), um eine Kategorie zu erhalten (oder irgendetwas, als Benutzer, ...), und es war sehr langsam (sehr sehr langsam) , verwendete Ansicht in MySQL ist nicht der gute Weg). Das Suchmodul in dieser Struktur kann alles tun, was ich will, aber ich denke, Mongodb wird bei diesem Konzept des vollständigen JSON-Datensatzes effizienter sein. Zum Beispiel benutze ich Benutzeransichten, um einen Baum der Kategorie zu erstellen, und Breadcrumb, mein Gott! so viele Fragen zu erledigen! Apache selbst weg! und in der Tat, für diese kleine Website benutze ich einen PHP, der Baum und Brotkrumen erzeugt, Die Extraktion der Daten erfolgt durch das Suchmodul (das nur den Index verwendet). Die Datentabelle wird nur zur Aktualisierung verwendet. Wenn ich möchte, kann ich alle Indizes zerstören und mit jedem Daten neu generieren und die umgekehrte Arbeit ausführen, um beispielsweise alle Daten (json) zu zerstören und nur mit der Indextabelle neu zu generieren. Mein Projekt ist jung und läuft unter PHP und MySQL, aber manchmal wird die Verwendung von Node Js und Mongodb für dieses Projekt effizienter.

Verwenden Sie json, wenn Sie glauben, dass Sie es können, nur um es zu tun, weil Sie es können! und vergiss es, wenn es ein Fehler war; Versuchen Sie es, indem Sie eine gute oder schlechte Wahl treffen, aber versuchen Sie es!

Niedrig

ein französischer Benutzer

Ich weiß, dass dies sehr spät ist, aber ich hatte eine ähnliche Situation, in der ich einen hybriden Ansatz verwendet habe, bei dem RDBMS-Standards beibehalten wurden, um Tabellen bis zu einem bestimmten Punkt zu normalisieren und dann Daten in JSON als Textwert über diesen Punkt hinaus zu speichern. So speichere ich beispielsweise Daten in 4 Tabellen gemäß den RDBMS-Normalisierungsregeln. In der 4. Tabelle zur Aufnahme eines dynamischen Schemas speichere ich jedoch Daten im JSON-Format. Jedes Mal, wenn ich Daten abrufen möchte, rufe ich die JSON-Daten ab, analysiere sie und zeige sie in Java an. Dies hat bisher bei mir funktioniert und um sicherzustellen, dass ich die Felder, die ich in JSON-Daten in der Tabelle transformiere, mithilfe einer ETL weiterhin normalisiert indizieren kann. Dies stellt sicher, dass der Benutzer während der Arbeit an der Anwendung nur eine minimale Verzögerung hat und die Felder für die Datenanalyse usw. in ein RDBMS-freundliches Format umgewandelt werden.

Sie können dieses Gist verwenden: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Nach der Installation auf dem Server (nur Root-Berechtigung, nicht Super) können Sie Folgendes tun:

select extract_json_value('{"a":["a","2"]}','(/a)')

Es wird zurückgegeben. a 2 Sie können alles in JSON zurückgeben, indem Sie dies verwenden. Der gute Teil ist, dass es MySQL 5.1,5.2,5.6 unterstützt. Und Sie müssen keine Binärdatei auf dem Server installieren.

Basierend auf einem alten Projekt common-schema, aber es funktioniert noch heute https://code.google.com/archive/p/common-schema/