Kurzer Hintergrund: In meiner letzten Anmerkung wurde ein Ansatz zum Speichern und Abrufen von Daten beschrieben, auf dem Sie einen Anwendungsdesigner erstellen können - eine Alternative zu modernen Entwicklungsplattformen, jedoch ohne Programmierbedarf. Diese Erfindung kann möglicherweise die gesamte Welt der IT, wie wir sie kennen, verändern.
Ich führte eine Patentrecherche durch und veröffentlichte das Ergebnis, um sicherzustellen, dass es keine architektonischen Gegenstücke gab. Dann erhielt er ein Patent und veröffentlichte einen Artikel mit Erläuterungen, der einige kühne Bemerkungen zu Volumen, Skalierbarkeit, Geschwindigkeit und anderen Dingen enthielt.
Natürlich warf der Artikel eine Vielzahl von Fragen auf, die separat behandelt werden müssen: den Unterschied zu bestehenden Lösungen und eine vergleichende Analyse der Leistung und Pläne zum Erstellen von Datenbankabfragen. Und beantworten Sie auch die Frage: Worum geht es und warum?
Da das Thema für viele schmerzhaft ist und die behaupteten Vorteile sehr ehrgeizig sind, waren die Kommentare ziemlich hart. Der Grund ist verständlich - in dem Artikel sieht jeder sofort „EAV“, über das ernsthafte Leute noch Forschung schreiben, während das Leistungsproblem im Allgemeinen nicht lösbar ist. Wie ich in den Kommentaren freundlich informiert wurde, hat EAV eine Reihe von Mängeln, dies ist bekannt, und jeder, der eine endgültige Lösung für die EAV-Probleme behauptet, muss großzügige Karma-Tritte bekommen, um zur Besinnung zu kommen.
Es gibt nur eine Subtilität: Der Artikel präsentiert EAV nicht als solche
Die beliebteste Frage war: "Wie unterscheidet sich das von EAV, KV, Magento ...".
Es scheint, dass die Unterschiede in allem liegen, was nicht in die aufgeführten Eigenschaften passt:
- Die Struktur - in der Tabelle sind 5 Spalten und 3 Indizes
- Stichprobenmethode - Eine Tabelle beschreibt Datentypen und ihre Beziehungen (Metadaten) sowie die Daten selbst
Aber eine solche Antwort passte nicht zu vielen Lesern, deshalb werde ich versuchen, sie genauer zu erklären.
Die beschriebene Struktur verwendet das EAV-Verzeichnis, ergänzt durch das ID-Attribut, da jedes Attribut auch eine unabhängige Entität ist, die ihre eigenen Attribute haben und als Referenzwert verwendet werden kann. Das heißt, die Struktur ist nicht nur als EAV-Referenz gedacht, weshalb ich sie eigentlich nicht EAV nennen kann.
Am wichtigsten ist, dass EAV keine autarke Lösung sein kann, sondern nur eine Anleitung, eines der Elemente des Systems. Ich spreche von einer vollständigen, autarken Lösung, für die keine zusätzlichen Elemente erforderlich sind, um eine Struktur, Daten und deren Verwaltung zu erstellen.
Um zu erklären, wie sich die Lösung von Datomic, Magento und Zehntausenden anderer Lösungen und Produkte unterscheidet, müssen Sie sie zehntausende Male vergleichen. Daher werde ich es wagen, eine einfache Technik vorzuschlagen, mit der Sie in wenigen Minuten einen Vergleich mit jedem System anstellen und gegebenenfalls den Unterschied feststellen können.
Es ist erforderlich, die Erfüllung der folgenden Bedingungen für das verglichene System zu überprüfen:
1. Alle Daten werden in einer Tabelle gespeichert (siehe auch Abschnitt 3.), die mindestens die folgenden Felder enthält: ID, Eltern-ID, Typ-ID, Wert
2. Für die Tabelle werden mindestens die folgenden Indizes erstellt: ID; Typ ID + Wert; Übergeordnete ID + Typ-ID.
3. Es können mehrere Tabellen vorhanden sein, die jedoch alle die minimale Struktur von Element 1 und Indizes enthalten, die sich durch den Typ des Felds Wert unterscheiden
4. Die Tabelle enthält eine Beschreibung der Datentypen.
5. Die Tabelle enthält eine Beschreibung der Details der Datentypen (aus den darin beschriebenen Typen).
6. Die Tabelle enthält Datenobjekte mit einem Verweis auf ihren Typ (aus den darin beschriebenen Typen).
7. Die Tabelle enthält Details zu Objekten mit einem Link zum übergeordneten Objekt und Typ
8. Die Auswahl der Objekte erfolgt unter Angabe der Objektart
9. Die Auswahl der Details des Objekts erfolgt unter Angabe des Elternteils und des Typs
10. Die Auswahl des Objekts anhand seiner Angaben erfolgt unter Angabe der Art der Angaben
11. (optional) Die Objekte werden über die Details verbunden, die den ID-Typ des verknüpften Objekts enthalten
Wenn alle Voraussetzungen erfüllt sind, verfügen Sie über ein System, das unter die Beschreibung der hier beschriebenen Hinweise fällt.
Wichtigere Probleme werfen Zweifel an der Aussage zur Systemleistung auf, wenn das Volumen zunimmt.
Für Vergleichstests wurden zwei identische Datenbanken erstellt, von denen eine in den üblichen Tabellen der relationalen Datenbank erstellt wurde und die andere unter Verwendung der deklarierten Methodik. Nachfolgend finden Sie die Testergebnisse von zwei Datenbanken mit Abfragetexten, Zeitmessungen und Analyse von Ausführungsplänen.
In den Kommentaren zum letzten Beitrag wurde eine einfache Struktur verwandter Daten vorgeschlagen , die zum Testen geeignet ist. Ich habe es als Grundlage genommen: Dies ist eine Liste von 1.048.552 Büchern von 142.654 Autoren, die aus zufälligen Daten generiert wurden.
Die Struktur sieht folgendermaßen aus (zum Anzeigen klicken)CREATE TABLE `author` (
`id` int(11) NOT NULL,
`author` varchar(128) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `books` (
`id` int(8) NOT NULL,
`name` varchar(256) NOT NULL,
`author` int(8) NOT NULL,
`pages` int(4) NOT NULL,
`year` int(4) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `author`
ADD PRIMARY KEY (`id`),
ADD KEY `author` (`author`);
ALTER TABLE `books`
ADD PRIMARY KEY (`id`),
ADD KEY `name` (`name`(255)),
ADD KEY `author` (`author`);
ALTER TABLE `books`
ADD CONSTRAINT `books_ibfk_1` FOREIGN KEY (`author`) REFERENCES `author` (`id`);
:
: 1 @2.4GHz, 1GB RAM, SSD.
207 289 .
, , .
: , . .
:
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE author.author LIKE '%aro%' AND books.author=author.id
LIMIT 1000
( ):
«aro», 465 .
193 :
:
266 :
, 266 6 ( , - , ). 264 .
:
SELECT a225.val v1_225,a217.val v2_217,a223.val v3_217,a219.val v4_217
FROM test a225
LEFT JOIN (test r217 JOIN test a217 USE INDEX (PRIMARY)) ON r217.up=a217.id AND a225.id=r217.t AND a217.t=217
LEFT JOIN test a223 ON a223.up=a217.id AND a223.t=223
LEFT JOIN test a219 ON a219.up=a217.id AND a219.t=219
WHERE a225.up!=0 AND a225.t=225 AND a225.val LIKE '%aro%'
LIMIT 1000
:
, , «», , , .
, , ( ).
, , . .
, :
, . . Magento, , .
,
, , .
:
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE author.author LIKE 'lac%' AND books.author=author.id
LIMIT 1000
3.1 :
8.4 , 6 :
, , .
:
:
, ( ):
, , . , .
—
: . :
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE books.name LIKE '% %' AND books.author=author.id
LIMIT 50
:
: 148 2490 . 17 !
, , , , . :
: 181 25 . , , 7 .
:
SELECT author.author, books.name, books.pages, books.year
FROM books INNER JOIN author ON books.author=author.id
WHERE books.name LIKE '% %'
LIMIT 50
: 62 47 . . , , . , .
, , , .
, , , . , .
: () . :
SELECT author.author, books.name, books.pages, books.year
FROM books, author
WHERE books.pages=150 AND books.year=1972 AND books.author=author.id
LIMIT 50
:
, 30 :
, , . .
, : , .
: DDL DML .