ಮೊದಲು ಸತ್ಯ, ಅಥವಾ ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸದ ಆಧಾರದ ಮೇಲೆ ಸಿಸ್ಟಮ್ ಅನ್ನು ಏಕೆ ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು

ಹಲೋ, ಹಬ್ರ್!

ನಾವು ವಿಷಯದ ಸಂಶೋಧನೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ ಜಾವಾ и ವಸಂತ, ಡೇಟಾಬೇಸ್ ಮಟ್ಟದಲ್ಲಿ ಸೇರಿದಂತೆ. ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ ಅದು ಡೇಟಾಬೇಸ್ ರಚನೆಯಾಗಿದೆ ಮತ್ತು ಜಾವಾ ಕೋಡ್ ಅಲ್ಲ, ಅದು ನಿರ್ಣಾಯಕ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿರಬೇಕು, ಇದನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ನಿಯಮಕ್ಕೆ ಯಾವ ವಿನಾಯಿತಿಗಳಿವೆ ಎಂಬುದರ ಕುರಿತು ಓದಲು ಇಂದು ನಾವು ನಿಮ್ಮನ್ನು ಆಹ್ವಾನಿಸುತ್ತೇವೆ.

ಈ ತಡವಾದ ಲೇಖನದಲ್ಲಿ, ಬಹುತೇಕ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿನ ಡೇಟಾ ಮಾದರಿಯನ್ನು "ಜಾವಾದ ಸಾಮರ್ಥ್ಯಗಳಿಂದ" (ಅಥವಾ ನೀವು ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಭಾಷೆಯಿಂದ" ಬದಲಿಗೆ "ಡೇಟಾಬೇಸ್‌ನಿಂದ" ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು ಎಂದು ನಾನು ಏಕೆ ನಂಬುತ್ತೇನೆ ಎಂದು ನಾನು ವಿವರಿಸುತ್ತೇನೆ. ಜೊತೆ ಕೆಲಸ ಮಾಡುವುದು). ಎರಡನೆಯ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ, ನಿಮ್ಮ ಯೋಜನೆಯು ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ ನೀವು ನೋವು ಮತ್ತು ಸಂಕಟದ ದೀರ್ಘ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಸುತ್ತೀರಿ.

ಲೇಖನವನ್ನು ಆಧರಿಸಿ ಬರೆಯಲಾಗಿದೆ ಒಂದು ಪ್ರಶ್ನೆ, ಸ್ಟಾಕ್ ಓವರ್‌ಫ್ಲೋನಲ್ಲಿ ನೀಡಲಾಗಿದೆ.

ವಿಭಾಗಗಳಲ್ಲಿ ರೆಡ್ಡಿಟ್ ಕುರಿತು ಆಸಕ್ತಿದಾಯಕ ಚರ್ಚೆಗಳು /ಆರ್/ಜಾವಾ и /ಆರ್/ಪ್ರೋಗ್ರಾಮಿಂಗ್.

ಕೋಡ್ ಉತ್ಪಾದನೆ

JOOQ ನೊಂದಿಗೆ ಪರಿಚಯವಾದ ನಂತರ, jOOQ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಮೂಲ ಕೋಡ್ ಉತ್ಪಾದನೆಯ ಮೇಲೆ ಗಂಭೀರವಾಗಿ ಅವಲಂಬಿತವಾಗಿದೆ ಎಂಬ ಅಂಶದಿಂದ ಆಕ್ರೋಶಗೊಂಡ ಬಳಕೆದಾರರಲ್ಲಿ ಇಂತಹ ಸಣ್ಣ ಭಾಗವಿದೆ ಎಂದು ನನಗೆ ಎಷ್ಟು ಆಶ್ಚರ್ಯವಾಯಿತು. ನೀವು ಸರಿಹೊಂದುವಂತೆ jOOQ ಅನ್ನು ಬಳಸುವುದನ್ನು ಯಾರೂ ತಡೆಯುವುದಿಲ್ಲ ಅಥವಾ ಕೋಡ್ ಉತ್ಪಾದನೆಯನ್ನು ಬಳಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ. ಆದರೆ ಡೀಫಾಲ್ಟ್ (ಕೈಪಿಡಿಯಲ್ಲಿ ವಿವರಿಸಿದಂತೆ) jOOQ ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ವಿಧಾನವೆಂದರೆ ನೀವು (ಲೆಗಸಿ) ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ, jOOQ ಕೋಡ್ ಜನರೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅದನ್ನು ರಿವರ್ಸ್ ಇಂಜಿನಿಯರ್ ಮಾಡಿ ಆ ಮೂಲಕ ನಿಮ್ಮ ಕೋಷ್ಟಕಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವ ತರಗತಿಗಳ ಗುಂಪನ್ನು ಪಡೆದುಕೊಳ್ಳಿ ಮತ್ತು ನಂತರ ಟೈಪ್ ಬರೆಯಿರಿ -ಈ ಕೋಷ್ಟಕಗಳಿಗೆ ಸುರಕ್ಷಿತ ಪ್ರಶ್ನೆಗಳು:

	for (Record2<String, String> record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на 
//   основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT 
 
       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ сгенерированные имена
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

ಕೋಡ್ ಅನ್ನು ಅಸೆಂಬ್ಲಿಯ ಹೊರಗೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ಅಥವಾ ಪ್ರತಿ ಅಸೆಂಬ್ಲಿಯಲ್ಲಿ ಹಸ್ತಚಾಲಿತವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಅಂತಹ ಪುನರುತ್ಪಾದನೆಯು ತಕ್ಷಣವೇ ಅನುಸರಿಸಬಹುದು ಫ್ಲೈವೇ ಡೇಟಾಬೇಸ್ ವಲಸೆ, ಇದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಅಥವಾ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಬಹುದು.

ಮೂಲ ಕೋಡ್ ಉತ್ಪಾದನೆ

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

ಅಂತಹ ಅನೇಕ ಕೋಡ್ ಜನರೇಟರ್ಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, XJC XSD ಅಥವಾ WSDL ಫೈಲ್‌ಗಳನ್ನು ಆಧರಿಸಿ ಜಾವಾ ಕೋಡ್ ಅನ್ನು ರಚಿಸಬಹುದು. ತತ್ವವು ಯಾವಾಗಲೂ ಒಂದೇ ಆಗಿರುತ್ತದೆ:

• ಕೆಲವು ಸತ್ಯವಿದೆ (ಆಂತರಿಕ ಅಥವಾ ಬಾಹ್ಯ) - ಉದಾಹರಣೆಗೆ, ನಿರ್ದಿಷ್ಟತೆ, ಡೇಟಾ ಮಾದರಿ, ಇತ್ಯಾದಿ.
• ನಮ್ಮ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ ಈ ಸತ್ಯದ ಸ್ಥಳೀಯ ಪ್ರಾತಿನಿಧ್ಯದ ಅಗತ್ಯವಿದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪುನರಾವರ್ತನೆಯನ್ನು ತಪ್ಪಿಸಲು ಅಂತಹ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ರಚಿಸಲು ಯಾವಾಗಲೂ ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ.

ಪ್ರಕಾರ ಪೂರೈಕೆದಾರರು ಮತ್ತು ಟಿಪ್ಪಣಿ ಪ್ರಕ್ರಿಯೆ

ಗಮನಿಸಿ: jOOQ ಗಾಗಿ ಕೋಡ್ ಅನ್ನು ರಚಿಸುವ ಮತ್ತೊಂದು, ಹೆಚ್ಚು ಆಧುನಿಕ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾದ ವಿಧಾನವು ಪ್ರಕಾರ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸುತ್ತಿದೆ, ಅವುಗಳನ್ನು F# ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕೋಡ್ ಅನ್ನು ಕಂಪೈಲರ್ ಮೂಲಕ ರಚಿಸಲಾಗುತ್ತದೆ, ವಾಸ್ತವವಾಗಿ ಸಂಕಲನ ಹಂತದಲ್ಲಿ. ತಾತ್ವಿಕವಾಗಿ, ಅಂತಹ ಕೋಡ್ ಮೂಲ ರೂಪದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಜಾವಾ ಇದೇ ರೀತಿಯದ್ದಾಗಿದೆ, ಆದರೂ ಸೊಗಸಾದವಲ್ಲದ, ಉಪಕರಣಗಳು - ಟಿಪ್ಪಣಿ ಸಂಸ್ಕಾರಕಗಳು, ಉದಾಹರಣೆಗೆ, Lombok.

ಒಂದರ್ಥದಲ್ಲಿ, ಮೊದಲ ಪ್ರಕರಣದಂತೆಯೇ ಇಲ್ಲಿಯೂ ಸಂಭವಿಸುತ್ತದೆ, ಹೊರತುಪಡಿಸಿ:

• ನೀವು ರಚಿಸಲಾದ ಕೋಡ್ ಅನ್ನು ನೋಡುತ್ತಿಲ್ಲ (ಬಹುಶಃ ಈ ಪರಿಸ್ಥಿತಿಯು ಯಾರಿಗಾದರೂ ಕಡಿಮೆ ಹಿಮ್ಮೆಟ್ಟಿಸುವಂತಿದೆಯೇ?)
• ಪ್ರಕಾರಗಳನ್ನು ಒದಗಿಸಬಹುದೆಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು, ಅಂದರೆ, "ನಿಜ" ಯಾವಾಗಲೂ ಲಭ್ಯವಿರಬೇಕು. "ಸತ್ಯ" ಎಂದು ಟಿಪ್ಪಣಿ ಮಾಡುವ ಲೊಂಬೋಕ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಸುಲಭವಾಗಿದೆ. ನಿರಂತರವಾಗಿ ಲಭ್ಯವಿರುವ ಲೈವ್ ಸಂಪರ್ಕವನ್ನು ಅವಲಂಬಿಸಿರುವ ಡೇಟಾಬೇಸ್ ಮಾದರಿಗಳೊಂದಿಗೆ ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ.

ಕೋಡ್ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸಮಸ್ಯೆ ಏನು?

ಕೋಡ್ ಉತ್ಪಾದನೆಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಅಥವಾ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೇಗೆ ಚಲಾಯಿಸುವುದು ಎಂಬ ಟ್ರಿಕಿ ಪ್ರಶ್ನೆಯ ಜೊತೆಗೆ, ಕೋಡ್ ಉತ್ಪಾದನೆಯ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಂಬುವ ಜನರಿದ್ದಾರೆ ಎಂದು ನಾವು ನಮೂದಿಸಬೇಕಾಗಿದೆ. ನಾನು ಹೆಚ್ಚಾಗಿ ಕಂಡ ಈ ದೃಷ್ಟಿಕೋನದ ಸಮರ್ಥನೆ ಏನೆಂದರೆ, ನಿರ್ಮಾಣ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು ಕಷ್ಟ. ಹೌದು, ಇದು ನಿಜವಾಗಿಯೂ ಕಷ್ಟ. ಹೆಚ್ಚುವರಿ ಮೂಲಸೌಕರ್ಯ ವೆಚ್ಚಗಳು ಉಂಟಾಗುತ್ತವೆ. ನೀವು ಕೇವಲ ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದರೆ (ಅದು jOOQ, ಅಥವಾ JAXB, ಅಥವಾ ಹೈಬರ್ನೇಟ್, ಇತ್ಯಾದಿ), ಉತ್ಪಾದನಾ ಪರಿಸರವನ್ನು ಹೊಂದಿಸಲು ನೀವು API ಅನ್ನು ಕಲಿಯಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಆದ್ದರಿಂದ ನೀವು ಅದರಿಂದ ಮೌಲ್ಯವನ್ನು ಹೊರತೆಗೆಯಬಹುದು. .

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

ಇದನ್ನೆಲ್ಲಾ ಮಾಡಲು ಸಮಯವಿಲ್ಲ ಎಂದು ಹಲವರು ಹೇಳುತ್ತಾರೆ. ಅವರು ತಮ್ಮ ಸೂಪರ್ ಉತ್ಪನ್ನಕ್ಕಾಗಿ ಗಡುವನ್ನು ಮೀರುತ್ತಿದ್ದಾರೆ. ಒಂದು ದಿನ ನಾವು ಅಸೆಂಬ್ಲಿ ಕನ್ವೇಯರ್‌ಗಳನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಮಾಡುತ್ತೇವೆ, ನಮಗೆ ಸಮಯವಿದೆ. ನಾನು ಅವರಿಗೆ ಉತ್ತರಿಸುತ್ತೇನೆ:

ಮೂಲ, ಅಲನ್ ಒ'ರೂರ್ಕ್, ಆಡಿಯನ್ಸ್ ಸ್ಟಾಕ್

ಆದರೆ ಹೈಬರ್ನೇಟ್/ಜೆಪಿಎಯಲ್ಲಿ ಜಾವಾ ಕೋಡ್ ಬರೆಯುವುದು ತುಂಬಾ ಸುಲಭ.

ನಿಜವಾಗಿಯೂ. ಹೈಬರ್ನೇಟ್ ಮತ್ತು ಅದರ ಬಳಕೆದಾರರಿಗೆ, ಇದು ಆಶೀರ್ವಾದ ಮತ್ತು ಶಾಪವಾಗಿದೆ. ಹೈಬರ್ನೇಟ್‌ನಲ್ಲಿ ನೀವು ಈ ರೀತಿಯ ಎರಡು ಘಟಕಗಳನ್ನು ಸರಳವಾಗಿ ಬರೆಯಬಹುದು:

	@Entity
class Book {
  @Id
  int id;
  String title;
}

ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲವೂ ಸಿದ್ಧವಾಗಿದೆ. ನಿಮ್ಮ SQL "ಉಪಭಾಷೆ" ಯ DDL ನಲ್ಲಿ ಈ ಘಟಕವನ್ನು ಹೇಗೆ ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಸಂಕೀರ್ಣ "ವಿವರಗಳನ್ನು" ರಚಿಸುವುದು ಈಗ ಹೈಬರ್ನೇಟ್‌ಗೆ ಬಿಟ್ಟದ್ದು:

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

... ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಪ್ರಾರಂಭಿಸಿ. ತ್ವರಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ಪ್ರಯತ್ನಿಸಲು ನಿಜವಾಗಿಯೂ ಉತ್ತಮ ಅವಕಾಶ.

ಆದರೂ ದಯವಿಟ್ಟು ನನಗೆ ಅವಕಾಶ ಕೊಡಿ. ನಾನು ಸುಳ್ಳು ಹೇಳುತ್ತಿದ್ದೆ.

• ಹೈಬರ್ನೇಟ್ ವಾಸ್ತವವಾಗಿ ಈ ಹೆಸರಿಸಲಾದ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯ ವ್ಯಾಖ್ಯಾನವನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆಯೇ?
• ಹೈಬರ್ನೇಟ್ TITLE ನಲ್ಲಿ ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸುತ್ತದೆಯೇ? - ನಮಗೆ ಇದು ಬೇಕಾಗುತ್ತದೆ ಎಂದು ನನಗೆ ಖಚಿತವಾಗಿ ತಿಳಿದಿದೆ.
• ಹೈಬರ್ನೇಟ್ ಈ ಕೀಲಿಯನ್ನು ಐಡೆಂಟಿಟಿ ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ನಲ್ಲಿ ನಿಖರವಾಗಿ ಗುರುತಿಸುತ್ತದೆಯೇ?

ಬಹುಷಃ ಇಲ್ಲ. ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ನೀವು ಮೊದಲಿನಿಂದ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದರೆ, ಹಳೆಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸರಳವಾಗಿ ತ್ಯಜಿಸಲು ಮತ್ತು ಅಗತ್ಯ ಟಿಪ್ಪಣಿಗಳನ್ನು ಸೇರಿಸಿದ ತಕ್ಷಣ ಹೊಸದನ್ನು ರಚಿಸಲು ಯಾವಾಗಲೂ ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ. ಹೀಗಾಗಿ, ಪುಸ್ತಕ ಘಟಕವು ಅಂತಿಮವಾಗಿ ರೂಪವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

ಕೂಲ್. ಪುನರುತ್ಪಾದಿಸು. ಮತ್ತೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಪ್ರಾರಂಭದಲ್ಲಿ ತುಂಬಾ ಸುಲಭವಾಗುತ್ತದೆ.

ಆದರೆ ನೀವು ಅದನ್ನು ನಂತರ ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ

ಶೀಘ್ರದಲ್ಲೇ ಅಥವಾ ನಂತರ ನೀವು ಉತ್ಪಾದನೆಗೆ ಹೋಗಬೇಕಾಗುತ್ತದೆ. ಆಗ ಈ ಮಾದರಿಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಏಕೆಂದರೆ:

ಉತ್ಪಾದನೆಯಲ್ಲಿ, ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ಹಳೆಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತ್ಯಜಿಸಲು ಮತ್ತು ಮೊದಲಿನಿಂದ ಪ್ರಾರಂಭಿಸಲು ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಪರಂಪರೆಯಾಗುತ್ತದೆ.

ಇಂದಿನಿಂದ ಮತ್ತು ಎಂದೆಂದಿಗೂ ನೀವು ಬರೆಯಬೇಕು DDL ವಲಸೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಉದಾಹರಣೆಗೆ, ಫ್ಲೈವೇ ಬಳಸಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮ್ಮ ಘಟಕಗಳಿಗೆ ಏನಾಗುತ್ತದೆ? ನೀವು ಅವುಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು (ಮತ್ತು ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆಯನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಬಹುದು), ಅಥವಾ ಅವುಗಳನ್ನು ನಿಮಗಾಗಿ ಪುನರುತ್ಪಾದಿಸಲು ಹೈಬರ್ನೇಟ್‌ಗೆ ಹೇಳಬಹುದು (ನಿಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸಲು ಈ ರೀತಿಯಲ್ಲಿ ಉತ್ಪತ್ತಿಯಾಗುವ ಸಾಧ್ಯತೆ ಎಷ್ಟು?) ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ, ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.

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

ಬದಲಾಗಿ, ಮೊದಲಿನಿಂದಲೂ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿ ಕೆಲಸಗಳನ್ನು ಮಾಡಬಹುದಿತ್ತು. ಉದಾಹರಣೆಗೆ, ಬೈಸಿಕಲ್ನಲ್ಲಿ ಸುತ್ತಿನ ಚಕ್ರಗಳನ್ನು ಹಾಕಿ.

ಮೊದಲು ಡೇಟಾಬೇಸ್

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

ಇದಲ್ಲದೆ, ಅಷ್ಟೆ ಅಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಒರಾಕಲ್ ಬಳಸಿ, ನೀವು ಬಹುಶಃ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಬಯಸುತ್ತೀರಿ:

• ನಿಮ್ಮ ಟೇಬಲ್ ಯಾವ ಟೇಬಲ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿದೆ?
• ಅದರ PCTFREE ಮೌಲ್ಯ ಏನು?
• ನಿಮ್ಮ ಅನುಕ್ರಮದಲ್ಲಿ ಸಂಗ್ರಹ ಗಾತ್ರ ಎಷ್ಟು (ಐಡಿ ಹಿಂದೆ)

ಸಣ್ಣ ಸಿಸ್ಟಂಗಳಲ್ಲಿ ಇದು ಮುಖ್ಯವಲ್ಲದಿರಬಹುದು, ಆದರೆ ನೀವು ದೊಡ್ಡ ಡೇಟಾ ಕ್ಷೇತ್ರಕ್ಕೆ ತೆರಳುವವರೆಗೆ ನೀವು ಕಾಯಬೇಕಾಗಿಲ್ಲ - ಮೇಲೆ ತಿಳಿಸಿದಂತಹ ಮಾರಾಟಗಾರ-ಒದಗಿಸಿದ ಶೇಖರಣಾ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳಿಂದ ನೀವು ಲಾಭವನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ನಾನು ನೋಡಿದ ಯಾವುದೇ ORM ಗಳು (jOOQ ಸೇರಿದಂತೆ) ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನೀವು ಬಳಸಲು ಬಯಸುವ DDL ಆಯ್ಕೆಗಳ ಸಂಪೂರ್ಣ ಸೆಟ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ORMಗಳು ನಿಮಗೆ DDL ಬರೆಯಲು ಸಹಾಯ ಮಾಡುವ ಕೆಲವು ಸಾಧನಗಳನ್ನು ನೀಡುತ್ತವೆ.

ಆದರೆ ದಿನದ ಕೊನೆಯಲ್ಲಿ, ಡಿಡಿಎಲ್‌ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಕೈಯಿಂದ ಬರೆಯಲಾಗುತ್ತದೆ. ಯಾವುದೇ ರಚಿಸಲಾದ DDL ಅದರ ಅಂದಾಜು ಮಾತ್ರ.

ಕ್ಲೈಂಟ್ ಮಾದರಿಯ ಬಗ್ಗೆ ಏನು?

ಮೇಲೆ ಹೇಳಿದಂತೆ, ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾ, ಕ್ಲೈಂಟ್ ವೀಕ್ಷಣೆಯ ನಕಲು ನಿಮಗೆ ಅಗತ್ಯವಿರುತ್ತದೆ. ಉಲ್ಲೇಖಿಸಬೇಕಾಗಿಲ್ಲ, ಈ ಕ್ಲೈಂಟ್ ವೀಕ್ಷಣೆಯು ನಿಜವಾದ ಮಾದರಿಯೊಂದಿಗೆ ಸಿಂಕ್ ಆಗಿರಬೇಕು. ಇದನ್ನು ಸಾಧಿಸಲು ಉತ್ತಮ ಮಾರ್ಗ ಯಾವುದು? ಕೋಡ್ ಜನರೇಟರ್ ಅನ್ನು ಬಳಸುವುದು.

ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳು ತಮ್ಮ ಮೆಟಾ ಮಾಹಿತಿಯನ್ನು SQL ಮೂಲಕ ಒದಗಿಸುತ್ತವೆ. ವಿವಿಧ SQL ಉಪಭಾಷೆಗಳಲ್ಲಿ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
 
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
 
-- Oracle
SELECT owner, table_name
FROM all_tables
 
-- SQLite
SELECT name
FROM sqlite_master
 
-- Teradata
SELECT databasename, tablename
FROM dbc.tables

ಈ ಪ್ರಶ್ನೆಗಳು (ಅಥವಾ ಇದೇ ರೀತಿಯವುಗಳು, ನೀವು ವೀಕ್ಷಣೆಗಳು, ವಸ್ತುರೂಪದ ವೀಕ್ಷಣೆಗಳು, ಟೇಬಲ್-ಮೌಲ್ಯದ ಕಾರ್ಯಗಳನ್ನು ಸಹ ಪರಿಗಣಿಸಬೇಕೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ) ಸಹ ಕರೆ ಮಾಡುವ ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ DatabaseMetaData.getTables() JDBC ಯಿಂದ, ಅಥವಾ jOOQ ಮೆಟಾ-ಮಾಡ್ಯೂಲ್ ಬಳಸಿ.

ಅಂತಹ ಪ್ರಶ್ನೆಗಳ ಫಲಿತಾಂಶಗಳಿಂದ, ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಮಾದರಿಯ ಯಾವುದೇ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ರಚಿಸುವುದು ತುಲನಾತ್ಮಕವಾಗಿ ಸುಲಭವಾಗಿದೆ, ನೀವು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಯಾವ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸುತ್ತೀರಿ.

• ನೀವು JDBC ಅಥವಾ ಸ್ಪ್ರಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಸ್ಟ್ರಿಂಗ್ ಸ್ಥಿರಾಂಕಗಳ ಗುಂಪನ್ನು ರಚಿಸಬಹುದು
• ನೀವು JPA ಅನ್ನು ಬಳಸಿದರೆ, ನೀವು ಘಟಕಗಳನ್ನು ಸ್ವತಃ ರಚಿಸಬಹುದು
• ನೀವು jOOQ ಅನ್ನು ಬಳಸಿದರೆ, ನೀವು jOOQ ಮೆಟಾ-ಮಾಡೆಲ್ ಅನ್ನು ರಚಿಸಬಹುದು

ನಿಮ್ಮ ಕ್ಲೈಂಟ್ API (ಉದಾ jOOQ ಅಥವಾ JPA) ಮೂಲಕ ಎಷ್ಟು ಕಾರ್ಯವನ್ನು ನೀಡಲಾಗುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ, ರಚಿತವಾದ ಮೆಟಾ ಮಾದರಿಯು ನಿಜವಾಗಿಯೂ ಶ್ರೀಮಂತ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸೂಚ್ಯ ಸೇರ್ಪಡೆಗಳ ಸಾಧ್ಯತೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, jOOQ 3.11 ರಲ್ಲಿ ಪರಿಚಯಿಸಲಾಗಿದೆ, ಇದು ನಿಮ್ಮ ಕೋಷ್ಟಕಗಳ ನಡುವೆ ಇರುವ ವಿದೇಶಿ ಪ್ರಮುಖ ಸಂಬಂಧಗಳ ಕುರಿತು ರಚಿತವಾದ ಮೆಟಾ ಮಾಹಿತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಈಗ ಯಾವುದೇ ಡೇಟಾಬೇಸ್ ಹೆಚ್ಚಳವು ಕ್ಲೈಂಟ್ ಕೋಡ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ:

ALTER TABLE book RENAME COLUMN title TO book_title;

ನೀವು ನಿಜವಾಗಿಯೂ ಈ ಕೆಲಸವನ್ನು ಎರಡು ಬಾರಿ ಮಾಡಲು ಬಯಸುವಿರಾ? ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ. ಸರಳವಾಗಿ DDL ಅನ್ನು ಒಪ್ಪಿಸಿ, ಅದನ್ನು ನಿಮ್ಮ ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್ ಮೂಲಕ ರನ್ ಮಾಡಿ ಮತ್ತು ನವೀಕರಿಸಿದ ಘಟಕವನ್ನು ಪಡೆಯಿರಿ:

@Entity
@Table(name = "book", indexes = {
 
  // Вы об этом задумывались?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

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

ಒಂದೇ ಸತ್ಯ

ನೀವು ಯಾವ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸುತ್ತೀರಿ ಎಂಬುದರ ಹೊರತಾಗಿಯೂ, ಕೆಲವು ಉಪವ್ಯವಸ್ಥೆಗೆ ಸತ್ಯದ ಏಕೈಕ ಮೂಲವಾಗಿರುವ ಒಂದು ಮಾದರಿ ಯಾವಾಗಲೂ ಇರುತ್ತದೆ - ಅಥವಾ, ಕನಿಷ್ಠ, ನಾವು ಇದಕ್ಕಾಗಿ ಶ್ರಮಿಸಬೇಕು ಮತ್ತು ಅಂತಹ ಉದ್ಯಮ ಗೊಂದಲವನ್ನು ತಪ್ಪಿಸಬೇಕು, ಅಲ್ಲಿ "ಸತ್ಯ" ಎಲ್ಲೆಡೆ ಮತ್ತು ಎಲ್ಲಿಯೂ ಒಂದೇ ಬಾರಿಗೆ ಇರುವುದಿಲ್ಲ. . ಎಲ್ಲವೂ ಹೆಚ್ಚು ಸರಳವಾಗಬಹುದು. ನೀವು XML ಫೈಲ್‌ಗಳನ್ನು ಬೇರೆ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ವಿನಿಮಯ ಮಾಡುತ್ತಿದ್ದರೆ, ಕೇವಲ XSD ಬಳಸಿ. XML ರೂಪದಲ್ಲಿ jOOQ ನಿಂದ INFORMATION_SCHEMA ಮೆಟಾ-ಮಾಡೆಲ್ ಅನ್ನು ನೋಡಿ:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD ಚೆನ್ನಾಗಿ ಅರ್ಥವಾಗುತ್ತದೆ
• XSD XML ವಿಷಯವನ್ನು ಚೆನ್ನಾಗಿ ಟೋಕನೈಸ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಕ್ಲೈಂಟ್ ಭಾಷೆಗಳಲ್ಲಿ ಮೌಲ್ಯೀಕರಣವನ್ನು ಅನುಮತಿಸುತ್ತದೆ
• XSD ಉತ್ತಮ ಆವೃತ್ತಿಯಾಗಿದೆ ಮತ್ತು ಮುಂದುವರಿದ ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಹೊಂದಿದೆ
• XJC ಬಳಸಿಕೊಂಡು XSD ಅನ್ನು ಜಾವಾ ಕೋಡ್‌ಗೆ ಅನುವಾದಿಸಬಹುದು

ಕೊನೆಯ ಅಂಶವು ಮುಖ್ಯವಾಗಿದೆ. XML ಸಂದೇಶಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬಾಹ್ಯ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವಾಗ, ನಮ್ಮ ಸಂದೇಶಗಳು ಮಾನ್ಯವಾಗಿವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ. JAXB, XJC ಮತ್ತು XSD ಬಳಸಿ ಇದನ್ನು ಸಾಧಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ನಾವು ನಮ್ಮ ಸಂದೇಶಗಳನ್ನು ಜಾವಾ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿ ಮಾಡುವ "ಜಾವಾ ಮೊದಲ" ವಿನ್ಯಾಸದ ವಿಧಾನದೊಂದಿಗೆ, ಅವುಗಳನ್ನು ಹೇಗಾದರೂ XML ಗೆ ಸುಸಂಬದ್ಧವಾಗಿ ಮ್ಯಾಪ್ ಮಾಡಬಹುದು ಮತ್ತು ಬಳಕೆಗಾಗಿ ಮತ್ತೊಂದು ಸಿಸ್ಟಮ್‌ಗೆ ಕಳುಹಿಸಬಹುದು ಎಂದು ಯೋಚಿಸುವುದು ಸಂಪೂರ್ಣ ಹುಚ್ಚುತನವಾಗಿದೆ. ಈ ರೀತಿಯಲ್ಲಿ ರಚಿಸಲಾದ XML ಅತ್ಯಂತ ಕಳಪೆ ಗುಣಮಟ್ಟದ, ದಾಖಲೆರಹಿತ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಅಂತಹ ಇಂಟರ್‌ಫೇಸ್‌ಗಾಗಿ ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದ (ಎಸ್‌ಎಲ್‌ಎ) ಇದ್ದರೆ, ನಾವು ಅದನ್ನು ತಕ್ಷಣವೇ ತಿರುಗಿಸುತ್ತೇವೆ.

ಪ್ರಾಮಾಣಿಕವಾಗಿ, JSON API ಗಳಲ್ಲಿ ಇದು ಸಾರ್ವಕಾಲಿಕ ಸಂಭವಿಸುತ್ತದೆ, ಆದರೆ ಇದು ಇನ್ನೊಂದು ಕಥೆ, ನಾನು ಮುಂದಿನ ಬಾರಿ ಜಗಳವಾಡುತ್ತೇನೆ...

ಡೇಟಾಬೇಸ್‌ಗಳು: ಅವು ಒಂದೇ ಆಗಿರುತ್ತವೆ

ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಅವೆಲ್ಲವೂ ಮೂಲತಃ ಹೋಲುತ್ತವೆ ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳುತ್ತೀರಿ. ಮೂಲವು ಅದರ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸಬೇಕು. ಸ್ಕೀಮಾಗೆ ಮಾಡಿದ ಯಾವುದೇ ಮಾರ್ಪಾಡುಗಳನ್ನು ನೇರವಾಗಿ DDL ನಲ್ಲಿ ಅಳವಡಿಸಬೇಕು ಇದರಿಂದ ಸತ್ಯದ ಏಕೈಕ ಮೂಲವನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ.

ಮೂಲ ನವೀಕರಣ ಸಂಭವಿಸಿದಾಗ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಮಾದರಿಯ ಪ್ರತಿಗಳನ್ನು ಸಹ ನವೀಕರಿಸಬೇಕು. ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು jOOQ ಮತ್ತು ಹೈಬರ್ನೇಟ್ ಅಥವಾ JDBC (ಅಥವಾ ಎರಡೂ) ಬಳಸಿಕೊಂಡು ಜಾವಾದಲ್ಲಿ ಬರೆಯಬಹುದು. ಇತರ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪರ್ಲ್‌ನಲ್ಲಿ ಬರೆಯಬಹುದು (ನಾವು ಅವರಿಗೆ ಶುಭ ಹಾರೈಸುತ್ತೇವೆ), ಇತರರನ್ನು C# ನಲ್ಲಿ ಬರೆಯಬಹುದು. ಪರವಾಗಿಲ್ಲ. ಮುಖ್ಯ ಮಾದರಿ ಡೇಟಾಬೇಸ್ನಲ್ಲಿದೆ. ORM ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ರಚಿಸಲಾದ ಮಾದರಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕಳಪೆ ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿವೆ, ಕಳಪೆಯಾಗಿ ದಾಖಲಿಸಲಾಗಿದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಕಷ್ಟ.

ಆದ್ದರಿಂದ ತಪ್ಪುಗಳನ್ನು ಮಾಡಬೇಡಿ. ಮೊದಲಿನಿಂದಲೂ ತಪ್ಪುಗಳನ್ನು ಮಾಡಬೇಡಿ. ಡೇಟಾಬೇಸ್‌ನಿಂದ ಕೆಲಸ ಮಾಡಿ. ಸ್ವಯಂಚಾಲಿತ ಮಾಡಬಹುದಾದ ನಿಯೋಜನೆ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಮಾದರಿಯನ್ನು ಸುಲಭವಾಗಿ ನಕಲಿಸಲು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳ ಮೇಲೆ ಡಂಪ್ ಮಾಡಲು ಕೋಡ್ ಜನರೇಟರ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ. ಮತ್ತು ಕೋಡ್ ಜನರೇಟರ್‌ಗಳ ಬಗ್ಗೆ ಚಿಂತಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಅವರು ಒಳ್ಳೆಯವರು. ಅವರೊಂದಿಗೆ ನೀವು ಹೆಚ್ಚು ಉತ್ಪಾದಕರಾಗುತ್ತೀರಿ. ನೀವು ಮೊದಲಿನಿಂದಲೂ ಅವುಗಳನ್ನು ಹೊಂದಿಸಲು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಕಳೆಯಬೇಕಾಗಿದೆ - ತದನಂತರ ಹೆಚ್ಚಿದ ಉತ್ಪಾದಕತೆಯ ವರ್ಷಗಳು ನಿಮಗಾಗಿ ಕಾಯುತ್ತಿವೆ, ಅದು ನಿಮ್ಮ ಯೋಜನೆಯ ಇತಿಹಾಸವನ್ನು ರೂಪಿಸುತ್ತದೆ.

ನನಗೆ ಇನ್ನೂ ಧನ್ಯವಾದ ಹೇಳಬೇಡ, ನಂತರ.

ವಿವರಣೆ

ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ: ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಮಾದರಿಗೆ ಸರಿಹೊಂದುವಂತೆ ನೀವು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಅನ್ನು (ಅಂದರೆ, ಡೊಮೇನ್, ವ್ಯವಹಾರ ತರ್ಕ, ಇತ್ಯಾದಿ. ಇತ್ಯಾದಿ) ಬಗ್ಗಿಸಬೇಕೆಂದು ಈ ಲೇಖನವು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿಪಾದಿಸುವುದಿಲ್ಲ. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಹೇಳುವುದೇನೆಂದರೆ, ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಕ್ಲೈಂಟ್ ಕೋಡ್ ಡೇಟಾಬೇಸ್ ಮಾದರಿಯ ಆಧಾರದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ಆದ್ದರಿಂದ ಅದು ಸ್ವತಃ ಡೇಟಾಬೇಸ್ ಮಾದರಿಯನ್ನು "ಪ್ರಥಮ-ದರ್ಜೆ" ಸ್ಥಿತಿಯಲ್ಲಿ ಪುನರುತ್ಪಾದಿಸುವುದಿಲ್ಲ. ಈ ತರ್ಕವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿರುವ ಡೇಟಾ ಪ್ರವೇಶ ಲೇಯರ್‌ನಲ್ಲಿದೆ.

ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಇನ್ನೂ ಸಂರಕ್ಷಿಸಲ್ಪಟ್ಟಿರುವ ಎರಡು-ಹಂತದ ವಾಸ್ತುಶಿಲ್ಪಗಳಲ್ಲಿ, ಅಂತಹ ಒಂದು ಸಿಸ್ಟಮ್ ಮಾದರಿಯು ಒಂದೇ ಆಗಿರಬಹುದು. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಡೇಟಾ ಪ್ರವೇಶ ಪದರವು ಡೇಟಾಬೇಸ್ ಮಾದರಿಯನ್ನು ಆವರಿಸುವ "ಉಪವ್ಯವಸ್ಥೆ" ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ.

ವಿನಾಯಿತಿಗಳು

ಪ್ರತಿ ನಿಯಮಕ್ಕೂ ವಿನಾಯಿತಿಗಳಿವೆ, ಮತ್ತು ಡೇಟಾಬೇಸ್-ಮೊದಲ ಮತ್ತು ಮೂಲ-ಕೋಡ್ ರಚನೆಯ ವಿಧಾನವು ಕೆಲವೊಮ್ಮೆ ಸೂಕ್ತವಲ್ಲ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದ್ದೇನೆ. ಅಂತಹ ಕೆಲವು ವಿನಾಯಿತಿಗಳು ಇಲ್ಲಿವೆ (ಬಹುಶಃ ಇತರರು ಇವೆ):

• ಸ್ಕೀಮಾ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಕಂಡುಹಿಡಿಯಬೇಕಾದಾಗ. ಉದಾಹರಣೆಗೆ, ನೀವು ಯಾವುದೇ ರೇಖಾಚಿತ್ರವನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು ಬಳಕೆದಾರರಿಗೆ ಸಹಾಯ ಮಾಡುವ ಸಾಧನವನ್ನು ಒದಗಿಸುವವರಾಗಿದ್ದೀರಿ. ಉಫ್. ಇಲ್ಲಿ ಕೋಡ್ ಜನರೇಷನ್ ಇಲ್ಲ. ಆದರೆ ಇನ್ನೂ, ಡೇಟಾಬೇಸ್ ಮೊದಲು ಬರುತ್ತದೆ.
• ಕೆಲವು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಫ್ಲೈನಲ್ಲಿ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ರಚಿಸಬೇಕು. ಈ ಉದಾಹರಣೆಯು ಮಾದರಿಯ ಸ್ವಲ್ಪ ಕಾಲ್ಪನಿಕ ಆವೃತ್ತಿಯಂತೆ ತೋರುತ್ತದೆ ಘಟಕದ ಗುಣಲಕ್ಷಣ ಮೌಲ್ಯ, ಅಂದರೆ, ನೀವು ನಿಜವಾಗಿಯೂ ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಯೋಜನೆಯನ್ನು ಹೊಂದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, RDBMS ನಿಮಗೆ ಸರಿಹೊಂದುತ್ತದೆ ಎಂದು ನೀವು ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ.

ವಿನಾಯಿತಿಗಳು ಸ್ವಭಾವತಃ ಅಸಾಧಾರಣವಾಗಿವೆ. RDBMS ಬಳಕೆಯನ್ನು ಒಳಗೊಂಡಿರುವ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸ್ಕೀಮಾವನ್ನು ಮುಂಚಿತವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ, ಇದು RDBMS ನಲ್ಲಿ ನೆಲೆಸಿದೆ ಮತ್ತು "ಸತ್ಯ" ದ ಏಕೈಕ ಮೂಲವಾಗಿದೆ, ಮತ್ತು ಎಲ್ಲಾ ಗ್ರಾಹಕರು ಅದರಿಂದ ಪಡೆದ ಪ್ರತಿಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳಬೇಕು. ತಾತ್ತ್ವಿಕವಾಗಿ, ನೀವು ಕೋಡ್ ಜನರೇಟರ್ ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಮೂಲ: www.habr.com