நவீன தகவல் அமைப்புகள் மிகவும் சிக்கலானவை. எல்லாவற்றிற்கும் மேலாக, அவற்றின் சிக்கலானது அவற்றில் செயலாக்கப்பட்ட தரவுகளின் சிக்கலான தன்மையால் ஏற்படுகிறது. தரவுகளின் சிக்கலானது பெரும்பாலும் பயன்படுத்தப்படும் பல்வேறு தரவு மாதிரிகளில் உள்ளது. எனவே, எடுத்துக்காட்டாக, தரவு "பெரியதாக" மாறும் போது, சிக்கலான பண்புகளில் ஒன்று அதன் தொகுதி ("தொகுதி"), ஆனால் அதன் பல்வேறு ("பல்வேறு") மட்டுமல்ல.

பகுத்தறிவில் இன்னும் குறை காணவில்லை என்றால், படிக்கவும்.

உள்ளடக்கம்

பாலிகிளாட் நிலைத்தன்மை
பல மாதிரி
தொடர்புடைய மாதிரியின் அடிப்படையில் பல மாதிரி DBMS
     MS SQL சேவையகத்தில் ஆவண மாதிரி
     MS SQL சேவையகத்தில் வரைபட மாதிரி
ஆவண மாதிரியின் அடிப்படையில் பல மாதிரி DBMS
     MarkLogic இல் தொடர்புடைய மாதிரி
     MarkLogic இல் வரைபட மாதிரி
பல மாதிரி DBMS "முக்கிய மாதிரி இல்லாமல்"
     அரங்கோடிபி
     OrientDB
     அஸூர் காஸ்மோஸ் டி.பி.
வரைபட மாதிரியை அடிப்படையாகக் கொண்ட பல மாதிரி DBMS?
முடிவுக்கு
பேட்டியில்

பாலிகிளாட் நிலைத்தன்மை

சில நேரங்களில் ஒரு அமைப்பின் கட்டமைப்பிற்குள் கூட, தரவைச் சேமிப்பதற்கும், அவற்றைச் செயலாக்குவதில் உள்ள பல்வேறு சிக்கல்களைத் தீர்ப்பதற்கும் பல்வேறு டிபிஎம்எஸ்களைப் பயன்படுத்துவது அவசியம் என்பதற்கு மேலே உள்ளவை, ஒவ்வொன்றும் அதன் சொந்த தரவு மாதிரியை ஆதரிக்கின்றன. எம். ஃபோலரின் லேசான கையால், நூலாசிரியர் பல பிரபலமான புத்தகங்கள் மற்றும் ஒன்று இணை ஆசிரியர்கள் சுறுசுறுப்பான அறிக்கை, இந்த நிலைமை அழைக்கப்படுகிறது பல வகை சேமிப்பு ("பாலிகிலாட் நிலைத்தன்மை").

இ-காமர்ஸ் துறையில் முழு அம்சமான மற்றும் அதிக சுமை பயன்பாட்டில் தரவு சேமிப்பகத்தை ஒழுங்கமைப்பதற்கான பின்வரும் உதாரணத்தையும் ஃபோலர் கொண்டுள்ளது.

இந்த உதாரணம், நிச்சயமாக, ஓரளவு மிகைப்படுத்தப்பட்டது, ஆனால் தொடர்புடைய நோக்கத்திற்காக ஒன்று அல்லது மற்றொரு DBMS ஐத் தேர்ந்தெடுப்பதற்கு ஆதரவாக சில பரிசீலனைகளைக் காணலாம், எடுத்துக்காட்டாக, இங்கே.

அத்தகைய மிருகக்காட்சிசாலையில் வேலைக்காரனாக இருப்பது எளிதானது அல்ல என்பது தெளிவாகிறது.

பயன்படுத்தப்படும் DBMSகளின் எண்ணிக்கையின் விகிதத்தில் தரவு சேமிப்பகத்தைச் செய்யும் குறியீட்டின் அளவு அதிகரிக்கிறது; குறியீட்டை ஒத்திசைக்கும் தரவின் அளவு இந்த எண்ணின் சதுரத்திற்கு விகிதாசாரமாக இல்லாவிட்டால் நல்லது.
பயன்படுத்தப்படும் DBMSகளின் எண்ணிக்கையின் பெருக்கமாக, பயன்படுத்தப்படும் ஒவ்வொரு DBMSகளின் நிறுவன பண்புகளை (அளவிடுதல், தவறு சகிப்புத்தன்மை, அதிக கிடைக்கும் தன்மை) வழங்குவதற்கான செலவுகள் அதிகரிக்கின்றன.
ஒட்டுமொத்த சேமிப்பக துணை அமைப்பின் நிறுவன பண்புகளை உறுதிப்படுத்துவது சாத்தியமில்லை - குறிப்பாக பரிவர்த்தனை.

மிருகக்காட்சிசாலையின் இயக்குனரின் பார்வையில், எல்லாம் இதுபோல் தெரிகிறது:

டிபிஎம்எஸ் உற்பத்தியாளரிடமிருந்து உரிமங்கள் மற்றும் தொழில்நுட்ப ஆதரவின் விலையில் பல அதிகரிப்பு.
அதிகப்படியான பணியாளர்கள் மற்றும் அதிகரித்த காலக்கெடு.
தரவு முரண்பாட்டின் காரணமாக நேரடி நிதி இழப்புகள் அல்லது அபராதங்கள்.

கணினியின் மொத்த உரிமைச் செலவில் (TCO) குறிப்பிடத்தக்க அதிகரிப்பு உள்ளது. "பல்வேறு சேமிப்பக விருப்பங்கள்" சூழ்நிலையிலிருந்து வெளியேற ஏதாவது வழி உள்ளதா?

பல மாதிரி

"பன்முக சேமிப்பு" என்ற சொல் 2011 இல் பயன்பாட்டுக்கு வந்தது. அணுகுமுறையின் சிக்கல்கள் பற்றிய விழிப்புணர்வு மற்றும் தீர்வுக்கான தேடல் பல ஆண்டுகள் ஆனது, மேலும் 2015 வாக்கில், கார்ட்னர் ஆய்வாளர்களின் வாயிலாக, பதில் உருவாக்கப்பட்டது:

"NoSQL DBMSகளுக்கான சந்தை வழிகாட்டி - 2015»:

DBMSகளின் எதிர்காலம், அவற்றின் கட்டமைப்புகள் மற்றும் அவற்றைப் பயன்படுத்தும் முறைகள் பல மாதிரிகள்.
"ODBMS - 2016க்கான மேஜிக் குவாட்ரன்ட்»:

முன்னணி செயல்பாட்டு DBMSகள் ஒரே தளத்தின் ஒரு பகுதியாக பல மாதிரிகள்-தொடர்புடைய மற்றும் தொடர்பற்றவை-களை வழங்கும்.

இந்த முறை கார்ட்னர் ஆய்வாளர்கள் தங்கள் முன்னறிவிப்புடன் சரியாக இருப்பதாகத் தெரிகிறது. உடன் பக்கம் சென்றால் முக்கிய மதிப்பீடு DB-இன்ஜின்களில் DBMS, அதை நீங்கள் பார்க்கலாம்оஅதன் பெரும்பாலான தலைவர்கள் தங்களை குறிப்பாக பல மாதிரி DBMSகளாக நிலைநிறுத்துகின்றனர். எந்தவொரு தனிப்பட்ட மதிப்பீட்டின் பக்கத்திலும் இதையே காணலாம்.

கீழே உள்ள அட்டவணையில் DBMS - தனிப்பட்ட மதிப்பீடுகள் ஒவ்வொன்றிலும் உள்ள தலைவர்கள், பல மாதிரிகள் எனக் கூறுகின்றனர். ஒவ்வொரு DBMS க்கும், அசல் ஆதரவு மாதிரி (ஒரு காலத்தில் ஒரே மாதிரியாக இருந்தது) மற்றும் அதனுடன் தற்போது ஆதரிக்கப்படும் மாதிரிகள் குறிக்கப்படுகின்றன. மேலும் பட்டியலிடப்பட்ட DBMSகள் "முதலில் பல மாதிரிகள்" என்று தங்களை நிலைநிறுத்திக் கொள்கின்றன, மேலும் படைப்பாளிகளின் கூற்றுப்படி, எந்த ஆரம்ப மரபுவழி மாதிரியும் இல்லை.

டிபிஎம்எஸ்	ஆரம்ப மாதிரி	கூடுதல் மாதிரிகள்
Oracle	உறவுமுறை	வரைபடம், ஆவணம்
MSSQL	உறவுமுறை	வரைபடம், ஆவணம்
போஸ்ட்கெரே	உறவுமுறை	வரைபடம்*, ஆவணம்
மார்க்லாஜிக்	ஆவணப்படம்	வரைபடம், தொடர்புடையது
MongoDB	ஆவணப்படம்	முக்கிய மதிப்பு, வரைபடம்*
டேட்டாஸ்டாக்ஸ்	பரந்த நெடுவரிசை	ஆவணப்படம், வரைபடம்
Redis	முக்கிய மதிப்பு	ஆவணப்படம், வரைபடம்*
அரங்கோடிபி	-	வரைபடம், ஆவணம்
OrientDB	-	வரைபடம், ஆவணம், தொடர்புடையது
அஸூர் காஸ்மோஸ் டி.பி.	-	வரைபடம், ஆவணம், தொடர்புடையது

மேஜையில் குறிப்புகள்

அட்டவணையில் உள்ள நட்சத்திரக் குறியீடுகள் முன்பதிவுகள் தேவைப்படும் அறிக்கைகளைக் குறிக்கின்றன:

PostgreSQL DBMS வரைபட தரவு மாதிரியை ஆதரிக்காது, ஆனால் இந்த தயாரிப்பு அதை ஆதரிக்கிறது அதன் அடிப்படையில், AgensGraph போன்றவை.
மோங்கோடிபி தொடர்பாக, வினவல் மொழியில் வரைபட ஆபரேட்டர்கள் இருப்பதைப் பற்றி பேசுவது மிகவும் சரியானது ($lookup, $graphLookup) வரைபட மாதிரியை ஆதரிப்பதை விட, நிச்சயமாக, அவற்றின் அறிமுகத்திற்கு வரைபட மாதிரியை ஆதரிக்கும் திசையில் இயற்பியல் சேமிப்பக மட்டத்தில் சில மேம்படுத்தல்கள் தேவைப்பட்டன.
ரெடிஸ் தொடர்பாக, நீட்டிப்பைக் குறிக்கிறோம் ரெடிஸ் கிராஃப்.

அடுத்து, ஒவ்வொரு வகுப்பிற்கும், இந்த வகுப்பிலிருந்து DBMS இல் பல மாதிரிகளுக்கான ஆதரவு எவ்வாறு செயல்படுத்தப்படுகிறது என்பதைக் காண்பிப்போம். தொடர்புடைய, ஆவணம் மற்றும் வரைபட மாதிரிகளை நாங்கள் மிக முக்கியமானதாகக் கருதுவோம் மற்றும் "காணாமல் போனவை" எவ்வாறு செயல்படுத்தப்படுகின்றன என்பதைக் காட்ட குறிப்பிட்ட DBMSகளின் உதாரணங்களைப் பயன்படுத்துவோம்.

தொடர்புடைய மாதிரியின் அடிப்படையில் பல மாதிரி DBMS

முன்னணி DBMSகள் தற்போது தொடர்புடையவை; RDBMSகள் மல்டி-மாடலிங் திசையில் இயக்கத்தைக் காட்டவில்லை என்றால் கார்ட்னரின் முன்னறிவிப்பை உண்மையாகக் கருத முடியாது. மற்றும் அவர்கள் நிரூபிக்கிறார்கள். இப்போது மல்டி மாடல் டிபிஎம்எஸ் என்பது சுவிஸ் கத்தியைப் போன்றது, அது எதையும் சிறப்பாகச் செய்ய முடியாது என்ற எண்ணத்தை நேரடியாக லாரி எலிசனுக்குச் செலுத்தலாம்.

இருப்பினும், ஆசிரியர் மைக்ரோசாஃப்ட் SQL சர்வரில் மல்டி-மாடலிங் செயல்படுத்துவதை விரும்புகிறார், இதன் எடுத்துக்காட்டில் ஆவணம் மற்றும் வரைபட மாதிரிகளுக்கான RDBMS ஆதரவு விவரிக்கப்படும்.

MS SQL சேவையகத்தில் ஆவண மாதிரி

ஆவண மாதிரிக்கான ஆதரவை MS SQL சர்வர் எவ்வாறு செயல்படுத்துகிறது என்பது பற்றி ஹப்ரேயில் ஏற்கனவே இரண்டு சிறந்த கட்டுரைகள் வந்துள்ளன; ஒரு சுருக்கமான மறுபரிசீலனை மற்றும் வர்ணனைக்கு நான் என்னை மட்டுப்படுத்துகிறேன்:

MS SQL சேவையகத்தில் ஆவண மாதிரியை ஆதரிப்பதற்கான வழி தொடர்புடைய DBMS களுக்கு மிகவும் பொதுவானது: JSON ஆவணங்கள் சாதாரண உரை புலங்களில் சேமிக்க முன்மொழியப்பட்டுள்ளன. இந்த JSON ஐ அலசுவதற்கு சிறப்பு ஆபரேட்டர்களை வழங்குவதே ஆவண மாதிரிக்கான ஆதரவு:

JSON_VALUE அளவிடல் பண்புக்கூறு மதிப்புகளைப் பிரித்தெடுக்க,
JSON_QUERY துணை ஆவணங்களைப் பிரித்தெடுக்க.

இரண்டு ஆபரேட்டர்களின் இரண்டாவது வாதம் JSONPath போன்ற தொடரியல் ஒரு வெளிப்பாடு ஆகும்.

சுருக்கமாக, இந்த வழியில் சேமிக்கப்பட்ட ஆவணங்கள் டூப்பிள்களைப் போலல்லாமல், தொடர்புடைய DBMS இல் "முதல்-வகுப்பு நிறுவனங்கள்" அல்ல என்று நாம் கூறலாம். குறிப்பாக, MS SQL சேவையகத்தில் தற்போது JSON ஆவணங்களின் புலங்களில் குறியீடுகள் எதுவும் இல்லை, இது இந்த புலங்களின் மதிப்புகளைப் பயன்படுத்தி அட்டவணையில் சேர்வதை கடினமாக்குகிறது மற்றும் இந்த மதிப்புகளைப் பயன்படுத்தி ஆவணங்களைத் தேர்ந்தெடுக்கிறது. இருப்பினும், அத்தகைய புலத்திற்கான கணக்கிடப்பட்ட நெடுவரிசை மற்றும் அதில் ஒரு குறியீட்டை உருவாக்க முடியும்.

கூடுதலாக, MS SQL சேவையகம் ஆபரேட்டரைப் பயன்படுத்தி அட்டவணைகளின் உள்ளடக்கங்களிலிருந்து JSON ஆவணத்தை வசதியாக உருவாக்குவதற்கான திறனை வழங்குகிறது. FOR JSON PATH - ஒரு சாத்தியம், ஒரு குறிப்பிட்ட அர்த்தத்தில், முந்தையதற்கு நேர்மாறாக, வழக்கமான சேமிப்பு. ஒரு RDBMS எவ்வளவு வேகமாக இருந்தாலும், இந்த அணுகுமுறை ஆவண DBMSகளின் சித்தாந்தத்திற்கு முரணானது என்பது தெளிவாகிறது, இது பிரபலமான கேள்விகளுக்கான ஆயத்த பதில்களை முக்கியமாக சேமித்து வைக்கும், மேலும் வளர்ச்சியின் எளிதான சிக்கல்களை மட்டுமே தீர்க்க முடியும், ஆனால் வேகம் அல்ல.

இறுதியாக, MS SQL சேவையகம் ஆவணக் கட்டுமானத்தின் எதிர்ச் சிக்கலைத் தீர்க்க உங்களை அனுமதிக்கிறது: நீங்கள் JSON ஐப் பயன்படுத்தி அட்டவணைகளாகச் சிதைக்கலாம் OPENJSON. ஆவணம் முற்றிலும் தட்டையாக இல்லாவிட்டால், நீங்கள் பயன்படுத்த வேண்டும் CROSS APPLY.

MS SQL சேவையகத்தில் வரைபட மாதிரி

கிராஃப் (எல்பிஜி) மாதிரிக்கான ஆதரவும் மைக்ரோசாஃப்ட் SQL சர்வரில் முழுமையாக செயல்படுத்தப்படுகிறது கணிக்கக்கூடியது: முனைகளை சேமிக்க மற்றும் வரைபட விளிம்புகளை சேமிக்க சிறப்பு அட்டவணைகள் பயன்படுத்த முன்மொழியப்பட்டது. இத்தகைய அட்டவணைகள் வெளிப்பாடுகளைப் பயன்படுத்தி உருவாக்கப்படுகின்றன CREATE TABLE AS NODE и CREATE TABLE AS EDGE முறையே.

முதல் வகை அட்டவணைகள் பதிவுகளை சேமிப்பதற்கான சாதாரண அட்டவணைகளைப் போலவே இருக்கும், ஒரே வெளிப்புற வேறுபாடு அட்டவணையில் கணினி புலம் உள்ளது. $node_id — தரவுத்தளத்தில் உள்ள வரைபட முனையின் தனிப்பட்ட அடையாளங்காட்டி.

இதேபோல், இரண்டாவது வகை அட்டவணைகள் கணினி புலங்களைக் கொண்டுள்ளன $from_id и $to_id, அத்தகைய அட்டவணையில் உள்ள உள்ளீடுகள் முனைகளுக்கு இடையிலான இணைப்புகளை தெளிவாக வரையறுக்கின்றன. ஒவ்வொரு வகை உறவுகளையும் சேமிக்க ஒரு தனி அட்டவணை பயன்படுத்தப்படுகிறது.

இதை ஒரு உதாரணத்தின் மூலம் விளக்குவோம். வரைபடத் தரவு படத்தில் காட்டப்பட்டுள்ளதைப் போன்ற அமைப்பைக் கொண்டிருக்கட்டும். தரவுத்தளத்தில் தொடர்புடைய கட்டமைப்பை உருவாக்க, நீங்கள் பின்வரும் DDL வினவல்களை இயக்க வேண்டும்:

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

அத்தகைய அட்டவணைகளின் முக்கிய விவரம் என்னவென்றால், அவற்றிற்கு எதிரான வினவல்களில் சைஃபர் போன்ற தொடரியல் மூலம் வரைபட வடிவங்களைப் பயன்படுத்த முடியும் (இருப்பினும், "*"முதலியன இன்னும் ஆதரிக்கப்படவில்லை). செயல்திறன் அளவீடுகளின் அடிப்படையில், இந்த அட்டவணையில் தரவு சேமிக்கப்படும் விதம் வழக்கமான அட்டவணையில் தரவு சேமிக்கப்படும் விதத்தில் இருந்து வேறுபட்டது மற்றும் அத்தகைய வரைபட வினவல்களை செயல்படுத்துவதற்கு உகந்ததாக இருக்கும் என்றும் கருதலாம்.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

மேலும், அத்தகைய அட்டவணைகளுடன் பணிபுரியும் போது இந்த வரைபட வடிவங்களைப் பயன்படுத்தாமல் இருப்பது மிகவும் கடினம், ஏனெனில் இதுபோன்ற சிக்கல்களைத் தீர்க்க சாதாரண SQL வினவல்களில் கணினி “வரைபடம்” முனை அடையாளங்காட்டிகளைப் பெற கூடுதல் முயற்சிகளை மேற்கொள்ள வேண்டியது அவசியம் ($node_id, $from_id, $to_id; அதே காரணத்திற்காக, தரவைச் செருகுவதற்கான வினவல்கள் தேவையில்லாமல் சிரமமாக இருப்பதால் இங்கே காட்டப்படவில்லை).

MS SQL சேவையகத்தில் ஆவணம் மற்றும் வரைபட மாதிரிகளின் செயலாக்கங்களின் விளக்கத்தை சுருக்கமாகக் கூற, முதன்மையாக மொழி வடிவமைப்பின் பார்வையில், ஒரு மாதிரியின் மேல் மற்றொன்றின் இத்தகைய செயலாக்கங்கள் வெற்றிகரமாகத் தெரியவில்லை என்பதை நான் கவனிக்கிறேன். ஒரு மொழியை மற்றொரு மொழியுடன் விரிவுபடுத்துவது அவசியம், மொழிகள் முற்றிலும் "ஆர்த்தோகனல்" அல்ல, பொருந்தக்கூடிய விதிகள் மிகவும் வினோதமானவை.

ஆவண மாதிரியின் அடிப்படையில் பல மாதிரி DBMS

இந்த பிரிவில், ஆவண DBMS களில் பல மாதிரிகளை செயல்படுத்துவதை நான் விளக்க விரும்புகிறேன், அவற்றில் மிகவும் பிரபலமாக இல்லாத மோங்கோடிபியின் உதாரணத்தைப் பயன்படுத்தி, இது நிபந்தனை வரைபட ஆபரேட்டர்களை மட்டுமே கொண்டுள்ளது. $lookup и $graphLookup, துண்டாக்கப்பட்ட சேகரிப்புகளில் வேலை செய்யவில்லை), ஆனால் மிகவும் முதிர்ந்த மற்றும் "நிறுவன" DBMS இன் உதாரணத்தைப் பயன்படுத்துதல் மார்க்லாஜிக்.

எனவே, சேகரிப்பில் பின்வரும் வகை எக்ஸ்எம்எல் ஆவணங்கள் இருக்கட்டும் (JSON ஆவணங்களைச் சேமிக்க MarkLogic உங்களை அனுமதிக்கிறது):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

MarkLogic இல் தொடர்புடைய மாதிரி

ஆவணங்களின் தொகுப்பின் தொடர்புடைய காட்சியைப் பயன்படுத்தி உருவாக்கலாம் காட்சி டெம்ப்ளேட் (உறுப்புகளின் உள்ளடக்கம் value கீழே உள்ள எடுத்துக்காட்டில் ஒரு தன்னிச்சையான XPath இருக்கலாம்):

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

SQL வினவல் மூலம் உருவாக்கப்பட்ட காட்சியை நீங்கள் உரையாற்றலாம் (எடுத்துக்காட்டாக, ODBC வழியாக):

SELECT name, surname FROM Person WHERE name="John"

துரதிர்ஷ்டவசமாக, காட்சி டெம்ப்ளேட்டால் உருவாக்கப்பட்ட தொடர்புடைய பார்வை படிக்க மட்டுமே. அதற்கான கோரிக்கையைச் செயல்படுத்தும் போது, MarkLogic பயன்படுத்த முயற்சிக்கும் ஆவணக் குறியீடுகள். முன்னதாக, MarkLogic முற்றிலும் வரையறுக்கப்பட்ட தொடர்புடைய பார்வைகளைக் கொண்டிருந்தது குறியீட்டு அடிப்படையிலானது மற்றும் எழுதக்கூடியது, ஆனால் இப்போது அவை நிராகரிக்கப்பட்டதாகக் கருதப்படுகிறது.

MarkLogic இல் வரைபட மாதிரி

வரைபடம் (RDF) மாதிரிக்கான ஆதரவுடன், எல்லாம் ஒரே மாதிரியாக இருக்கும். மீண்டும் உதவியுடன் காட்சி டெம்ப்ளேட் மேலே உள்ள எடுத்துக்காட்டில் இருந்து ஆவணங்களின் தொகுப்பின் RDF பிரதிநிதித்துவத்தை நீங்கள் உருவாக்கலாம்:

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

SPARQL வினவலின் மூலம் நீங்கள் பெறப்பட்ட RDF வரைபடத்தை நீங்கள் குறிப்பிடலாம்:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

தொடர்புடைய ஒன்றைப் போலன்றி, MarkLogic வரைபட மாதிரியை வேறு இரண்டு வழிகளில் ஆதரிக்கிறது:

DBMS என்பது RDF தரவின் முழு அளவிலான தனி சேமிப்பகமாக இருக்கலாம் (அதில் உள்ள மும்மடங்குகள் என்று அழைக்கப்படும் நிர்வகிக்கப்படும் மேலே விவரிக்கப்பட்டவற்றுக்கு மாறாக பிரித்தெடுக்கப்படும்).
சிறப்பு வரிசைப்படுத்தலில் உள்ள RDF ஆனது XML அல்லது JSON ஆவணங்களில் செருகப்படலாம் (மற்றும் மும்மடங்குகள் பின்னர் அழைக்கப்படும். நிர்வகிக்கப்படாததைப்) இது அநேகமாக பொறிமுறைகளுக்கு மாற்றாக இருக்கலாம் idref மற்றும் மற்றவர்கள்.

MarkLogic இல் விஷயங்கள் "உண்மையில்" எவ்வாறு செயல்படுகின்றன என்பதற்கான நல்ல யோசனை வழங்கப்பட்டுள்ளது ஆப்டிகல் API, இந்த அர்த்தத்தில், இது குறைந்த அளவிலானது, இருப்பினும் அதன் நோக்கம் இதற்கு நேர்மாறானது - பயன்படுத்தப்படும் தரவு மாதிரியிலிருந்து சுருக்க முயற்சிப்பது, வெவ்வேறு மாதிரிகள், பரிவர்த்தனை போன்றவற்றில் தரவுகளுடன் நிலையான வேலையை உறுதி செய்வது.

பல மாதிரி DBMS "முக்கிய மாதிரி இல்லாமல்"

சந்தையில் DBMSகளும் உள்ளன, அவை எந்த மரபுவழி பிரதான மாதிரியும் இல்லாமல், ஆரம்பத்தில் பல-மாடலாக தங்களை நிலைநிறுத்துகின்றன. இதில் அடங்கும் அரங்கோடிபி, OrientDB (2018 முதல் மேம்பாட்டு நிறுவனம் SAP க்கு சொந்தமானது) மற்றும் காஸ்மோஸ்டிபி (மைக்ரோசாஃப்ட் அஸூர் கிளவுட் தளத்தின் ஒரு பகுதியாக சேவை).

உண்மையில், ArangoDB மற்றும் OrientDB இல் "கோர்" மாதிரிகள் உள்ளன. இரண்டு சந்தர்ப்பங்களிலும், இவை அவற்றின் சொந்த தரவு மாதிரிகள், அவை ஆவணம் ஒன்றின் பொதுமைப்படுத்தல்கள் ஆகும். பொதுமைப்படுத்தல்கள் முக்கியமாக ஒரு வரைபடம் மற்றும் தொடர்புடைய தன்மையின் வினவல்களைச் செய்யும் திறனை எளிதாக்குகின்றன.

இந்த மாதிரிகள் மட்டுமே குறிப்பிட்ட DBMS இல் பயன்படுத்தக் கிடைக்கின்றன; அவற்றின் சொந்த வினவல் மொழிகள் அவற்றுடன் வேலை செய்ய வடிவமைக்கப்பட்டுள்ளன. நிச்சயமாக, அத்தகைய மாதிரிகள் மற்றும் DBMS கள் நம்பிக்கைக்குரியவை, ஆனால் நிலையான மாதிரிகள் மற்றும் மொழிகளுடன் இணக்கத்தன்மை இல்லாததால், இந்த DBMS களை மரபு அமைப்புகளில் பயன்படுத்த இயலாது - ஏற்கனவே அங்கு பயன்படுத்தப்பட்ட DBMS களை மாற்றுவதற்கு.

Habré இல் ஏற்கனவே ArangoDB மற்றும் OrientDB பற்றி ஒரு அற்புதமான கட்டுரை இருந்தது: NoSQL தரவுத்தளங்களில் சேரவும்.

அரங்கோடிபி

ArangoDB வரைபட தரவு மாதிரிக்கான ஆதரவைக் கோருகிறது.

ArangoDB இல் உள்ள வரைபடத்தின் முனைகள் சாதாரண ஆவணங்கள், மற்றும் விளிம்புகள் ஒரு சிறப்பு வகை ஆவணங்கள், அவை வழக்கமான கணினி புலங்களுடன், (_key, _id, _rev) அமைப்பு புலங்கள் _from и _to. DBMS ஆவணங்களில் உள்ள ஆவணங்கள் பாரம்பரியமாக சேகரிப்புகளாக இணைக்கப்படுகின்றன. விளிம்புகளைக் குறிக்கும் ஆவணங்களின் தொகுப்புகள் ArangoDB இல் விளிம்பு சேகரிப்புகள் என்று அழைக்கப்படுகின்றன. மூலம், விளிம்பு சேகரிப்பு ஆவணங்களும் ஆவணங்களாகும், எனவே ArangoDB இல் உள்ள விளிம்புகளும் முனைகளாக செயல்படும்.

ரா தரவு

எங்களிடம் ஒரு சேகரிப்பு இருக்கட்டும் persons, யாருடைய ஆவணங்கள் இப்படி இருக்கும்:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

வசூல் கூட இருக்கட்டும் cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

பிறகு வசூல் likes இது போல இருக்கலாம்:

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

கேள்விகள் மற்றும் முடிவுகள்

ArangoDB இல் பயன்படுத்தப்படும் AQL மொழியில் ஒரு வரைபட பாணி வினவல், எந்த ஓட்டலை யார் விரும்புகிறார்கள் என்பது பற்றிய தகவல்களை மனிதர்கள் படிக்கக்கூடிய படிவத்தில் திரும்பப் பெறுவது, இது போல் தெரிகிறது:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

ஒரு தொடர்புடைய பாணியில், நாம் உறவுகளை சேமிப்பதை விட "கணினி" செய்கிறோம், இந்த வினவலை இவ்வாறு மீண்டும் எழுதலாம் (இதன் மூலம், சேகரிப்பு இல்லாமல் likes இல்லாமல் செய்ய முடியும்):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

இரண்டு நிகழ்வுகளிலும் முடிவு ஒரே மாதிரியாக இருக்கும்:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

மேலும் கேள்விகள் மற்றும் முடிவுகள்

மேலே உள்ள முடிவு வடிவம் DBMS ஆவணத்தை விட தொடர்புடைய DBMSக்கு மிகவும் பொதுவானதாகத் தோன்றினால், இந்த வினவலை நீங்கள் முயற்சி செய்யலாம் (அல்லது நீங்கள் பயன்படுத்தலாம் COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

முடிவு இப்படி இருக்கும்:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

OrientDB இல் ஒரு ஆவண மாதிரியின் மேல் வரைபட மாதிரியை செயல்படுத்துவதற்கான அடிப்படை வாய்ப்பு ஆவணப் புலங்கள், அதிகமாகவோ அல்லது குறைவாகவோ நிலையான அளவுகோல் மதிப்புகளுக்கு கூடுதலாக, போன்ற வகைகளின் மதிப்புகளைக் கொண்டுள்ளன LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. இந்த வகைகளின் மதிப்புகள் இணைப்புகள் அல்லது இணைப்புகளின் தொகுப்புகள் ஆகும் அமைப்பு அடையாளங்காட்டிகள் ஆவணங்கள்.

கணினியால் ஒதுக்கப்பட்ட ஆவண அடையாளங்காட்டியானது தரவுத்தளத்தில் உள்ள பதிவின் நிலையைக் குறிக்கும் "உடல் பொருள்" உள்ளது, மேலும் இது போன்றது: @rid : #3:16. எனவே, குறிப்பு பண்புகளின் மதிப்புகள் தேர்வு நிலைமைகளை விட (வரைபட மாதிரியில் உள்ளதைப் போல) உண்மையில் சுட்டிகளாகும் (தொடர்புடைய மாதிரியைப் போல).

ArangoDB போலவே, OrientDB இல் உள்ள விளிம்புகள் தனி ஆவணங்களாகக் குறிப்பிடப்படுகின்றன (ஒரு விளிம்பில் அதன் சொந்த பண்புகள் இல்லை என்றாலும், அதை உருவாக்கலாம் இலகுரக, மற்றும் இது ஒரு தனி ஆவணத்துடன் பொருந்தாது).

ரா தரவு

நெருக்கமான வடிவத்தில் டம்ப் வடிவம் OrientDB தரவுத்தளமானது, ArangoDB க்கான முந்தைய எடுத்துக்காட்டில் இருந்து தரவு இப்படி இருக்கும்:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

நாம் பார்க்க முடியும் என, செங்குத்துகள் உள்வரும் மற்றும் வெளிச்செல்லும் விளிம்புகள் பற்றிய தகவலையும் சேமிக்கின்றன. மணிக்கு பயன்படுத்தி ஆவண API குறிப்பு ஒருமைப்பாட்டைக் கண்காணிக்க வேண்டும், மேலும் வரைபட API இந்த வேலையைச் செய்கிறது. ஆனால் நிரலாக்க மொழிகளில் ஒருங்கிணைக்கப்படாத "தூய" வினவல் மொழிகளில் OrientDBக்கான அணுகல் எப்படி இருக்கும் என்று பார்ப்போம்.

கேள்விகள் மற்றும் முடிவுகள்

OrientDB இல் உள்ள ArangoDBக்கான எடுத்துக்காட்டில் இருந்து வினவலுக்கு ஒத்த நோக்கத்துடன் வினவல் இது போல் தெரிகிறது:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

முடிவு பின்வரும் வடிவத்தில் பெறப்படும்:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

முடிவு வடிவம் மீண்டும் மிகவும் "தொடர்புடையதாக" தோன்றினால், நீங்கள் வரியை அகற்ற வேண்டும் UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

OrientDB இன் வினவல் மொழியை கிரெம்லின் போன்ற செருகல்களுடன் SQL என விவரிக்கலாம். பதிப்பு 2.2 இல், சைஃபர் போன்ற கோரிக்கைப் படிவம் தோன்றியது, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

முடிவு வடிவம் முந்தைய கோரிக்கையில் இருந்ததைப் போலவே இருக்கும். முதல் வினவலைப் போலவே, அதை மேலும் "தொடர்புடையதாக" மாற்றுவதற்கு எதை அகற்ற வேண்டும் என்று சிந்தியுங்கள்.

அஸூர் காஸ்மோஸ் டி.பி.

குறைந்த அளவிற்கு, ArangoDB மற்றும் OrientDB பற்றி மேலே கூறப்பட்டது Azure CosmosDB க்கும் பொருந்தும். CosmosDB பின்வரும் தரவு அணுகல் APIகளை வழங்குகிறது: SQL, MongoDB, Gremlin மற்றும் Cassandra.

ஆவண மாதிரியில் தரவை அணுக SQL API மற்றும் MongoDB API பயன்படுத்தப்படுகின்றன. Gremlin API மற்றும் Cassandra API - முறையே வரைபடம் மற்றும் நெடுவரிசை வடிவங்களில் தரவை அணுகுவதற்கு. அனைத்து மாடல்களிலும் உள்ள தரவு CosmosDB உள் மாதிரி வடிவத்தில் சேமிக்கப்படுகிறது: அதே ARS (“atom-record-sequence”), இது ஆவணம் ஒன்றிற்கு அருகில் உள்ளது.

ஆனால் சேவையில் கணக்கை உருவாக்கும் நேரத்தில் பயனரால் தேர்ந்தெடுக்கப்பட்ட தரவு மாதிரி மற்றும் பயன்படுத்தப்படும் API ஆகியவை சரி செய்யப்படுகின்றன. ஒரு மாதிரியில் ஏற்றப்பட்ட தரவை மற்றொரு மாதிரியின் வடிவத்தில் அணுக முடியாது, இது போன்றவற்றால் விளக்கப்பட்டுள்ளது:

எனவே, இன்று Azure CosmosDB இல் உள்ள மல்டி-மாடல் என்பது ஒரு உற்பத்தியாளரிடமிருந்து வெவ்வேறு மாதிரிகளை ஆதரிக்கும் பல தரவுத்தளங்களைப் பயன்படுத்துவதற்கான திறன் மட்டுமே, இது பல மாறுபாடு சேமிப்பகத்தின் அனைத்து சிக்கல்களையும் தீர்க்காது.

வரைபட மாதிரியை அடிப்படையாகக் கொண்ட பல மாதிரி DBMS?

கிராஃப் மாடலை அடிப்படையாகக் கொண்ட மல்டி-மாடல் டிபிஎம்எஸ்கள் சந்தையில் இன்னும் இல்லை என்பது குறிப்பிடத்தக்கது (ஒரே நேரத்தில் இரண்டு வரைபட மாடல்களுக்கான பல-மாடல் ஆதரவு தவிர: RDF மற்றும் LPG; இதைப் பார்க்கவும் முந்தைய வெளியீடு) தொடர்புடைய ஒன்றைக் காட்டிலும் வரைபட மாதிரியின் மேல் ஒரு ஆவண மாதிரியை செயல்படுத்துவதால் மிகப்பெரிய சிரமங்கள் ஏற்படுகின்றன.

வரைபட மாதிரியின் மேல் ஒரு தொடர்புடைய மாதிரியை எவ்வாறு செயல்படுத்துவது என்ற கேள்வி பிந்தைய உருவாக்கத்தின் போது கூட கருதப்பட்டது. எப்படி பேசினார்உதாரணமாக டேவிட் மெக்கவர்ன்:

(1) வழக்கமான முக்கிய மதிப்பு ஜோடிகளிலிருந்து டூப்பிள்களை மீட்டெடுப்பது மற்றும் (2) குழுவாக்கம் ஆகியவற்றுடன் தொடர்புடைய பார்வையை செயல்படுத்தும் வரைபட தரவுத்தளத்தில் ஒரு அடுக்கை (எ.கா., பொருத்தமான அட்டவணைப்படுத்தல் மூலம்) உருவாக்குவதைத் தடுக்கும் வரைபட அணுகுமுறையில் உள்ளார்ந்த எதுவும் இல்லை. தொடர்பு வகை மூலம் tuples.

வரைபட மாதிரியின் மேல் ஒரு ஆவண மாதிரியை செயல்படுத்தும் போது, நீங்கள் மனதில் கொள்ள வேண்டும், எடுத்துக்காட்டாக, பின்வருவனவற்றை:

JSON வரிசையின் கூறுகள் வரிசைப்படுத்தப்பட்டதாகக் கருதப்படுகின்றன, ஆனால் வரைபடத்தின் விளிம்பின் உச்சியில் இருந்து வெளிப்பட்டவை அல்ல;
ஆவண மாதிரியில் உள்ள தரவு பொதுவாக இயல்புநிலைக்கு மாறானது; நீங்கள் இன்னும் ஒரே உட்பொதிக்கப்பட்ட ஆவணத்தின் பல நகல்களைச் சேமிக்க விரும்பவில்லை, மேலும் துணை ஆவணங்களில் பொதுவாக அடையாளங்காட்டிகள் இருக்காது;
மறுபுறம், ஆவணங்கள் DBMS களின் சித்தாந்தம் என்னவென்றால், ஆவணங்கள் ஒவ்வொரு முறையும் புதிதாக உருவாக்கப்பட வேண்டிய அவசியமில்லாத "தொகுப்புகள்" ஆகும். முடிக்கப்பட்ட ஆவணத்துடன் தொடர்புடைய துணை வரைபடத்தை விரைவாகப் பெறுவதற்கான திறனுடன் வரைபட மாதிரியை வழங்க வேண்டியது அவசியம்.

கொஞ்சம் விளம்பரம்

கட்டுரையின் ஆசிரியர் NitrosBase DBMS இன் வளர்ச்சியுடன் தொடர்புடையவர், இதன் உள் மாதிரி வரைபடம், மற்றும் வெளிப்புற மாதிரிகள் - தொடர்புடைய மற்றும் ஆவணம் - அதன் பிரதிநிதித்துவங்கள். எல்லா மாடல்களும் சமமானவை: எந்தவொரு தரவும் அதில் இயற்கையான வினவல் மொழியைப் பயன்படுத்தி கிடைக்கும். மேலும், எந்த பார்வையிலும், தரவு மாற்றப்படலாம். மாற்றங்கள் உள் மாதிரியிலும், அதன்படி, பிற காட்சிகளிலும் பிரதிபலிக்கும்.

பின்வரும் கட்டுரைகளில் ஒன்றில் NitrosBase இல் மாதிரி பொருத்தம் எப்படி இருக்கும் என்பதை நான் நம்புகிறேன்.

முடிவுக்கு

மல்டி-மாடலிங் என்று சொல்லப்படுபவற்றின் பொதுவான அவுட்லைன்கள் வாசகருக்கு அதிகமாகவோ அல்லது குறைவாகவோ தெளிவாகத் தெரிந்திருக்கும் என்று நம்புகிறேன். மல்டி-மாடல் டிபிஎம்எஸ்கள் முற்றிலும் வேறுபட்டவை, மேலும் “மல்டி மாடல் சப்போர்ட்” வித்தியாசமாக இருக்கும். ஒவ்வொரு குறிப்பிட்ட விஷயத்திலும் "மல்டி-மாடல்" என்று அழைக்கப்படுவதைப் புரிந்து கொள்ள, பின்வரும் கேள்விகளுக்கு பதிலளிப்பது பயனுள்ளது:

நாம் பாரம்பரிய மாதிரிகள் அல்லது சில வகையான "கலப்பின" மாதிரியை ஆதரிப்பது பற்றி பேசுகிறோமா?
மாதிரிகள் "சமமானவை", அல்லது அவற்றில் ஒன்று மற்றவற்றின் பொருளா?
மாதிரிகள் ஒருவருக்கொருவர் "அலட்சியமாக" இருக்கிறதா? ஒரு மாதிரியில் எழுதப்பட்ட தரவை மற்றொன்றில் படிக்க முடியுமா அல்லது மேலெழுத முடியுமா?

மல்டி-மாடல் டிபிஎம்எஸ்ஸின் பொருத்தம் குறித்த கேள்விக்கு ஏற்கனவே சாதகமாக பதிலளிக்க முடியும் என்று நான் நினைக்கிறேன், ஆனால் எதிர்காலத்தில் எந்த வகைகளில் அதிக தேவை இருக்கும் என்பது சுவாரஸ்யமான கேள்வி. பாரம்பரிய மாதிரிகளை ஆதரிக்கும் மல்டி-மாடல் DBMSகள், முதன்மையாக தொடர்புடையவை, அதிக தேவையில் இருக்கும் என்று தெரிகிறது; மல்டி-மாடல் DBMS களின் புகழ், பல்வேறு பாரம்பரியமானவற்றின் நன்மைகளை ஒருங்கிணைக்கும் புதிய மாடல்களை வழங்குவது, இன்னும் தொலைதூர எதிர்காலத்தின் ஒரு விஷயம்.

பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். உள்நுழையவும், தயவு செய்து.

நீங்கள் பல மாதிரி DBMS ஐப் பயன்படுத்துகிறீர்களா?

நாங்கள் அதைப் பயன்படுத்த மாட்டோம், எல்லாவற்றையும் ஒரு டிபிஎம்எஸ் மற்றும் ஒரு மாதிரியில் சேமிக்கிறோம்
பாரம்பரிய DBMSகளின் பல மாதிரி திறன்களைப் பயன்படுத்துகிறோம்
நாங்கள் பாலிகிளாட் பிடிவாதத்தைப் பயிற்சி செய்கிறோம்
நாங்கள் புதிய மல்டி மாடல் DBMS (Arango, Orient, CosmosDB) பயன்படுத்துகிறோம்

19 பயனர்கள் வாக்களித்தனர். 4 பயனர்கள் வாக்களிக்கவில்லை.

ஆதாரம்: www.habr.com

பல மாதிரி DBMSகள் நவீன தகவல் அமைப்புகளின் அடிப்படையா?