"ಕೋಡ್ ಆಗಿ ಡೇಟಾಬೇಸ್" ಅನುಭವ

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

ಮತ್ತು ಈಗಿನಿಂದಲೇ ಪ್ರಾರಂಭಿಸೋಣ ORM. "SQL vs ORM" ಪ್ರಕಾರದ ಮೊದಲ ಯುದ್ಧಗಳು ಮತ್ತೆ ಗಮನಕ್ಕೆ ಬಂದವು ಪ್ರಿ-ಪೆಟ್ರಿನ್ ರುಸ್'.

ಆಬ್ಜೆಕ್ಟ್-ರಿಲೇಶನಲ್ ಮ್ಯಾಪಿಂಗ್

ORM ಬೆಂಬಲಿಗರು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ವೇಗ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಸುಲಭತೆ, DBMS ನಿಂದ ಸ್ವಾತಂತ್ರ್ಯ ಮತ್ತು ಕ್ಲೀನ್ ಕೋಡ್ ಅನ್ನು ಗೌರವಿಸುತ್ತಾರೆ. ನಮ್ಮಲ್ಲಿ ಅನೇಕರಿಗೆ, ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕೋಡ್ (ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್ ಸ್ವತಃ)

ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ ...

@Entity
@Table(name = "stock", catalog = "maindb", uniqueConstraints = {
        @UniqueConstraint(columnNames = "STOCK_NAME"),
        @UniqueConstraint(columnNames = "STOCK_CODE") })
public class Stock implements java.io.Serializable {

    @Id
    @GeneratedValue(strategy = IDENTITY)
    @Column(name = "STOCK_ID", unique = true, nullable = false)
    public Integer getStockId() {
        return this.stockId;
    }
  ...

ಮಾದರಿಯನ್ನು ಬುದ್ಧಿವಂತ ಟಿಪ್ಪಣಿಗಳೊಂದಿಗೆ ತೂಗುಹಾಕಲಾಗಿದೆ, ಮತ್ತು ಎಲ್ಲೋ ತೆರೆಮರೆಯಲ್ಲಿ ಧೀರ ORM ಕೆಲವು SQL ಕೋಡ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಅಂದಹಾಗೆ, ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಕಿಲೋಮೀಟರ್‌ಗಳ ಅಮೂರ್ತತೆಗಳೊಂದಿಗೆ ತಮ್ಮನ್ನು ಪ್ರತ್ಯೇಕಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ, ಇದು ಕೆಲವನ್ನು ಸೂಚಿಸುತ್ತದೆ "SQL ದ್ವೇಷ".

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

ನಾವು ಎರಡೂ ಪ್ರಪಂಚದ ಅತ್ಯುತ್ತಮವನ್ನು ಹೊಂದಿದ್ದರೆ ಏನು? ಜೀವನವನ್ನು ದೃಢೀಕರಿಸುವ ಹೆಸರಿನೊಂದಿಗೆ ಅದ್ಭುತ ಸಾಧನದಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ Yesql. ನನ್ನ ಉಚಿತ ಅನುವಾದದಲ್ಲಿ ನಾನು ಸಾಮಾನ್ಯ ಪರಿಕಲ್ಪನೆಯಿಂದ ಒಂದೆರಡು ಸಾಲುಗಳನ್ನು ನೀಡುತ್ತೇನೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ತಿಳಿದುಕೊಳ್ಳಬಹುದು. ಇಲ್ಲಿ.

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

ಹಾಗಾದರೆ ನಾನು ಏನು ಮಾಡಬೇಕು? SQL ಅನ್ನು ಸಾಮಾನ್ಯ SQL ಆಗಿ ಬಿಡೋಣ - ಪ್ರತಿ ವಿನಂತಿಗೆ ಒಂದು ಫೈಲ್:

-- name: users-by-country
select *
  from users
 where country_code = :country_code

... ತದನಂತರ ಈ ಫೈಲ್ ಅನ್ನು ಓದಿ, ಅದನ್ನು ಸಾಮಾನ್ಯ ಕ್ಲೋಜೂರ್ ಕಾರ್ಯವಾಗಿ ಪರಿವರ್ತಿಸಿ:

(defqueries "some/where/users_by_country.sql"
   {:connection db-spec})

;;; A function with the name `users-by-country` has been created.
;;; Let's use it:
(users-by-country {:country_code "GB"})
;=> ({:name "Kris" :country_code "GB" ...} ...)

"SQL ಸ್ವತಃ, ಕ್ಲೋಜುರ್ ಸ್ವತಃ" ತತ್ವವನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ, ನೀವು ಪಡೆಯುತ್ತೀರಿ:

• ವಾಕ್ಯರಚನೆಯ ಆಶ್ಚರ್ಯಗಳಿಲ್ಲ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ (ಯಾವುದೇ ರೀತಿಯಂತೆ) SQL ಮಾನದಂಡದೊಂದಿಗೆ 100% ಅನುವರ್ತನೆ ಹೊಂದಿಲ್ಲ - ಆದರೆ ಇದು Yesql ಗೆ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. SQL ಸಮಾನ ಸಿಂಟ್ಯಾಕ್ಸ್‌ನೊಂದಿಗೆ ಕಾರ್ಯಗಳಿಗಾಗಿ ನೀವು ಸಮಯವನ್ನು ಬೇಟೆಯಾಡಲು ಎಂದಿಗೂ ವ್ಯರ್ಥ ಮಾಡುವುದಿಲ್ಲ. ನೀವು ಎಂದಿಗೂ ಕಾರ್ಯಕ್ಕೆ ಹಿಂತಿರುಗಬೇಕಾಗಿಲ್ಲ (raw-sql "ಕೆಲವು('ಫಂಕಿ'::SYNTAX)")).
• ಅತ್ಯುತ್ತಮ ಸಂಪಾದಕ ಬೆಂಬಲ. ನಿಮ್ಮ ಸಂಪಾದಕರು ಈಗಾಗಲೇ ಅತ್ಯುತ್ತಮ SQL ಬೆಂಬಲವನ್ನು ಹೊಂದಿದ್ದಾರೆ. SQL ಅನ್ನು SQL ಆಗಿ ಉಳಿಸುವ ಮೂಲಕ ನೀವು ಅದನ್ನು ಸರಳವಾಗಿ ಬಳಸಬಹುದು.
• ತಂಡದ ಹೊಂದಾಣಿಕೆ. ನಿಮ್ಮ ಕ್ಲೋಜೂರ್ ಯೋಜನೆಯಲ್ಲಿ ನೀವು ಬಳಸುವ SQL ಅನ್ನು ನಿಮ್ಮ DBA ಗಳು ಓದಬಹುದು ಮತ್ತು ಬರೆಯಬಹುದು.
• ಸುಲಭವಾದ ಕಾರ್ಯಕ್ಷಮತೆ ಟ್ಯೂನಿಂಗ್. ಸಮಸ್ಯಾತ್ಮಕ ಪ್ರಶ್ನೆಗೆ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸುವ ಅಗತ್ಯವಿದೆಯೇ? ನಿಮ್ಮ ಪ್ರಶ್ನೆಯು ಸಾಮಾನ್ಯ SQL ಆಗಿರುವಾಗ ಇದು ಸಮಸ್ಯೆಯಲ್ಲ.
• ಮರುಬಳಕೆ ಪ್ರಶ್ನೆಗಳು. ಅದೇ SQL ಫೈಲ್‌ಗಳನ್ನು ಇತರ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗೆ ಎಳೆಯಿರಿ ಮತ್ತು ಬಿಡಿ ಏಕೆಂದರೆ ಇದು ಕೇವಲ ಹಳೆಯ SQL ಆಗಿದೆ - ಅದನ್ನು ಹಂಚಿಕೊಳ್ಳಿ.

ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಕಲ್ಪನೆಯು ತುಂಬಾ ತಂಪಾಗಿದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ತುಂಬಾ ಸರಳವಾಗಿದೆ, ಯೋಜನೆಯು ಅನೇಕರನ್ನು ಗಳಿಸಿದೆ ಅನುಯಾಯಿಗಳು ವಿವಿಧ ಭಾಷೆಗಳಲ್ಲಿ. ಮತ್ತು ನಾವು ಮುಂದೆ ORM ಅನ್ನು ಮೀರಿದ ಎಲ್ಲದರಿಂದ SQL ಕೋಡ್ ಅನ್ನು ಬೇರ್ಪಡಿಸುವ ಇದೇ ರೀತಿಯ ತತ್ತ್ವಶಾಸ್ತ್ರವನ್ನು ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.

IDE ಮತ್ತು DB ವ್ಯವಸ್ಥಾಪಕರು

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

ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ನಾನು ಮೌಸ್ ಅನ್ನು ಎಸೆದು ಕೋಡ್ ಬರೆಯುತ್ತೇನೆ. "HR" ಸ್ಕೀಮಾದಲ್ಲಿ ಯಾವ ಕೋಷ್ಟಕಗಳು (ಮತ್ತು ಯಾವ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ) ಒಳಗೊಂಡಿವೆ ಎಂಬುದನ್ನು ನೀವು ಕಂಡುಹಿಡಿಯಬೇಕು ಎಂದು ಹೇಳೋಣ. ಹೆಚ್ಚಿನ DBMS ಗಳಲ್ಲಿ, ಮಾಹಿತಿ_ಸ್ಕೀಮಾದಿಂದ ಈ ಸರಳ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಬಹುದು:

select table_name
     , ...
  from information_schema.tables
 where schema = 'HR'

ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡೇಟಾಬೇಸ್‌ಗೆ, ಅಂತಹ ಉಲ್ಲೇಖ ಕೋಷ್ಟಕಗಳ ವಿಷಯಗಳು ಪ್ರತಿ DBMS ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗುತ್ತವೆ. ಮತ್ತು, ಉದಾಹರಣೆಗೆ, MySQL ಗಾಗಿ, ಅದೇ ಉಲ್ಲೇಖ ಪುಸ್ತಕದಿಂದ ನೀವು ಈ DBMS ಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಟೇಬಲ್ ನಿಯತಾಂಕಗಳನ್ನು ಪಡೆಯಬಹುದು:

select table_name
     , storage_engine -- Используемый "движок" ("MyISAM", "InnoDB" etc)
     , row_format     -- Формат строки ("Fixed", "Dynamic" etc)
     , ...
  from information_schema.tables
 where schema = 'HR'

ಒರಾಕಲ್‌ಗೆ ಮಾಹಿತಿ_ಸ್ಕೀಮಾ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಅದು ಹೊಂದಿದೆ ಒರಾಕಲ್ ಮೆಟಾಡೇಟಾ, ಮತ್ತು ಯಾವುದೇ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುವುದಿಲ್ಲ:

select table_name
     , pct_free       -- Минимум свободного места в блоке данных (%)
     , pct_used       -- Минимум используемого места в блоке данных (%)
     , last_analyzed  -- Дата последнего сбора статистики
     , ...
  from all_tables
 where owner = 'HR'

ClickHouse ಇದಕ್ಕೆ ಹೊರತಾಗಿಲ್ಲ:

select name
     , engine -- Используемый "движок" ("MergeTree", "Dictionary" etc)
     , ...
  from system.tables
 where database = 'HR'

ಕಸ್ಸಂದ್ರದಲ್ಲಿ ಇದೇ ರೀತಿಯದ್ದನ್ನು ಮಾಡಬಹುದು (ಇದು ಟೇಬಲ್‌ಗಳ ಬದಲಿಗೆ ಕಾಲಮ್‌ಕುಟುಂಬಗಳನ್ನು ಮತ್ತು ಸ್ಕೀಮಾಗಳ ಬದಲಿಗೆ ಕೀಸ್ಪೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದೆ):

select columnfamily_name
     , compaction_strategy_class  -- Стратегия сборки мусора
     , gc_grace_seconds           -- Время жизни мусора
     , ...
  from system.schema_columnfamilies
 where keyspace_name = 'HR'

ಹೆಚ್ಚಿನ ಇತರ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ, ನೀವು ಇದೇ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಸಹ ಬರಬಹುದು (ಮೊಂಗೋ ಕೂಡ ಹೊಂದಿದೆ ವಿಶೇಷ ಸಿಸ್ಟಮ್ ಸಂಗ್ರಹಣೆ, ಇದು ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಸಂಗ್ರಹಣೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ).

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

ಪರಿಣಾಮವಾಗಿ, ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವ ಮತ್ತು ವಸ್ತುಗಳನ್ನು ಹುಡುಕುವ ಈ ವಿಧಾನವು ಹೆಚ್ಚು ಮೃದುವಾಗಿರುತ್ತದೆ, ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಈಗ ಅಗತ್ಯವಿರುವ ರೂಪದಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ನಿಖರವಾಗಿ ಪಡೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಪೋಸ್ಟ್‌ನಲ್ಲಿ ವಿವರಿಸಿದಂತೆ "ಯಾವುದೇ ಸ್ವರೂಪದಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡೇಟಾವನ್ನು ರಫ್ತು ಮಾಡುವುದು: IntelliJ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ IDE ಗಳು ಏನು ಮಾಡಬಹುದು").

ವಸ್ತುಗಳೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳು

ನಾವು ಅಗತ್ಯ ವಸ್ತುಗಳನ್ನು ಕಂಡುಕೊಂಡ ನಂತರ ಮತ್ತು ಅಧ್ಯಯನ ಮಾಡಿದ ನಂತರ, ಅವರೊಂದಿಗೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಮಾಡುವ ಸಮಯ. ನೈಸರ್ಗಿಕವಾಗಿ, ಕೀಬೋರ್ಡ್‌ನಿಂದ ನಿಮ್ಮ ಬೆರಳುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳದೆಯೇ.

ಟೇಬಲ್ ಅನ್ನು ಅಳಿಸುವುದು ಬಹುತೇಕ ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ ಎಂಬುದು ರಹಸ್ಯವಲ್ಲ:

drop table hr.persons

ಆದರೆ ಮೇಜಿನ ರಚನೆಯೊಂದಿಗೆ ಅದು ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗುತ್ತದೆ. ಯಾವುದೇ DBMS (ಹಲವು NoSQL ಸೇರಿದಂತೆ) ಒಂದು ರೂಪದಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದರಲ್ಲಿ "ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಬಹುದು", ಮತ್ತು ಅದರ ಮುಖ್ಯ ಭಾಗವು ಸ್ವಲ್ಪ ಭಿನ್ನವಾಗಿರುತ್ತದೆ (ಹೆಸರು, ಕಾಲಮ್ಗಳ ಪಟ್ಟಿ, ಡೇಟಾ ಪ್ರಕಾರಗಳು), ಆದರೆ ಇತರ ವಿವರಗಳು ನಾಟಕೀಯವಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ ಮತ್ತು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಆಂತರಿಕ ಸಾಧನ ಮತ್ತು ನಿರ್ದಿಷ್ಟ DBMS ಸಾಮರ್ಥ್ಯಗಳು. ನನ್ನ ಮೆಚ್ಚಿನ ಉದಾಹರಣೆಯೆಂದರೆ ಒರಾಕಲ್ ದಸ್ತಾವೇಜನ್ನು "ಟೇಬಲ್ ರಚಿಸಿ" ಸಿಂಟ್ಯಾಕ್ಸ್‌ಗಾಗಿ ಕೇವಲ "ಬೆತ್ತಲೆ" BNF ಗಳು ಮಾತ್ರ ಇವೆ 31 ಪುಟಗಳನ್ನು ಆಕ್ರಮಿಸಿ. ಇತರ DBMS ಗಳು ಹೆಚ್ಚು ಸಾಧಾರಣ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿವೆ, ಆದರೆ ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸಲು ಅನೇಕ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ವಿಶಿಷ್ಟ ಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ (ಪೋಸ್ಟ್‌ಗ್ರೆಸ್, MySQL, ಜಿರಳೆ, ಕಸ್ಸಂದ್ರ) ಮತ್ತೊಂದು IDE ಯಿಂದ (ವಿಶೇಷವಾಗಿ ಸಾರ್ವತ್ರಿಕವಾದ) ಯಾವುದೇ ಚಿತ್ರಾತ್ಮಕ "ಮಾಂತ್ರಿಕ" ಈ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂಬುದು ಅಸಂಭವವಾಗಿದೆ, ಮತ್ತು ಅದು ಸಾಧ್ಯವಾದರೂ ಸಹ, ಹೃದಯದ ಮಂಕಾದವರಿಗೆ ಇದು ಕೈಗನ್ನಡಿಯಾಗಿರುವುದಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸರಿಯಾಗಿ ಮತ್ತು ಸಕಾಲಿಕ ಲಿಖಿತ ಹೇಳಿಕೆ ಟೇಬಲ್ ರಚಿಸಿ ಇವೆಲ್ಲವನ್ನೂ ಸುಲಭವಾಗಿ ಬಳಸಲು, ಸಂಗ್ರಹಣೆ ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ವಿಶ್ವಾಸಾರ್ಹ, ಅತ್ಯುತ್ತಮ ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಆರಾಮದಾಯಕವಾಗಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

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

ಈಗ ಸ್ವಲ್ಪ ಸೆಳೆಯೋಣ

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

ಆದರೆ ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೆಚ್ಚು ಸರಳ, ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಸೊಗಸಾದ, ಮತ್ತು ಕೋಡ್ ಸಹಾಯದಿಂದ ಸಹಜವಾಗಿ ಪರಿಹರಿಸಬಹುದು. ಯಾವುದೇ ಸಂಕೀರ್ಣತೆಯ ರೇಖಾಚಿತ್ರಗಳನ್ನು ರಚಿಸಲು, ನಾವು ಹಲವಾರು ವಿಶೇಷ ಮಾರ್ಕ್ಅಪ್ ಭಾಷೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ (DOT, GraphML ಇತ್ಯಾದಿ), ಮತ್ತು ಅವರಿಗೆ ಅಂತಹ ಸೂಚನೆಗಳನ್ನು ಓದುವ ಮತ್ತು ಅವುಗಳನ್ನು ವಿವಿಧ ಸ್ವರೂಪಗಳಲ್ಲಿ ದೃಶ್ಯೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಸಂಪೂರ್ಣ ಸ್ಕ್ಯಾಟರಿಂಗ್ (GraphViz, PlantUML, Mermaid). . ಒಳ್ಳೆಯದು, ವಸ್ತುಗಳು ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಸಂಪರ್ಕಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು ಎಂದು ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ.

PlantUML ಮತ್ತು ಬಳಸಿಕೊಂಡು ಇದು ಹೇಗಿರಬಹುದು ಎಂಬುದರ ಸಣ್ಣ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ PostgreSQL ಗಾಗಿ ಡೆಮೊ ಡೇಟಾಬೇಸ್ (ಎಡಭಾಗದಲ್ಲಿ SQL ಪ್ರಶ್ನೆಯಿದೆ ಅದು PlantUML ಗೆ ಅಗತ್ಯವಿರುವ ಸೂಚನೆಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಬಲಭಾಗದಲ್ಲಿ ಫಲಿತಾಂಶವಿದೆ):

select '@startuml'||chr(10)||'hide methods'||chr(10)||'hide stereotypes' union all
select distinct ccu.table_name || ' --|> ' ||
       tc.table_name as val
  from table_constraints as tc
  join key_column_usage as kcu
    on tc.constraint_name = kcu.constraint_name
  join constraint_column_usage as ccu
    on ccu.constraint_name = tc.constraint_name
 where tc.constraint_type = 'FOREIGN KEY'
   and tc.table_name ~ '.*' union all
select '@enduml'

ಮತ್ತು ನೀವು ಸ್ವಲ್ಪ ಪ್ರಯತ್ನಿಸಿದರೆ, ನಂತರ ಆಧರಿಸಿ PlantUML ಗಾಗಿ ER ಟೆಂಪ್ಲೇಟ್ ನೀವು ನಿಜವಾದ ER ರೇಖಾಚಿತ್ರಕ್ಕೆ ಹೋಲುವದನ್ನು ಪಡೆಯಬಹುದು:

SQL ಪ್ರಶ್ನೆಯು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ

-- Шапка
select '@startuml
        !define Table(name,desc) class name as "desc" << (T,#FFAAAA) >>
        !define primary_key(x) <b>x</b>
        !define unique(x) <color:green>x</color>
        !define not_null(x) <u>x</u>
        hide methods
        hide stereotypes'
 union all
-- Таблицы
select format('Table(%s, "%s n information about %s") {'||chr(10), table_name, table_name, table_name) ||
       (select string_agg(column_name || ' ' || upper(udt_name), chr(10))
          from information_schema.columns
         where table_schema = 'public'
           and table_name = t.table_name) || chr(10) || '}'
  from information_schema.tables t
 where table_schema = 'public'
 union all
-- Связи между таблицами
select distinct ccu.table_name || ' "1" --> "0..N" ' || tc.table_name || format(' : "A %s may haven many %s"', ccu.table_name, tc.table_name)
  from information_schema.table_constraints as tc
  join information_schema.key_column_usage as kcu on tc.constraint_name = kcu.constraint_name
  join information_schema.constraint_column_usage as ccu on ccu.constraint_name = tc.constraint_name
 where tc.constraint_type = 'FOREIGN KEY'
   and ccu.constraint_schema = 'public'
   and tc.table_name ~ '.*'
 union all
-- Подвал
select '@enduml'

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

ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಮಾನಿಟರಿಂಗ್

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

ಆದರೆ ಮೇಲ್ವಿಚಾರಣಾ ಪ್ರಕ್ರಿಯೆಯು ಹೆಚ್ಚು ವಿನೋದ ಮತ್ತು ಸ್ನೇಹಪರವಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಎಲ್ಲರಿಗೂ ಪ್ರವೇಶಿಸಬಹುದು ಮತ್ತು ಪಾರದರ್ಶಕವಾಗಿರುತ್ತದೆ. ಕನಿಷ್ಠ ಅದರ ಮೂಲ ಭಾಗ, ಮುಖ್ಯ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಹೆಚ್ಚುವರಿಯಾಗಿ (ಇದು ಖಂಡಿತವಾಗಿಯೂ ಉಪಯುಕ್ತವಾಗಿದೆ ಮತ್ತು ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ ಭರಿಸಲಾಗದು). ಯಾವುದೇ DBMS ಅದರ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಉಚಿತವಾಗಿ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಉಚಿತವಾಗಿದೆ. ಅದೇ "ರಕ್ತಸಿಕ್ತ" ಒರಾಕಲ್ DB ನಲ್ಲಿ, ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಸೆಷನ್‌ಗಳಿಂದ ಹಿಡಿದು ಬಫರ್ ಕ್ಯಾಶ್‌ನ ಸ್ಥಿತಿಯವರೆಗೆ ಸಿಸ್ಟಮ್ ವೀಕ್ಷಣೆಗಳಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು (ಉದಾಹರಣೆಗೆ, DBA ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ವಿಭಾಗ "ಮೇಲ್ವಿಚಾರಣೆ"). Postgresql ಸಹ ಸಿಸ್ಟಮ್ ವೀಕ್ಷಣೆಗಳ ಸಂಪೂರ್ಣ ಗುಂಪನ್ನು ಹೊಂದಿದೆ ಡೇಟಾಬೇಸ್ ಮೇಲ್ವಿಚಾರಣೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ ಯಾವುದೇ DBA ಯ ದೈನಂದಿನ ಜೀವನದಲ್ಲಿ ಅನಿವಾರ್ಯವಾದವು, ಉದಾಹರಣೆಗೆ pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL ಇದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಸ್ಕೀಮಾವನ್ನು ಸಹ ಹೊಂದಿದೆ. ಕಾರ್ಯಕ್ಷಮತೆ_ಸ್ಕೀಮಾ. ಎ ಇನ್ ಮೊಂಗೋ ಅಂತರ್ನಿರ್ಮಿತ ಪ್ರೊಫೈಲರ್ ಸಿಸ್ಟಂ ಸಂಗ್ರಹಕ್ಕೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ system.profile.

ಹೀಗಾಗಿ, ಕಸ್ಟಮ್ sql ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ವಹಿಸಬಲ್ಲ ಕೆಲವು ರೀತಿಯ ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಾಹಕ (ಟೆಲಿಗ್ರಾಫ್, ಮೆಟ್ರಿಕ್‌ಬೀಟ್, ಕಲೆಕ್ಟೆಡ್) ನೊಂದಿಗೆ ಶಸ್ತ್ರಸಜ್ಜಿತವಾಗಿದೆ, ಈ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹಣೆ (ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿ, ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್, ಟೈಮ್‌ಸ್ಕೇಲ್ಡ್‌ಬಿ) ಮತ್ತು ವಿಶ್ಯುಲೈಜರ್ (ಗ್ರಾಫನಾ, ಕಿಬಾನಾ), ನೀವು ಸಾಕಷ್ಟು ಸುಲಭವಾಗಿ ಪಡೆಯಬಹುದು ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಇತರ ಸಿಸ್ಟಮ್-ವೈಡ್ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ನಿಕಟವಾಗಿ ಸಂಯೋಜಿಸಲ್ಪಡುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನಿಂದ, OS ನಿಂದ, ಇತ್ಯಾದಿ. ಪಡೆಯಲಾಗಿದೆ). ಉದಾಹರಣೆಗೆ, ಇದನ್ನು pgwatch2 ನಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ, ಇದು InfluxDB + Grafana ಸಂಯೋಜನೆಯನ್ನು ಮತ್ತು ಸಿಸ್ಟಮ್ ವೀಕ್ಷಣೆಗಳಿಗೆ ಪ್ರಶ್ನೆಗಳ ಗುಂಪನ್ನು ಬಳಸುತ್ತದೆ, ಅದನ್ನು ಸಹ ಪ್ರವೇಶಿಸಬಹುದು ಕಸ್ಟಮ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಸೇರಿಸಿ.

ಒಟ್ಟು

ಮತ್ತು ಇದು ಸಾಮಾನ್ಯ SQL ಕೋಡ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಏನು ಮಾಡಬಹುದು ಎಂಬುದರ ಅಂದಾಜು ಪಟ್ಟಿ ಮಾತ್ರ. ನೀವು ಇನ್ನೂ ಹೆಚ್ಚಿನ ಉಪಯೋಗಗಳನ್ನು ಕಾಣಬಹುದು ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ, ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ. ಮತ್ತು ಈ ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಮತ್ತು ಮುಂದಿನ ಬಾರಿ ಅದನ್ನು ನಿಮ್ಮ CI/CD ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಸೇರಿಸುವುದು ಹೇಗೆ (ಮತ್ತು ಮುಖ್ಯವಾಗಿ ಏಕೆ) ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ.

ಮೂಲ: www.habr.com