حلم براءة اختراع المبرمج - الجزء الثاني

خلفية موجزة: وصفت ملاحظتي الأخيرة نهجًا لتخزين واسترداد البيانات التي يمكنك من خلالها بناء مصمم تطبيقات - وهو بديل لمنصات التطوير الحديثة ، ولكن دون الحاجة إلى البرمجة. يمكن لهذا الاختراع أن يحول عالم تكنولوجيا المعلومات بالكامل ، كما نعرفه.

لقد أجريت بحثًا عن براءة اختراع ونشرت النتيجة للتأكد من عدم وجود نظراء معماريين. ثم حصل على براءة اختراع ونشر مقالًا يحتوي على تفسيرات ، تضمنت العديد من الملاحظات الجريئة حول الأحجام والقابلية للتوسع والسرعة وأشياء أخرى.

بالطبع ، أثار المقال عددًا كبيرًا من الأسئلة التي يجب معالجتها بشكل منفصل: الفرق عن الحلول الحالية وتحليل مقارن للأداء وخطط لبناء استعلامات قاعدة البيانات. وأجب أيضًا عن السؤال: ما هو كل هذا ولماذا؟

نظرًا لأن الموضوع مؤلم للكثيرين ، والفوائد المزعومة طموحة للغاية ، كانت التعليقات قاسية إلى حد ما. والسبب مفهوم - في المقال يرى الجميع على الفور "EAV" ، حول الأشخاص الجادين الذين لا يزالون يكتبون الأبحاث ، في حين أن مشكلة الأداء بشكل عام غير قابلة للحل. كما أبلغت في التعليقات ، فإن EAV لديها مجموعة من أوجه القصور ، وهذا معروف جيدًا ، وأي شخص يدعي الحل النهائي لمشاكل EAV يجب أن يحصل على ركلات سخية في الكارما من أجل الوصول إلى صوابه.

هناك دقة واحدة فقط: لا تقدم المقالة EAV على هذا النحو

كان السؤال الأكثر شيوعًا هو: "كيف يختلف هذا عن EAV ، KV ، Magento ...".

يبدو أن الاختلافات تكمن في كل شيء لا يتناسب مع الخصائص المدرجة:

1. الهيكل - في الجدول 5 أعمدة و 3 فهارس
2. طريقة أخذ العينات - يصف جدول واحد أنواع البيانات وعلاقاتها (البيانات الوصفية) والبيانات نفسها

لكن مثل هذا الجواب لا يناسب العديد من القراء ، لذلك سأحاول أن أشرح بمزيد من التفصيل.

تستخدم البنية الموصوفة دليل EAV ، المكمّل بسمة المعرف ، لأن أي سمة هي أيضًا كيان مستقل يمكن أن يكون له سماته الخاصة ، بالإضافة إلى استخدامه كقيمة مرجعية. أي أن الهيكل لا يقتصر على كونه مرجعًا لـ EAV ، فلماذا لا يمكنني تسميته بـ EAV.

الأهم من ذلك ، أن EAV لا يمكن أن يكون حلاً مكتفيًا ذاتيًا ، إنه مجرد دليل ، أحد عناصر النظام. أنا أتحدث عن حل كامل ومكتفي ذاتيًا ، والذي لا يتطلب أي شيء إضافي لإنشاء هيكل وبيانات وإدارته.

لتوضيح كيف يختلف الحل عن Datomic و Magento وعشرات الآلاف من الحلول والمنتجات الأخرى ، ستحتاج إلى مقارنتها عشرات الآلاف من المرات. لذلك ، سوف أجرؤ على اقتراح أسلوب بسيط يمكنك من خلال بضع دقائق إجراء مقارنة مع أي نظام وتحديد الفرق ، إن وجد.

من الضروري التحقق من استيفاء الشروط التالية للنظام المقارن:

1. يتم تخزين جميع البيانات في جدول واحد (انظر أيضًا الفقرة 3.) تحتوي على الحقول التالية على الأقل: ID ، Parent ID ، Type ID ، Value

2. بالنسبة للجدول ، تم إنشاء المؤشرات التالية على الأقل: ID؛ اكتب معرف + القيمة ؛ معرف الأصل + معرف النوع.

3. يمكن أن يكون هناك العديد من الجداول ، ولكن جميعها تحتوي على الحد الأدنى من الهيكل من العنصر 1 والفهارس ، تختلف حسب نوع حقل القيمة

4. يحتوي الجدول على وصف لأنواع البيانات.

5. يحتوي الجدول على وصف لتفاصيل أنواع البيانات (من مجموعة الأنواع الموضحة فيه)

6. يحتوي الجدول على كائنات بيانات مع مرجع إلى نوعها (من مجموعة الأنواع الموضحة فيه)

7. يحتوي الجدول على تفاصيل الكائنات مع ارتباط إلى الأصل والنوع

8. يتم اختيار الأشياء مع الإشارة الإلزامية لنوع الكائن

9. يتم اختيار تفاصيل الكائن مع الإشارة الإلزامية للوالد والنوع

10. يتم اختيار الكائن بتفاصيله مع الإشارة الإلزامية إلى نوع التفاصيل

11. (اختياري) يتم توصيل الكائنات من خلال التفاصيل التي تحتوي على نوع معرف الكائن المرتبط

إذا تم استيفاء جميع المتطلبات الأساسية ، فلديك نظام يندرج تحت وصف الملاحظات التي تمت مناقشتها هنا.

القضايا الأكثر أهمية تلقي بظلال من الشك على بيان أداء النظام مع نمو الحجم.

بالنسبة للاختبارات المقارنة ، تم عمل قاعدتي بيانات متطابقتين ، تم إنشاء إحداهما في الجداول المعتادة لقاعدة البيانات العلائقية ، والأخرى باستخدام المنهجية المعلنة. فيما يلي نتائج اختبار قاعدتي بيانات مع نصوص الاستعلام وقياسات الوقت وتحليل خطط التنفيذ.

في التعليقات على آخر مشاركة ، تم اقتراح هيكل بسيط للبيانات ذات الصلة ، مناسبة للاختبار. لقد أخذتها كأساس: هذه قائمة تضم 1،048،552 كتابًا من 142،654 مؤلفًا تم إنشاؤها من بيانات عشوائية.

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 .