ಆಧುನಿಕ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿವೆ. ಎಲ್ಲಕ್ಕಿಂತ ಕಡಿಮೆ ಅಲ್ಲ, ಅವುಗಳ ಸಂಕೀರ್ಣತೆಯು ಅವುಗಳಲ್ಲಿ ಸಂಸ್ಕರಿಸಿದ ಡೇಟಾದ ಸಂಕೀರ್ಣತೆಯ ಕಾರಣದಿಂದಾಗಿರುತ್ತದೆ. ಡೇಟಾದ ಸಂಕೀರ್ಣತೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ವಿವಿಧ ಡೇಟಾ ಮಾದರಿಗಳಲ್ಲಿ ಇರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, ಡೇಟಾವು "ದೊಡ್ಡದು" ಆದಾಗ, ಸಮಸ್ಯಾತ್ಮಕ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಒಂದು ಅದರ ಪರಿಮಾಣ ("ಪರಿಮಾಣ"), ಆದರೆ ಅದರ ವೈವಿಧ್ಯತೆ ("ವೈವಿಧ್ಯತೆ") ಮಾತ್ರವಲ್ಲ.

ನೀವು ಇನ್ನೂ ತಾರ್ಕಿಕ ದೋಷವನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ, ನಂತರ ಓದಿ.

ಪರಿವಿಡಿ

ಬಹುಭಾಷಾ ನಿರಂತರತೆ
ಬಹು ಮಾದರಿ
ಸಂಬಂಧಿತ ಮಾದರಿಯ ಆಧಾರದ ಮೇಲೆ ಬಹು-ಮಾದರಿ DBMS
     MS SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿ
     MS SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಗ್ರಾಫ್ ಮಾದರಿ
ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯ ಆಧಾರದ ಮೇಲೆ ಬಹು-ಮಾದರಿ DBMS
     ಮಾರ್ಕ್‌ಲಾಜಿಕ್‌ನಲ್ಲಿ ಸಂಬಂಧಿತ ಮಾದರಿ
     ಮಾರ್ಕ್‌ಲಾಜಿಕ್‌ನಲ್ಲಿ ಗ್ರಾಫ್ ಮಾದರಿ
ಬಹು-ಮಾದರಿ DBMS "ಮುಖ್ಯ ಮಾದರಿ ಇಲ್ಲದೆ"
     ಅರಂಗೋಡಿಬಿ
     ಓರಿಯಂಟ್ ಡಿಬಿ
     ಅಜುರೆ ಕಾಸ್ಮೊಸ್ಡಿಬಿ
ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿ ಬಹು-ಮಾದರಿ DBMS?
ತೀರ್ಮಾನಕ್ಕೆ
ಪೋಲ್

ಬಹುಭಾಷಾ ನಿರಂತರತೆ

ಮೇಲಿನವುಗಳು ಕೆಲವೊಮ್ಮೆ ಒಂದು ಸಿಸ್ಟಮ್ನ ಚೌಕಟ್ಟಿನೊಳಗೆ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ವಿವಿಧ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಹಲವಾರು ವಿಭಿನ್ನ DBMS ಗಳನ್ನು ಬಳಸುವುದು ಅವಶ್ಯಕವಾಗಿದೆ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಡೇಟಾ ಮಾದರಿಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. M. ಫೌಲರ್‌ನ ಲಘು ಹಸ್ತದಿಂದ, ಲೇಖಕ ಹಲವಾರು ಪ್ರಸಿದ್ಧ ಪುಸ್ತಕಗಳು ಮತ್ತು ಒಂದು ಸಹ ಲೇಖಕರು ಅಗೈಲ್ ಮ್ಯಾನಿಫೆಸ್ಟೋ, ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಬಹು-ವೇರಿಯಂಟ್ ಸಂಗ್ರಹಣೆ ("ಪಾಲಿಗ್ಲಾಟ್ ನಿರಂತರತೆ").

ಫೌಲರ್ ಇ-ಕಾಮರ್ಸ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಪೂರ್ಣ-ವೈಶಿಷ್ಟ್ಯದ ಮತ್ತು ಹೆಚ್ಚಿನ-ಲೋಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಂಘಟಿಸುವ ಕೆಳಗಿನ ಉದಾಹರಣೆಯನ್ನು ಸಹ ಹೊಂದಿದೆ.

ಈ ಉದಾಹರಣೆಯು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಉತ್ಪ್ರೇಕ್ಷಿತವಾಗಿದೆ, ಆದರೆ ಅನುಗುಣವಾದ ಉದ್ದೇಶಕ್ಕಾಗಿ ಒಂದು ಅಥವಾ ಇನ್ನೊಂದು DBMS ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪರವಾಗಿ ಕೆಲವು ಪರಿಗಣನೆಗಳನ್ನು ಕಾಣಬಹುದು, ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ.

ಅಂತಹ ಮೃಗಾಲಯದಲ್ಲಿ ಸೇವಕನಾಗುವುದು ಸುಲಭವಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಕೋಡ್‌ನ ಪ್ರಮಾಣವು ಬಳಸಿದ DBMS ಗಳ ಸಂಖ್ಯೆಗೆ ಅನುಗುಣವಾಗಿ ಬೆಳೆಯುತ್ತದೆ; ಈ ಸಂಖ್ಯೆಯ ವರ್ಗಕ್ಕೆ ಅನುಗುಣವಾಗಿಲ್ಲದಿದ್ದರೆ ಕೋಡ್ ಸಿಂಕ್ರೊನೈಸಿಂಗ್ ಡೇಟಾದ ಪ್ರಮಾಣವು ಉತ್ತಮವಾಗಿರುತ್ತದೆ.
ಬಳಸಿದ DBMS ಗಳ ಸಂಖ್ಯೆಯ ಬಹುಸಂಖ್ಯೆಯಂತೆ, ಬಳಸಿದ ಪ್ರತಿಯೊಂದು DBMS ಗಳ ಎಂಟರ್‌ಪ್ರೈಸ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು (ಸ್ಕೇಲೆಬಿಲಿಟಿ, ತಪ್ಪು ಸಹಿಷ್ಣುತೆ, ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ) ಒದಗಿಸುವ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ.
ಒಟ್ಟಾರೆಯಾಗಿ ಶೇಖರಣಾ ಉಪವ್ಯವಸ್ಥೆಯ ಎಂಟರ್‌ಪ್ರೈಸ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ - ವಿಶೇಷವಾಗಿ ವಹಿವಾಟು.

ಮೃಗಾಲಯದ ನಿರ್ದೇಶಕರ ದೃಷ್ಟಿಕೋನದಿಂದ, ಎಲ್ಲವೂ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

DBMS ತಯಾರಕರಿಂದ ಪರವಾನಗಿಗಳು ಮತ್ತು ತಾಂತ್ರಿಕ ಬೆಂಬಲದ ವೆಚ್ಚದಲ್ಲಿ ಬಹು ಹೆಚ್ಚಳ.
ಅತಿಯಾದ ಸಿಬ್ಬಂದಿ ಮತ್ತು ಹೆಚ್ಚಿದ ಗಡುವು.
ಡೇಟಾ ಅಸಂಗತತೆಯಿಂದಾಗಿ ನೇರ ಹಣಕಾಸಿನ ನಷ್ಟಗಳು ಅಥವಾ ದಂಡಗಳು.

ವ್ಯವಸ್ಥೆಯ ಒಟ್ಟು ಮಾಲೀಕತ್ವದ ವೆಚ್ಚದಲ್ಲಿ (TCO) ಗಮನಾರ್ಹ ಹೆಚ್ಚಳವಿದೆ. "ಬಹು ಶೇಖರಣಾ ಆಯ್ಕೆಗಳ" ಪರಿಸ್ಥಿತಿಯಿಂದ ಯಾವುದೇ ಮಾರ್ಗವಿದೆಯೇ?

ಬಹು ಮಾದರಿ

"ಮಲ್ಟಿವೇರಿಯೇಟ್ ಸ್ಟೋರೇಜ್" ಎಂಬ ಪದವು 2011 ರಲ್ಲಿ ಬಳಕೆಗೆ ಬಂದಿತು. ವಿಧಾನದ ಸಮಸ್ಯೆಗಳ ಅರಿವು ಮತ್ತು ಪರಿಹಾರದ ಹುಡುಕಾಟವು ಹಲವಾರು ವರ್ಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು, ಮತ್ತು 2015 ರ ಹೊತ್ತಿಗೆ ಗಾರ್ಟ್ನರ್ ವಿಶ್ಲೇಷಕರ ಬಾಯಿಯ ಮೂಲಕ ಉತ್ತರವನ್ನು ರೂಪಿಸಲಾಯಿತು:

ನಿಂದ "NoSQL DBMS ಗಾಗಿ ಮಾರುಕಟ್ಟೆ ಮಾರ್ಗದರ್ಶಿ - 2015»:

DBMS ಗಳ ಭವಿಷ್ಯ, ಅವುಗಳ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸುವ ವಿಧಾನಗಳು ಬಹು-ಮಾದರಿಯಾಗಿದೆ.
ನಿಂದ "ODBMS ಗಾಗಿ ಮ್ಯಾಜಿಕ್ ಕ್ವಾಡ್ರಾಂಟ್ - 2016»:

ಪ್ರಮುಖ ಕಾರ್ಯಾಚರಣಾ DBMSಗಳು ಒಂದೇ ವೇದಿಕೆಯ ಭಾಗವಾಗಿ ಅನೇಕ ಮಾದರಿಗಳನ್ನು-ಸಂಬಂಧಿತ ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ-ಅನ್ನು ನೀಡುತ್ತವೆ.

ಈ ಬಾರಿ ಗಾರ್ಟ್ನರ್ ವಿಶ್ಲೇಷಕರು ತಮ್ಮ ಮುನ್ಸೂಚನೆಯೊಂದಿಗೆ ಸರಿಯಾಗಿದ್ದರು ಎಂದು ತೋರುತ್ತದೆ. ನೀವು ಪುಟಕ್ಕೆ ಹೋದರೆ ಮುಖ್ಯ ರೇಟಿಂಗ್ DB-ಎಂಜಿನ್‌ಗಳಲ್ಲಿ DBMS, ನೀವು ಅದನ್ನು ನೋಡಬಹುದುоಅದರ ಹೆಚ್ಚಿನ ನಾಯಕರು ತಮ್ಮನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಬಹು-ಮಾದರಿ DBMS ಗಳಾಗಿ ಇರಿಸಿಕೊಂಡಿದ್ದಾರೆ. ಯಾವುದೇ ಖಾಸಗಿ ರೇಟಿಂಗ್‌ನೊಂದಿಗೆ ಪುಟದಲ್ಲಿ ಅದೇ ರೀತಿ ಕಾಣಬಹುದು.

ಕೆಳಗಿನ ಕೋಷ್ಟಕವು DBMS ಅನ್ನು ತೋರಿಸುತ್ತದೆ - ಪ್ರತಿಯೊಂದು ಖಾಸಗಿ ರೇಟಿಂಗ್‌ಗಳಲ್ಲಿನ ನಾಯಕರು, ಬಹು-ಮಾದರಿ ಎಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತಾರೆ. ಪ್ರತಿ DBMS ಗಾಗಿ, ಮೂಲ ಬೆಂಬಲಿತ ಮಾದರಿ (ಒಂದು ಕಾಲದಲ್ಲಿ ಒಂದೇ ಆಗಿತ್ತು) ಮತ್ತು ಅದರೊಂದಿಗೆ ಪ್ರಸ್ತುತ ಬೆಂಬಲಿತ ಮಾದರಿಗಳನ್ನು ಸೂಚಿಸಲಾಗುತ್ತದೆ. "ಮೂಲತಃ ಬಹು-ಮಾದರಿ" ಎಂದು ತಮ್ಮನ್ನು ತಾವು ಇರಿಸಿಕೊಳ್ಳುವ DBMS ಗಳನ್ನು ಸಹ ಪಟ್ಟಿಮಾಡಲಾಗಿದೆ ಮತ್ತು ರಚನೆಕಾರರ ಪ್ರಕಾರ, ಯಾವುದೇ ಆರಂಭಿಕ ಆನುವಂಶಿಕ ಮಾದರಿಯನ್ನು ಹೊಂದಿಲ್ಲ.

ಡಿಬಿಎಂಎಸ್	ಆರಂಭಿಕ ಮಾದರಿ	ಹೆಚ್ಚುವರಿ ಮಾದರಿಗಳು
ಒರಾಕಲ್	ಸಂಬಂಧಿತ	ಗ್ರಾಫ್, ಡಾಕ್ಯುಮೆಂಟ್
MS SQL	ಸಂಬಂಧಿತ	ಗ್ರಾಫ್, ಡಾಕ್ಯುಮೆಂಟ್
PostgreSQL	ಸಂಬಂಧಿತ	ಗ್ರಾಫ್*, ಡಾಕ್ಯುಮೆಂಟ್
ಮಾರ್ಕ್ ಲಾಜಿಕ್	ಸಾಕ್ಷ್ಯಚಿತ್ರ	ಗ್ರಾಫ್, ಸಂಬಂಧಿತ
ಮೊಂಗೋಡಬ್ಬಿ	ಸಾಕ್ಷ್ಯಚಿತ್ರ	ಪ್ರಮುಖ ಮೌಲ್ಯ, ಗ್ರಾಫ್*
ಡೇಟಾಸ್ಟ್ಯಾಕ್ಸ್	ವಿಶಾಲ-ಕಾಲಮ್	ಸಾಕ್ಷ್ಯಚಿತ್ರ, ಗ್ರಾಫ್
ಕೆಂಪು	ಪ್ರಮುಖ ಮೌಲ್ಯ	ಸಾಕ್ಷ್ಯಚಿತ್ರ, ಗ್ರಾಫ್*
ಅರಂಗೋಡಿಬಿ	-	ಗ್ರಾಫ್, ಡಾಕ್ಯುಮೆಂಟ್
ಓರಿಯಂಟ್ ಡಿಬಿ	-	ಗ್ರಾಫ್, ಡಾಕ್ಯುಮೆಂಟ್, ಸಂಬಂಧಿತ
ಅಜುರೆ ಕಾಸ್ಮೊಸ್ಡಿಬಿ	-	ಗ್ರಾಫ್, ಡಾಕ್ಯುಮೆಂಟ್, ಸಂಬಂಧಿತ

ಮೇಜಿನ ಮೇಲೆ ಟಿಪ್ಪಣಿಗಳು

ಟೇಬಲ್‌ನಲ್ಲಿನ ನಕ್ಷತ್ರ ಚಿಹ್ನೆಗಳು ಮೀಸಲಾತಿ ಅಗತ್ಯವಿರುವ ಹೇಳಿಕೆಗಳನ್ನು ಗುರುತಿಸುತ್ತವೆ:

PostgreSQL DBMS ಗ್ರಾಫ್ ಡೇಟಾ ಮಾದರಿಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಆದರೆ ಈ ಉತ್ಪನ್ನವು ಅದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಅದರ ಆಧಾರದ ಮೇಲೆ, ಅಜೆನ್ಸ್‌ಗ್ರಾಫ್‌ನಂತಹವು.
MongoDB ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಪ್ರಶ್ನೆ ಭಾಷೆಯಲ್ಲಿ ಗ್ರಾಫ್ ಆಪರೇಟರ್‌ಗಳ ಉಪಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಮಾತನಾಡುವುದು ಹೆಚ್ಚು ಸರಿಯಾಗಿದೆ ($lookup, $graphLookup) ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಬೆಂಬಲಿಸುವುದಕ್ಕಿಂತ, ಆದಾಗ್ಯೂ, ಅವರ ಪರಿಚಯವು ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಬೆಂಬಲಿಸುವ ದಿಕ್ಕಿನಲ್ಲಿ ಭೌತಿಕ ಶೇಖರಣಾ ಮಟ್ಟದಲ್ಲಿ ಕೆಲವು ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳ ಅಗತ್ಯವಿದೆ.
ರೆಡಿಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾವು ವಿಸ್ತರಣೆಯನ್ನು ಅರ್ಥೈಸುತ್ತೇವೆ ರೆಡಿಸ್ಗ್ರಾಫ್.

ಮುಂದೆ, ಪ್ರತಿಯೊಂದು ತರಗತಿಗಳಿಗೆ, ಈ ವರ್ಗದಿಂದ DBMS ನಲ್ಲಿ ಹಲವಾರು ಮಾದರಿಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ತೋರಿಸುತ್ತೇವೆ. ನಾವು ಸಂಬಂಧಿತ, ಡಾಕ್ಯುಮೆಂಟ್ ಮತ್ತು ಗ್ರಾಫ್ ಮಾದರಿಗಳನ್ನು ಅತ್ಯಂತ ಪ್ರಮುಖವೆಂದು ಪರಿಗಣಿಸುತ್ತೇವೆ ಮತ್ತು "ಕಾಣೆಯಾದವುಗಳನ್ನು" ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ನಿರ್ದಿಷ್ಟ DBMS ಗಳ ಉದಾಹರಣೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.

ಸಂಬಂಧಿತ ಮಾದರಿಯ ಆಧಾರದ ಮೇಲೆ ಬಹು-ಮಾದರಿ DBMS

ಪ್ರಸ್ತುತ ಪ್ರಮುಖ DBMS ಗಳು ಸಂಬಂಧಿತವಾಗಿವೆ; RDBMS ಗಳು ಬಹು-ಮಾಡೆಲಿಂಗ್‌ನ ದಿಕ್ಕಿನಲ್ಲಿ ಚಲನೆಯನ್ನು ತೋರಿಸದಿದ್ದರೆ ಗಾರ್ಟ್‌ನರ್‌ನ ಮುನ್ಸೂಚನೆಯನ್ನು ನಿಜವೆಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಅವರು ಪ್ರದರ್ಶಿಸುತ್ತಾರೆ. ಈಗ ಬಹು-ಮಾದರಿ DBMS ಸ್ವಿಸ್ ಚಾಕುವಿನಂತಿದೆ, ಅದು ಉತ್ತಮವಾಗಿ ಏನನ್ನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ನೇರವಾಗಿ ಲ್ಯಾರಿ ಎಲಿಸನ್‌ಗೆ ನಿರ್ದೇಶಿಸಬಹುದು.

ಆದಾಗ್ಯೂ, ಲೇಖಕರು ಮೈಕ್ರೋಸಾಫ್ಟ್ SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಬಹು-ಮಾಡೆಲಿಂಗ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುತ್ತಾರೆ, ಅದರ ಉದಾಹರಣೆಯಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಮತ್ತು ಗ್ರಾಫ್ ಮಾದರಿಗಳಿಗೆ RDBMS ಬೆಂಬಲವನ್ನು ವಿವರಿಸಲಾಗುತ್ತದೆ.

MS SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿ

MS SQL ಸರ್ವರ್ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾಡೆಲ್‌ಗೆ ಹೇಗೆ ಬೆಂಬಲವನ್ನು ಅಳವಡಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಹ್ಯಾಬ್ರೆಯಲ್ಲಿ ಈಗಾಗಲೇ ಎರಡು ಅತ್ಯುತ್ತಮ ಲೇಖನಗಳಿವೆ; ನಾನು ಸಂಕ್ಷಿಪ್ತ ಪುನರಾವರ್ತನೆ ಮತ್ತು ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತೇನೆ:

MS SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯನ್ನು ಬೆಂಬಲಿಸುವ ವಿಧಾನವು ಸಂಬಂಧಿತ DBMS ಗಳಿಗೆ ಸಾಕಷ್ಟು ವಿಶಿಷ್ಟವಾಗಿದೆ: JSON ದಾಖಲೆಗಳನ್ನು ಸಾಮಾನ್ಯ ಪಠ್ಯ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ. ಈ JSON ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ವಿಶೇಷ ಆಪರೇಟರ್‌ಗಳನ್ನು ಒದಗಿಸುವುದು ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಗೆ ಬೆಂಬಲವಾಗಿದೆ:

JSON_VALUE ಸ್ಕೇಲಾರ್ ಗುಣಲಕ್ಷಣ ಮೌಲ್ಯಗಳನ್ನು ಹೊರತೆಗೆಯಲು,
JSON_QUERY ಉಪ ದಾಖಲೆಗಳನ್ನು ಹೊರತೆಗೆಯಲು.

ಎರಡೂ ಆಪರೇಟರ್‌ಗಳ ಎರಡನೇ ವಾದವು JSONPath-ರೀತಿಯ ಸಿಂಟ್ಯಾಕ್ಸ್‌ನಲ್ಲಿನ ಅಭಿವ್ಯಕ್ತಿಯಾಗಿದೆ.

ಅಮೂರ್ತವಾಗಿ, ಈ ರೀತಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ದಾಖಲೆಗಳು ಸಂಬಂಧಿತ DBMS ನಲ್ಲಿ "ಪ್ರಥಮ ದರ್ಜೆಯ ಘಟಕಗಳು" ಅಲ್ಲ ಎಂದು ನಾವು ಹೇಳಬಹುದು, tuples ಗಿಂತ ಭಿನ್ನವಾಗಿ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, MS SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರಸ್ತುತ JSON ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಯಾವುದೇ ಸೂಚ್ಯಂಕಗಳಿಲ್ಲ, ಇದು ಈ ಕ್ಷೇತ್ರಗಳ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕೋಷ್ಟಕಗಳನ್ನು ಸೇರಲು ಕಷ್ಟವಾಗುತ್ತದೆ ಮತ್ತು ಈ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅಂತಹ ಕ್ಷೇತ್ರಕ್ಕಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ ಕಾಲಮ್ ಮತ್ತು ಅದರ ಮೇಲೆ ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಿದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, MS SQL ಸರ್ವರ್ ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕೋಷ್ಟಕಗಳ ವಿಷಯಗಳಿಂದ JSON ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಅನುಕೂಲಕರವಾಗಿ ನಿರ್ಮಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. FOR JSON PATH - ಒಂದು ಸಾಧ್ಯತೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಅರ್ಥದಲ್ಲಿ, ಹಿಂದಿನದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಸಾಂಪ್ರದಾಯಿಕ ಸಂಗ್ರಹಣೆ. RDBMS ಎಷ್ಟೇ ವೇಗವಾಗಿದ್ದರೂ, ಈ ವಿಧಾನವು ಡಾಕ್ಯುಮೆಂಟ್ DBMS ಗಳ ಸಿದ್ಧಾಂತಕ್ಕೆ ವಿರುದ್ಧವಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಇದು ಮೂಲಭೂತವಾಗಿ ಜನಪ್ರಿಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಸಿದ್ಧ ಉತ್ತರಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಸುಲಭದ ಸಮಸ್ಯೆಗಳನ್ನು ಮಾತ್ರ ಪರಿಹರಿಸುತ್ತದೆ, ಆದರೆ ವೇಗವಲ್ಲ.

ಅಂತಿಮವಾಗಿ, ಡಾಕ್ಯುಮೆಂಟ್ ನಿರ್ಮಾಣದ ವಿಲೋಮ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು MS SQL ಸರ್ವರ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ: ನೀವು JSON ಅನ್ನು ಟೇಬಲ್‌ಗಳಾಗಿ ವಿಭಜಿಸಬಹುದು OPENJSON. ಡಾಕ್ಯುಮೆಂಟ್ ಸಂಪೂರ್ಣವಾಗಿ ಸಮತಟ್ಟಾಗಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ CROSS APPLY.

MS SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಗ್ರಾಫ್ ಮಾದರಿ

ಗ್ರಾಫ್ (LPG) ಮಾದರಿಗೆ ಬೆಂಬಲವನ್ನು ಮೈಕ್ರೋಸಾಫ್ಟ್ 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 ಗಳಲ್ಲಿ ಬಹು-ಮಾದರಿಯ ಅನುಷ್ಠಾನವನ್ನು ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚು ಜನಪ್ರಿಯವಲ್ಲದ MongoDB ಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು ವಿವರಿಸಲು ಬಯಸುತ್ತೇನೆ (ಹೇಳುವಂತೆ, ಇದು ಷರತ್ತುಬದ್ಧ ಗ್ರಾಫ್ ಆಪರೇಟರ್‌ಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿದೆ. $lookup и $graphLookup, ಚೂರುಚೂರು ಸಂಗ್ರಹಣೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ), ಆದರೆ ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ ಮತ್ತು "ಉದ್ಯಮ" DBMS ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸುವುದು ಮಾರ್ಕ್ ಲಾಜಿಕ್.

ಆದ್ದರಿಂದ, ಸಂಗ್ರಹಣೆಯು ಈ ಕೆಳಗಿನ ಪ್ರಕಾರದ XML ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಿರಲಿ (ಮಾರ್ಕ್‌ಲಾಜಿಕ್ ನಿಮಗೆ JSON ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಹ ಅನುಮತಿಸುತ್ತದೆ):

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

ಮಾರ್ಕ್‌ಲಾಜಿಕ್‌ನಲ್ಲಿ ಸಂಬಂಧಿತ ಮಾದರಿ

ದಾಖಲೆಗಳ ಸಂಗ್ರಹದ ಸಂಬಂಧಿತ ನೋಟವನ್ನು ಬಳಸಿಕೊಂಡು ರಚಿಸಬಹುದು ಪ್ರದರ್ಶನ ಟೆಂಪ್ಲೇಟ್ (ಅಂಶಗಳ ವಿಷಯ 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 ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಡಾಕ್ಯುಮೆಂಟ್ ಸೂಚ್ಯಂಕಗಳು. ಹಿಂದೆ, ಮಾರ್ಕ್‌ಲಾಜಿಕ್ ಸಂಪೂರ್ಣವಾಗಿ ಸೀಮಿತ ಸಂಬಂಧಿತ ವೀಕ್ಷಣೆಗಳನ್ನು ಹೊಂದಿತ್ತು ಸೂಚ್ಯಂಕ ಆಧಾರಿತ ಮತ್ತು ಬರೆಯಬಹುದಾದ, ಆದರೆ ಈಗ ಅವುಗಳನ್ನು ಅಸಮ್ಮತಿ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.

ಮಾರ್ಕ್‌ಲಾಜಿಕ್‌ನಲ್ಲಿ ಗ್ರಾಫ್ ಮಾದರಿ

ಗ್ರಾಫ್ (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 ಮತ್ತು ಇತರರು.

ಮಾರ್ಕ್‌ಲಾಜಿಕ್‌ನಲ್ಲಿ ವಿಷಯಗಳು "ನಿಜವಾಗಿಯೂ" ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ಉತ್ತಮ ಕಲ್ಪನೆಯನ್ನು ನೀಡಲಾಗಿದೆ ಆಪ್ಟಿಕಲ್ API, ಈ ಅರ್ಥದಲ್ಲಿ, ಇದು ಕಡಿಮೆ-ಹಂತವಾಗಿದೆ, ಆದಾಗ್ಯೂ ಅದರ ಉದ್ದೇಶವು ವಿರುದ್ಧವಾಗಿರುತ್ತದೆ - ಬಳಸಿದ ಡೇಟಾ ಮಾದರಿಯಿಂದ ಅಮೂರ್ತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಲು, ವಿಭಿನ್ನ ಮಾದರಿಗಳಲ್ಲಿ ಡೇಟಾದೊಂದಿಗೆ ಸ್ಥಿರವಾದ ಕೆಲಸವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ವಹಿವಾಟು ಇತ್ಯಾದಿ.

ಬಹು-ಮಾದರಿ DBMS "ಮುಖ್ಯ ಮಾದರಿ ಇಲ್ಲದೆ"

ಯಾವುದೇ ಆನುವಂಶಿಕ ಮುಖ್ಯ ಮಾದರಿಯಿಲ್ಲದೆಯೇ ಆರಂಭದಲ್ಲಿ ಬಹು-ಮಾದರಿಯಾಗಿ ತಮ್ಮನ್ನು ತಾವು ಇರಿಸಿಕೊಳ್ಳುವ DBMS ಗಳು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿವೆ. ಇವುಗಳ ಸಹಿತ ಅರಂಗೋಡಿಬಿ, ಓರಿಯಂಟ್ ಡಿಬಿ (2018 ರಿಂದ ಅಭಿವೃದ್ಧಿ ಕಂಪನಿಯು SAP ಗೆ ಸೇರಿದೆ) ಮತ್ತು ಕಾಸ್ಮೊಸ್ಡಿಬಿ (ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಜುರೆ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಭಾಗವಾಗಿ ಸೇವೆ).

ವಾಸ್ತವವಾಗಿ, ArangoDB ಮತ್ತು OrientDB ನಲ್ಲಿ "ಕೋರ್" ಮಾದರಿಗಳಿವೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಇವುಗಳು ತಮ್ಮದೇ ಆದ ಡೇಟಾ ಮಾದರಿಗಳಾಗಿವೆ, ಅವುಗಳು ಡಾಕ್ಯುಮೆಂಟ್ ಒಂದರ ಸಾಮಾನ್ಯೀಕರಣಗಳಾಗಿವೆ. ಸಾಮಾನ್ಯೀಕರಣಗಳು ಮುಖ್ಯವಾಗಿ ಗ್ರಾಫ್ ಮತ್ತು ಸಂಬಂಧಿತ ಸ್ವಭಾವದ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸುಲಭಗೊಳಿಸಲು.

ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ DBMS ನಲ್ಲಿ ಬಳಸಲು ಈ ಮಾದರಿಗಳು ಮಾತ್ರ ಲಭ್ಯವಿವೆ; ಅವರ ಸ್ವಂತ ಪ್ರಶ್ನೆ ಭಾಷೆಗಳನ್ನು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಸಹಜವಾಗಿ, ಅಂತಹ ಮಾದರಿಗಳು ಮತ್ತು DBMS ಗಳು ಭರವಸೆ ನೀಡುತ್ತವೆ, ಆದರೆ ಪ್ರಮಾಣಿತ ಮಾದರಿಗಳು ಮತ್ತು ಭಾಷೆಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆಯು ಈ DBMS ಗಳನ್ನು ಪರಂಪರೆ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬಳಸಲು ಅಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ-ಅಲ್ಲಿ ಈಗಾಗಲೇ ಬಳಸಿದ DBMS ಗಳನ್ನು ಬದಲಿಸಲು.

Habé ನಲ್ಲಿ 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 : ["Джон Донн"] }
]

ಓರಿಯಂಟ್ ಡಿಬಿ

ಓರಿಯಂಟ್‌ಡಿಬಿಯಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯ ಮೇಲೆ ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಆಧಾರವಾಗಿದೆ ಅವಕಾಶವನ್ನು ಡಾಕ್ಯುಮೆಂಟ್ ಕ್ಷೇತ್ರಗಳು, ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಪ್ರಮಾಣಿತ ಸ್ಕೇಲಾರ್ ಮೌಲ್ಯಗಳ ಜೊತೆಗೆ, ರೀತಿಯ ಮೌಲ್ಯಗಳನ್ನು ಸಹ ಹೊಂದಿವೆ 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 ಯಲ್ಲಿನ 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": [ "Жан-Жак" ' }
]

ಓರಿಯಂಟ್‌ಡಿಬಿಯ ಪ್ರಶ್ನೆ ಭಾಷೆಯನ್ನು ಗ್ರೆಮ್ಲಿನ್ ತರಹದ ಒಳಸೇರಿಸುವಿಕೆಯೊಂದಿಗೆ 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 ಕುರಿತು ಮೇಲೆ ಹೇಳಿರುವುದು ಅಜುರೆ ಕಾಸ್ಮೊಸ್‌ಡಿಬಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. CosmosDB ಕೆಳಗಿನ ಡೇಟಾ ಪ್ರವೇಶ APIಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ: SQL, MongoDB, Gremlin ಮತ್ತು Cassandra.

ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು SQL API ಮತ್ತು MongoDB API ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಗ್ರೆಮ್ಲಿನ್ API ಮತ್ತು ಕಸ್ಸಂದ್ರ API - ಅನುಕ್ರಮವಾಗಿ ಗ್ರಾಫ್ ಮತ್ತು ಕಾಲಮ್ ಸ್ವರೂಪಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು. ಎಲ್ಲಾ ಮಾದರಿಗಳಲ್ಲಿನ ಡೇಟಾವನ್ನು CosmosDB ಆಂತರಿಕ ಮಾದರಿ ಸ್ವರೂಪದಲ್ಲಿ ಉಳಿಸಲಾಗಿದೆ: ARS ("ಪರಮಾಣು-ದಾಖಲೆ-ಅನುಕ್ರಮ"), ಇದು ಡಾಕ್ಯುಮೆಂಟ್ ಒಂದಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ.

ಆದರೆ ಸೇವೆಯಲ್ಲಿ ಖಾತೆಯನ್ನು ರಚಿಸುವ ಸಮಯದಲ್ಲಿ ಬಳಕೆದಾರರು ಆಯ್ಕೆ ಮಾಡಿದ ಡೇಟಾ ಮಾದರಿ ಮತ್ತು ಬಳಸಿದ API ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ಒಂದು ಮಾದರಿಯಲ್ಲಿ ಲೋಡ್ ಮಾಡಲಾದ ಡೇಟಾವನ್ನು ಮತ್ತೊಂದು ಮಾದರಿಯ ಸ್ವರೂಪದಲ್ಲಿ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಈ ರೀತಿಯಿಂದ ವಿವರಿಸಲಾಗಿದೆ:

ಹೀಗಾಗಿ, ಅಜುರೆ ಕಾಸ್ಮೊಸ್‌ಡಿಬಿಯಲ್ಲಿನ ಬಹು-ಮಾದರಿಯು ಇಂದು ಒಂದು ತಯಾರಕರಿಂದ ವಿವಿಧ ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಹಲವಾರು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯ ಮಾತ್ರ, ಇದು ಬಹು-ವಿಭಿನ್ನ ಸಂಗ್ರಹಣೆಯ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ.

ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿ ಬಹು-ಮಾದರಿ DBMS?

ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿದ ಯಾವುದೇ ಬಹು-ಮಾದರಿ DBMS ಗಳು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಇನ್ನೂ ಇಲ್ಲ ಎಂಬುದು ಗಮನಾರ್ಹ ಅಂಶವಾಗಿದೆ (ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಗ್ರಾಫ್ ಮಾದರಿಗಳಿಗೆ ಬಹು-ಮಾದರಿ ಬೆಂಬಲವನ್ನು ಹೊರತುಪಡಿಸಿ: RDF ಮತ್ತು LPG; ಇದನ್ನು ನೋಡಿ ಹಿಂದಿನ ಪ್ರಕಟಣೆ) ಸಂಬಂಧಿತ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಗ್ರಾಫ್ ಮಾದರಿಯ ಮೇಲೆ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯ ಅನುಷ್ಠಾನದಿಂದ ಹೆಚ್ಚಿನ ತೊಂದರೆಗಳು ಉಂಟಾಗುತ್ತವೆ.

ಗ್ರಾಫ್ ಮಾದರಿಯ ಮೇಲೆ ಸಂಬಂಧಿತ ಮಾದರಿಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ನಂತರದ ರಚನೆಯ ಸಮಯದಲ್ಲಿಯೂ ಪರಿಗಣಿಸಲಾಗಿದೆ. ಹೇಗೆ ಹೇಳಿದರುಉದಾಹರಣೆಗೆ ಡೇವಿಡ್ ಮೆಕ್‌ಗವರ್ನ್:

ಗ್ರಾಫ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪದರವನ್ನು (ಉದಾಹರಣೆಗೆ, ಸೂಕ್ತವಾದ ಸೂಚ್ಯಂಕದಿಂದ) ರಚಿಸುವುದನ್ನು ತಡೆಯುವ ಗ್ರಾಫ್ ವಿಧಾನದಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿರುವ ಏನೂ ಇಲ್ಲ, ಅದು ಸಂಬಂಧಿತ ವೀಕ್ಷಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ (1) ಸಾಮಾನ್ಯ ಪ್ರಮುಖ ಮೌಲ್ಯದ ಜೋಡಿಗಳಿಂದ ಟ್ಯೂಪಲ್‌ಗಳ ಮರುಪಡೆಯುವಿಕೆ ಮತ್ತು (2) ಗುಂಪು ಸಂಬಂಧದ ಪ್ರಕಾರದಿಂದ tuples.

ಗ್ರಾಫ್ ಮಾದರಿಯ ಮೇಲೆ ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ನೀವು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು, ಉದಾಹರಣೆಗೆ, ಈ ಕೆಳಗಿನವುಗಳು:

JSON ರಚನೆಯ ಅಂಶಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಗ್ರಾಫ್‌ನ ಅಂಚಿನ ಶೃಂಗದಿಂದ ಹೊರಹೊಮ್ಮುವವುಗಳು ಅಲ್ಲ;
ಡಾಕ್ಯುಮೆಂಟ್ ಮಾದರಿಯಲ್ಲಿನ ಡೇಟಾವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಅಮಾನ್ಯಗೊಳಿಸಲಾಗುತ್ತದೆ; ಒಂದೇ ಎಂಬೆಡೆಡ್ ಡಾಕ್ಯುಮೆಂಟ್‌ನ ಹಲವಾರು ಪ್ರತಿಗಳನ್ನು ನೀವು ಇನ್ನೂ ಸಂಗ್ರಹಿಸಲು ಬಯಸುವುದಿಲ್ಲ ಮತ್ತು ಉಪಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ;
ಮತ್ತೊಂದೆಡೆ, ಡಾಕ್ಯುಮೆಂಟ್ DBMS ಗಳ ಸಿದ್ಧಾಂತವು ಡಾಕ್ಯುಮೆಂಟ್ಗಳು ಸಿದ್ಧವಾದ "ಸಮೂಹಗಳು" ಆಗಿದ್ದು ಅದು ಪ್ರತಿ ಬಾರಿಯೂ ಹೊಸದಾಗಿ ನಿರ್ಮಿಸಬೇಕಾಗಿಲ್ಲ. ಸಿದ್ಧಪಡಿಸಿದ ಡಾಕ್ಯುಮೆಂಟ್‌ಗೆ ಅನುಗುಣವಾದ ಸಬ್‌ಗ್ರಾಫ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಗ್ರಾಫ್ ಮಾದರಿಯನ್ನು ಒದಗಿಸುವ ಅಗತ್ಯವಿದೆ.

ಸ್ವಲ್ಪ ಜಾಹೀರಾತು

ಲೇಖನದ ಲೇಖಕರು NitrosBase DBMS ನ ಅಭಿವೃದ್ಧಿಗೆ ಸಂಬಂಧಿಸಿದೆ, ಅದರ ಆಂತರಿಕ ಮಾದರಿಯು ಗ್ರಾಫ್, ಮತ್ತು ಬಾಹ್ಯ ಮಾದರಿಗಳು - ಸಂಬಂಧಿತ ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟ್ - ಅದರ ಪ್ರಾತಿನಿಧ್ಯಗಳಾಗಿವೆ. ಎಲ್ಲಾ ಮಾದರಿಗಳು ಸಮಾನವಾಗಿವೆ: ಯಾವುದೇ ಡೇಟಾವು ಸ್ವಾಭಾವಿಕವಾದ ಪ್ರಶ್ನೆ ಭಾಷೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಲಭ್ಯವಿದೆ. ಇದಲ್ಲದೆ, ಯಾವುದೇ ನೋಟದಲ್ಲಿ, ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಬದಲಾವಣೆಗಳು ಆಂತರಿಕ ಮಾದರಿಯಲ್ಲಿ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಇತರ ವೀಕ್ಷಣೆಗಳಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ.

ಕೆಳಗಿನ ಲೇಖನಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ NitrosBase ನಲ್ಲಿ ಯಾವ ಮಾದರಿ ಹೊಂದಾಣಿಕೆಯು ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ಆಶಾದಾಯಕವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಬಹು-ಮಾಡೆಲಿಂಗ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಾಮಾನ್ಯ ರೂಪರೇಖೆಗಳು ಓದುಗರಿಗೆ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಬಹು-ಮಾದರಿ DBMS ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ ಮತ್ತು "ಮಲ್ಟಿ-ಮಾಡೆಲ್ ಬೆಂಬಲ" ವಿಭಿನ್ನವಾಗಿ ಕಾಣಿಸಬಹುದು. ಪ್ರತಿಯೊಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣದಲ್ಲಿ "ಮಲ್ಟಿ-ಮಾಡೆಲ್" ಎಂದು ಕರೆಯುವುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ:

ನಾವು ಸಾಂಪ್ರದಾಯಿಕ ಮಾದರಿಗಳನ್ನು ಅಥವಾ ಕೆಲವು ರೀತಿಯ "ಹೈಬ್ರಿಡ್" ಮಾದರಿಯನ್ನು ಬೆಂಬಲಿಸುವ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆಯೇ?
ಮಾದರಿಗಳು "ಸಮಾನ", ಅಥವಾ ಅವುಗಳಲ್ಲಿ ಒಂದು ಇತರ ವಿಷಯವಾಗಿದೆಯೇ?
ಮಾದರಿಗಳು ಪರಸ್ಪರ "ಅಸಡ್ಡೆ"? ಒಂದು ಮಾದರಿಯಲ್ಲಿ ಬರೆಯಲಾದ ಡೇಟಾವನ್ನು ಇನ್ನೊಂದರಲ್ಲಿ ಓದಬಹುದೇ ಅಥವಾ ತಿದ್ದಿ ಬರೆಯಬಹುದೇ?

ಬಹು-ಮಾದರಿ DBMS ನ ಪ್ರಸ್ತುತತೆಯ ಕುರಿತಾದ ಪ್ರಶ್ನೆಗೆ ಈಗಾಗಲೇ ಧನಾತ್ಮಕವಾಗಿ ಉತ್ತರಿಸಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಅವುಗಳಲ್ಲಿ ಯಾವ ಪ್ರಕಾರಗಳು ಹೆಚ್ಚು ಬೇಡಿಕೆಯಲ್ಲಿವೆ ಎಂಬುದು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಸಾಂಪ್ರದಾಯಿಕ ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಬಹು-ಮಾದರಿ DBMS ಗಳು, ಪ್ರಾಥಮಿಕವಾಗಿ ಸಂಬಂಧಿತ, ಹೆಚ್ಚಿನ ಬೇಡಿಕೆಯಲ್ಲಿರುತ್ತವೆ ಎಂದು ತೋರುತ್ತದೆ; ಬಹು-ಮಾದರಿ DBMS ಗಳ ಜನಪ್ರಿಯತೆ, ವಿವಿಧ ಸಾಂಪ್ರದಾಯಿಕವಾದವುಗಳ ಅನುಕೂಲಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಹೊಸ ಮಾದರಿಗಳನ್ನು ನೀಡುವುದು ಹೆಚ್ಚು ದೂರದ ಭವಿಷ್ಯದ ವಿಷಯವಾಗಿದೆ.

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

ನೀವು ಬಹು-ಮಾದರಿ DBMS ಬಳಸುತ್ತೀರಾ?

ನಾವು ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ, ನಾವು ಎಲ್ಲವನ್ನೂ ಒಂದು DBMS ನಲ್ಲಿ ಮತ್ತು ಒಂದು ಮಾದರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ
ನಾವು ಸಾಂಪ್ರದಾಯಿಕ DBMS ಗಳ ಬಹು-ಮಾದರಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಬಳಸುತ್ತೇವೆ
ನಾವು ಬಹುಭಾಷಾ ನಿರಂತರತೆಯನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತೇವೆ
ನಾವು ಹೊಸ ಬಹು-ಮಾದರಿ DBMS ಅನ್ನು ಬಳಸುತ್ತೇವೆ (ಅರಾಂಗೊ, ಓರಿಯಂಟ್, ಕಾಸ್ಮೊಸ್ಡಿಬಿ)

19 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 4 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com

ಬಹು-ಮಾದರಿ DBMS ಗಳು ಆಧುನಿಕ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳ ಆಧಾರವಾಗಿದೆಯೇ?