प्रोग्रामर के पेटेंट ड्रीम - भाग II

संक्षिप्त पृष्ठभूमि: मेरे अंतिम नोट ने डेटा संग्रहीत करने और पुनर्प्राप्त करने के लिए एक दृष्टिकोण का वर्णन किया, जिस पर आप एक एप्लिकेशन डिजाइनर का निर्माण कर सकते हैं - आधुनिक विकास प्लेटफार्मों के लिए एक विकल्प, लेकिन प्रोग्रामिंग की आवश्यकता के बिना। जैसा कि हम जानते हैं कि यह आविष्कार संभवतः पूरी दुनिया को बदल सकता है।

मैंने एक पेटेंट खोज का संचालन किया और यह सुनिश्चित करने के लिए परिणाम को प्रचारित किया कि कोई वास्तु समकक्ष नहीं थे। फिर उन्होंने एक पेटेंट प्राप्त किया और स्पष्टीकरण के साथ एक लेख प्रकाशित किया, जिसमें वॉल्यूम, स्केलेबिलिटी, गति और अन्य चीजों के बारे में कई साहसिक टिप्पणियां शामिल थीं।

बेशक, लेख ने बड़ी संख्या में प्रश्न उठाए हैं जिन्हें अलग से संबोधित करने की आवश्यकता है: मौजूदा समाधानों से अंतर और डेटाबेस प्रश्नों के निर्माण के लिए प्रदर्शन और योजनाओं का तुलनात्मक विश्लेषण। और प्रश्न का उत्तर भी दें: यह सब क्या है और क्यों है?

चूंकि विषय कई लोगों के लिए दर्दनाक है, और दावा किए गए लाभ बहुत महत्वाकांक्षी हैं, इसलिए टिप्पणियां कठोर थीं। कारण समझ में आता है - लेख में हर कोई तुरंत "ईएवी" देखता है, जिसके बारे में गंभीर लोग अभी भी शोध लिखते हैं, जबकि प्रदर्शन की समस्या आमतौर पर हल नहीं होती है। जैसा कि मुझे टिप्पणियों में सूचित किया गया था, ईएवी में कमियों का एक समूह है, यह अच्छी तरह से जाना जाता है, और जो कोई भी ईएवी समस्याओं के अंतिम समाधान का दावा करता है, उसे अपनी इंद्रियों में आने के लिए कर्म में उदारतापूर्वक किक मिलनी चाहिए।

केवल एक सूक्ष्मता है: लेख ईएवी को इस तरह प्रस्तुत नहीं करता है

सबसे लोकप्रिय सवाल था: "यह ईएवी, केवी, मैगनेटो ... से कैसे अलग है।"

ऐसा लगता है कि अंतर हर चीज में निहित है जो सूचीबद्ध गुणों में फिट नहीं है:

1. संरचना - तालिका में 5 कॉलम और 3 सूचकांक हैं
2. नमूनाकरण विधि - एक तालिका डेटा प्रकारों और उनके संबंधों (मेटा-डेटा) और डेटा का स्वयं वर्णन करती है

लेकिन ऐसा जवाब कई पाठकों को पसंद नहीं आया, इसलिए मैं अधिक विस्तार से समझाने की कोशिश करूंगा।

वर्णित संरचना आईडी विशेषता द्वारा पूरक ईएवी निर्देशिका का उपयोग करती है, क्योंकि कोई भी विशेषता एक स्वतंत्र इकाई है जिसकी अपनी विशेषताएं हो सकती हैं, साथ ही संदर्भ मूल्य के रूप में भी इसका उपयोग किया जा सकता है। यही है, संरचना न केवल ईएवी-संदर्भ के रूप में अभिप्रेत है, क्यों, वास्तव में, मैं इसे ईएवी नहीं कह सकता।

सबसे महत्वपूर्ण बात, ईएवी एक आत्मनिर्भर समाधान नहीं हो सकता है, यह सिर्फ एक मार्गदर्शक है, सिस्टम के तत्वों में से एक है। मैं एक पूर्ण, आत्मनिर्भर समाधान के बारे में बात कर रहा हूं, जिसमें संरचना, डेटा बनाने और इसे प्रबंधित करने के लिए कुछ भी अतिरिक्त करने की आवश्यकता नहीं है।

यह समझाने के लिए कि समाधान डाटॉमिक, मैजेंटो और दसियों हजारों अन्य समाधानों और उत्पादों से कैसे भिन्न है, आपको उनकी तुलना हजारों बार करने की आवश्यकता होगी। इसलिए, मैं एक सरल तकनीक का प्रस्ताव करने के लिए उद्यम करूंगा जिसके द्वारा कुछ मिनटों में आप किसी भी प्रणाली के साथ तुलना कर सकते हैं और अंतर की पहचान कर सकते हैं, यदि कोई हो।

तुलनात्मक प्रणाली के लिए निम्नलिखित शर्तों की पूर्ति को सत्यापित करना आवश्यक है:

1. सभी डेटा एक तालिका में संग्रहीत किया जाता है (यह भी देखें खंड 3.) जिसमें कम से कम निम्नलिखित फ़ील्ड हों: आईडी, पेरेंट आईडी, टाइप आईडी मान

2. तालिका के लिए, कम से कम निम्नलिखित सूचकांक का निर्माण किया जाता है: आईडी; टाइप आईडी + मूल्य; पैरेंट आईडी + टाइप आईडी।

3. कई तालिकाओं हो सकती हैं, लेकिन उन सभी में आइटम 1 और अनुक्रमित से न्यूनतम संरचना होती है, जो मान के प्रकार से भिन्न होती है

4. तालिका में डेटा प्रकारों का विवरण होता है।

5. तालिका में डेटा प्रकारों के विवरण का विवरण होता है (इसमें वर्णित प्रकारों के सेट से)

6. तालिका में उनके प्रकार के संदर्भ के साथ डेटा ऑब्जेक्ट शामिल हैं (इसमें वर्णित प्रकारों के सेट से)

7. तालिका में माता-पिता और लिंक के साथ वस्तुओं का विवरण होता है

8. वस्तुओं का चयन वस्तु के प्रकार के अनिवार्य संकेत के साथ किया जाता है

9. वस्तु के विवरण का चयन माता-पिता के अनिवार्य संकेत और प्रकार के साथ किया जाता है

10. इसके विवरण द्वारा वस्तु का चयन विवरण के प्रकार के अनिवार्य संकेत के साथ किया जाता है

11. (वैकल्पिक) ऑब्जेक्ट जुड़े हुए ऑब्जेक्ट के आईडी के प्रकार के रूप में विवरण के माध्यम से जुड़े हुए हैं

यदि सभी आवश्यक शर्तें पूरी हो जाती हैं, तो आपके पास एक प्रणाली है जो यहां चर्चा किए गए नोटों के विवरण के अंतर्गत आती है।

वॉल्यूम बढ़ने पर सिस्टम के प्रदर्शन के बयान पर अधिक महत्वपूर्ण मुद्दों ने संदेह व्यक्त किया।

तुलनात्मक परीक्षणों के लिए, दो समान डेटाबेस बनाए गए थे, जिनमें से एक रिलेशनल डेटाबेस की सामान्य तालिकाओं में बनाया गया था, और दूसरा घोषित पद्धति का उपयोग करके। नीचे क्वेरी पाठ, समय मापन और निष्पादन योजनाओं के विश्लेषण के साथ दो डेटाबेस के परीक्षा परिणाम दिए गए हैं।

अंतिम पोस्ट पर टिप्पणियों में, संबंधित डेटा की एक सरल संरचना प्रस्तावित की गई थी , जो परीक्षण के लिए उपयुक्त थी। मैंने इसे एक आधार के रूप में लिया: यह यादृच्छिक डेटा से उत्पन्न 142,654 लेखकों की 1,048,552 पुस्तकों की सूची है।

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 .