"ਕੋਡ ਦੇ ਤੌਰ ਤੇ ਡਾਟਾਬੇਸ" ਅਨੁਭਵ

SQL, ਕੀ ਸਰਲ ਹੋ ਸਕਦਾ ਹੈ? ਸਾਡੇ ਵਿੱਚੋਂ ਹਰ ਕੋਈ ਇੱਕ ਸਧਾਰਨ ਬੇਨਤੀ ਲਿਖ ਸਕਦਾ ਹੈ - ਅਸੀਂ ਟਾਈਪ ਕਰਦੇ ਹਾਂ ਦੀ ਚੋਣ ਕਰੋ, ਲੋੜੀਂਦੇ ਕਾਲਮਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਫਿਰ ਤੱਕ, ਸਾਰਣੀ ਦਾ ਨਾਮ, ਵਿੱਚ ਕੁਝ ਸ਼ਰਤਾਂ ਜਿੱਥੇ ਕਿ ਅਤੇ ਇਹ ਸਭ ਹੈ - ਉਪਯੋਗੀ ਡੇਟਾ ਸਾਡੀ ਜੇਬ ਵਿੱਚ ਹੈ, ਅਤੇ (ਲਗਭਗ) ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿ ਉਸ ਸਮੇਂ DBMS ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਹੈ (ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਬਿਲਕੁਲ ਵੀ DBMS ਨਹੀਂ). ਨਤੀਜੇ ਵਜੋਂ, ਲਗਭਗ ਕਿਸੇ ਵੀ ਡੇਟਾ ਸਰੋਤ ਨਾਲ ਕੰਮ ਕਰਨਾ (ਸੰਬੰਧਕ ਅਤੇ ਅਜਿਹਾ ਨਹੀਂ) ਨੂੰ ਆਮ ਕੋਡ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਉਸ ਸਭ ਦੇ ਨਾਲ ਜੋ ਇਸਦਾ ਮਤਲਬ ਹੈ - ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ, ਕੋਡ ਸਮੀਖਿਆ, ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ, ਆਟੋਟੈਸਟ, ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਹੈ)। ਅਤੇ ਇਹ ਨਾ ਸਿਰਫ਼ ਡੇਟਾ, ਸਕੀਮਾਂ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸਟੋਰੇਜ ਦੇ ਪੂਰੇ ਜੀਵਨ ਲਈ. ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮਾਂ ਅਤੇ "ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਡਾਟਾਬੇਸ" ਦੇ ਲੈਂਸ ਦੇ ਤਹਿਤ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।

ਅਤੇ ਆਓ ਸਹੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੀਏ ਓਆਰਐਮ. "SQL ਬਨਾਮ 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. ਮੈਂ ਆਪਣੇ ਮੁਫਤ ਅਨੁਵਾਦ ਵਿੱਚ ਆਮ ਸੰਕਲਪ ਤੋਂ ਕੁਝ ਲਾਈਨਾਂ ਦੇਵਾਂਗਾ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਤੋਂ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਣੂ ਹੋ ਸਕਦੇ ਹੋ ਇੱਥੇ.

Clojure DSL ਬਣਾਉਣ ਲਈ ਇੱਕ ਵਧੀਆ ਭਾਸ਼ਾ ਹੈ, ਪਰ SQL ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਵਧੀਆ DSL ਹੈ, ਅਤੇ ਸਾਨੂੰ ਕਿਸੇ ਹੋਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਐਸ-ਐਕਸਪ੍ਰੈਸ਼ਨ ਵਧੀਆ ਹਨ, ਪਰ ਉਹ ਇੱਥੇ ਕੁਝ ਨਵਾਂ ਨਹੀਂ ਜੋੜਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਬਰੈਕਟਾਂ ਦੀ ਖ਼ਾਤਰ ਬਰੈਕਟਾਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ. ਸਹਿਮਤ ਨਹੀਂ ਹੋ? ਫਿਰ ਉਸ ਪਲ ਦੀ ਉਡੀਕ ਕਰੋ ਜਦੋਂ ਡੇਟਾਬੇਸ ਉੱਤੇ ਐਬਸਟਰੈਕਸ਼ਨ ਲੀਕ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਫੰਕਸ਼ਨ ਨਾਲ ਲੜਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ (raw-sql)

ਤਾਂ ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਚਲੋ 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 "some('funky'::SYNTAX)")).
• ਵਧੀਆ ਸੰਪਾਦਕ ਸਹਾਇਤਾ. ਤੁਹਾਡੇ ਸੰਪਾਦਕ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸ਼ਾਨਦਾਰ SQL ਸਮਰਥਨ ਹੈ। SQL ਨੂੰ SQL ਦੇ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਕੇ ਤੁਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।
• ਟੀਮ ਅਨੁਕੂਲਤਾ. ਤੁਹਾਡੇ DBAs ਉਸ SQL ਨੂੰ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਆਪਣੇ Clojure ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵਰਤਦੇ ਹੋ।
• ਆਸਾਨ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ. ਇੱਕ ਸਮੱਸਿਆ ਵਾਲੀ ਪੁੱਛਗਿੱਛ ਲਈ ਇੱਕ ਯੋਜਨਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ? ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਪੁੱਛਗਿੱਛ ਨਿਯਮਤ SQL ਹੈ।
• ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਉਹੀ SQL ਫਾਈਲਾਂ ਨੂੰ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਖਿੱਚੋ ਅਤੇ ਸੁੱਟੋ ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਸਧਾਰਨ ਪੁਰਾਣਾ SQL ਹੈ - ਇਸਨੂੰ ਸਾਂਝਾ ਕਰੋ।

ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇਹ ਵਿਚਾਰ ਬਹੁਤ ਠੰਡਾ ਹੈ ਅਤੇ ਉਸੇ ਸਮੇਂ ਬਹੁਤ ਸਧਾਰਨ ਹੈ, ਜਿਸਦਾ ਧੰਨਵਾਦ ਪ੍ਰੋਜੈਕਟ ਨੇ ਬਹੁਤ ਸਾਰੇ ਲਾਭ ਪ੍ਰਾਪਤ ਕੀਤੇ ਹਨ ਪੈਰੋਕਾਰ ਕਈ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ। ਅਤੇ ਅਸੀਂ ਅੱਗੇ ਓਆਰਐਮ ਤੋਂ ਦੂਰ ਹਰ ਚੀਜ਼ ਤੋਂ 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'

ਕਲਿਕਹਾਊਸ ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ ਹੈ:

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'

ਬਹੁਤੇ ਹੋਰ ਡੇਟਾਬੇਸ ਲਈ, ਤੁਸੀਂ ਸਮਾਨ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਵੀ ਆ ਸਕਦੇ ਹੋ (ਇੱਥੋਂ ਤੱਕ ਕਿ ਮੋਂਗੋ ਕੋਲ ਵੀ ਹੈ ਵਿਸ਼ੇਸ਼ ਸਿਸਟਮ ਸੰਗ੍ਰਹਿ, ਜਿਸ ਵਿੱਚ ਸਿਸਟਮ ਵਿੱਚ ਸਾਰੇ ਸੰਗ੍ਰਹਿ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੈ)।

ਬੇਸ਼ੱਕ, ਇਸ ਤਰੀਕੇ ਨਾਲ ਤੁਸੀਂ ਨਾ ਸਿਰਫ਼ ਟੇਬਲਾਂ ਬਾਰੇ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਵਸਤੂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ. ਸਮੇਂ-ਸਮੇਂ 'ਤੇ, ਦਿਆਲੂ ਲੋਕ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਲਈ ਅਜਿਹੇ ਕੋਡ ਸਾਂਝੇ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਹੈਬਰਾ ਲੇਖਾਂ ਦੀ ਲੜੀ ਵਿੱਚ "ਪੋਸਟਗਰੇਐਸਕਯੂਐਲ ਡੇਟਾਬੇਸ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ ਲਈ ਫੰਕਸ਼ਨ" (ਅਯਬ, ਬੈਨ, ਵਰਜਿਸ਼ਖਾਨਾ). ਬੇਸ਼ੱਕ, ਸਵਾਲਾਂ ਦੇ ਇਸ ਪੂਰੇ ਪਹਾੜ ਨੂੰ ਮੇਰੇ ਸਿਰ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਟਾਈਪ ਕਰਨਾ ਬਹੁਤ ਖੁਸ਼ੀ ਦੀ ਗੱਲ ਹੈ, ਇਸਲਈ ਮੇਰੇ ਮਨਪਸੰਦ IDE/ਸੰਪਾਦਕ ਵਿੱਚ ਮੇਰੇ ਕੋਲ ਅਕਸਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲਾਂ ਲਈ ਸਨਿੱਪਟ ਦਾ ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਸੈੱਟ ਹੈ, ਅਤੇ ਜੋ ਬਾਕੀ ਰਹਿੰਦਾ ਹੈ ਉਹ ਟਾਈਪ ਕਰਨਾ ਹੈ। ਟੈਂਪਲੇਟ ਵਿੱਚ ਵਸਤੂ ਦੇ ਨਾਮ.

ਨਤੀਜੇ ਵਜੋਂ, ਨੈਵੀਗੇਟ ਕਰਨ ਅਤੇ ਵਸਤੂਆਂ ਦੀ ਖੋਜ ਕਰਨ ਦਾ ਇਹ ਤਰੀਕਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਚਕਦਾਰ ਹੈ, ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਉਸ ਰੂਪ ਵਿੱਚ ਬਿਲਕੁਲ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਹੁਣ ਜ਼ਰੂਰੀ ਹੈ (ਜਿਵੇਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਪੋਸਟ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ "ਕਿਸੇ ਵੀ ਫਾਰਮੈਟ ਵਿੱਚ ਡੇਟਾਬੇਸ ਤੋਂ ਡੇਟਾ ਨਿਰਯਾਤ ਕਰਨਾ: IDEs IntelliJ ਪਲੇਟਫਾਰਮ 'ਤੇ ਕੀ ਕਰ ਸਕਦੇ ਹਨ").

ਵਸਤੂਆਂ ਨਾਲ ਸੰਚਾਲਨ

ਜਦੋਂ ਅਸੀਂ ਲੋੜੀਂਦੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਲੱਭ ਲਿਆ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦਾ ਅਧਿਐਨ ਕਰ ਲਿਆ ਹੈ, ਇਹ ਉਹਨਾਂ ਨਾਲ ਕੁਝ ਲਾਭਦਾਇਕ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਤੁਹਾਡੀਆਂ ਉਂਗਲਾਂ ਨੂੰ ਕੀਬੋਰਡ ਤੋਂ ਹਟਾਏ ਬਿਨਾਂ ਵੀ।

ਇਹ ਕੋਈ ਭੇਤ ਨਹੀਂ ਹੈ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਸਾਰਣੀ ਨੂੰ ਮਿਟਾਉਣਾ ਲਗਭਗ ਸਾਰੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਦਿਖਾਈ ਦੇਵੇਗਾ:

drop table hr.persons

ਪਰ ਸਾਰਣੀ ਦੀ ਸਿਰਜਣਾ ਦੇ ਨਾਲ ਇਹ ਹੋਰ ਦਿਲਚਸਪ ਹੋ ਜਾਂਦਾ ਹੈ. ਲਗਭਗ ਕੋਈ ਵੀ DBMS (ਬਹੁਤ ਸਾਰੇ NoSQL ਸਮੇਤ) ਇੱਕ ਜਾਂ ਦੂਜੇ ਰੂਪ ਵਿੱਚ "ਸਾਰਣੀ ਬਣਾ" ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਮੁੱਖ ਹਿੱਸਾ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਵੀ ਹੋਵੇਗਾ (ਨਾਮ, ਕਾਲਮਾਂ ਦੀ ਸੂਚੀ, ਡੇਟਾ ਕਿਸਮ), ਪਰ ਹੋਰ ਵੇਰਵੇ ਨਾਟਕੀ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਡਿਵਾਈਸ ਅਤੇ ਇੱਕ ਖਾਸ DBMS ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ। ਮੇਰੀ ਮਨਪਸੰਦ ਉਦਾਹਰਨ ਇਹ ਹੈ ਕਿ ਓਰੇਕਲ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ "ਟੇਬਲ ਬਣਾਓ" ਸੰਟੈਕਸ ਲਈ ਸਿਰਫ "ਨੰਗੇ" BNF ਹਨ 31 ਪੰਨਿਆਂ 'ਤੇ ਕਬਜ਼ਾ ਕਰੋ. ਹੋਰ DBMS ਵਿੱਚ ਵਧੇਰੇ ਮਾਮੂਲੀ ਸਮਰੱਥਾਵਾਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਟੇਬਲ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਅਤੇ ਵਿਲੱਖਣ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ (ਡਾਕਖਾਨੇ, MySQL, ਕਾਕਰੋਚ, cassandra). ਇਹ ਅਸੰਭਵ ਹੈ ਕਿ ਕਿਸੇ ਹੋਰ IDE (ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ ਯੂਨੀਵਰਸਲ) ਤੋਂ ਕੋਈ ਵੀ ਗ੍ਰਾਫਿਕਲ "ਵਿਜ਼ਰਡ" ਇਹਨਾਂ ਸਾਰੀਆਂ ਯੋਗਤਾਵਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਵਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ, ਅਤੇ ਭਾਵੇਂ ਇਹ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਦਿਲ ਦੇ ਬੇਹੋਸ਼ ਲਈ ਇੱਕ ਤਮਾਸ਼ਾ ਨਹੀਂ ਹੋਵੇਗਾ. ਉਸੇ ਸਮੇਂ, ਇੱਕ ਸਹੀ ਅਤੇ ਸਮੇਂ ਸਿਰ ਲਿਖਤੀ ਬਿਆਨ ਸਾਰਣੀ ਬਣਾਓ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਵਰਤਣ, ਸਟੋਰੇਜ ਅਤੇ ਤੁਹਾਡੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਭਰੋਸੇਯੋਗ, ਅਨੁਕੂਲ ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਆਰਾਮਦਾਇਕ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ।

ਨਾਲ ਹੀ, ਬਹੁਤ ਸਾਰੇ DBMS ਕੋਲ ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਖਾਸ ਕਿਸਮਾਂ ਦੀਆਂ ਵਸਤੂਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਹੋਰ 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'

ਜੇ ਤੁਸੀਂ ਧਿਆਨ ਨਾਲ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਬਹੁਤ ਸਾਰੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਟੂਲ ਵੀ ਸਮਾਨ ਸਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਹ ਸੱਚ ਹੈ ਕਿ ਇਹ ਬੇਨਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਡੂੰਘੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੋਡ ਵਿੱਚ "ਹਾਰਡਵਾਇਰਡ" ਅਤੇ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੈ, ਉਹਨਾਂ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸੋਧ ਦਾ ਜ਼ਿਕਰ ਨਾ ਕਰਨਾ।

ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਨਿਗਰਾਨੀ

ਆਉ ਇੱਕ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਗੁੰਝਲਦਾਰ ਵਿਸ਼ੇ ਵੱਲ ਵਧੀਏ - ਡੇਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ. ਮੈਨੂੰ "ਮੇਰੇ ਇੱਕ ਦੋਸਤ" ਦੁਆਰਾ ਦੱਸੀ ਗਈ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸੱਚੀ ਕਹਾਣੀ ਯਾਦ ਹੈ। ਇੱਕ ਹੋਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਖਾਸ ਸ਼ਕਤੀਸ਼ਾਲੀ DBA ਰਹਿੰਦਾ ਸੀ, ਅਤੇ ਕੁਝ ਡਿਵੈਲਪਰ ਉਸਨੂੰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਜਾਣਦੇ ਸਨ, ਜਾਂ ਕਦੇ ਉਸਨੂੰ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਸੀ (ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ, ਅਫਵਾਹਾਂ ਦੇ ਅਨੁਸਾਰ, ਉਸਨੇ ਅਗਲੀ ਇਮਾਰਤ ਵਿੱਚ ਕਿਤੇ ਕੰਮ ਕੀਤਾ ਸੀ)। ਘੰਟੇ "X" 'ਤੇ, ਜਦੋਂ ਇੱਕ ਵੱਡੇ ਰਿਟੇਲਰ ਦੀ ਪੋਡਕਸ਼ਨ ਪ੍ਰਣਾਲੀ ਇੱਕ ਵਾਰ ਫਿਰ "ਬੁਰਾ ਮਹਿਸੂਸ" ਕਰਨ ਲੱਗੀ, ਉਸਨੇ ਚੁੱਪਚਾਪ ਓਰੇਕਲ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਮੈਨੇਜਰ ਤੋਂ ਗ੍ਰਾਫਾਂ ਦੇ ਸਕਰੀਨਸ਼ਾਟ ਭੇਜੇ, ਜਿਸ 'ਤੇ ਉਸਨੇ "ਸਮਝਣਯੋਗਤਾ" ਲਈ ਲਾਲ ਮਾਰਕਰ ਨਾਲ ਨਾਜ਼ੁਕ ਸਥਾਨਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਉਜਾਗਰ ਕੀਤਾ ( ਇਹ, ਇਸ ਨੂੰ ਹਲਕੇ ਤੌਰ 'ਤੇ ਕਹਿਣ ਲਈ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਦਦ ਨਹੀਂ ਕੀਤੀ). ਅਤੇ ਇਸ "ਫੋਟੋ ਕਾਰਡ" ਦੇ ਅਧਾਰ ਤੇ ਮੈਨੂੰ ਇਲਾਜ ਕਰਨਾ ਪਿਆ. ਉਸੇ ਸਮੇਂ, ਕਿਸੇ ਦੀ ਵੀ ਕੀਮਤੀ (ਸ਼ਬਦ ਦੇ ਦੋਵਾਂ ਅਰਥਾਂ ਵਿੱਚ) ਐਂਟਰਪ੍ਰਾਈਜ਼ ਮੈਨੇਜਰ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ ਸਿਸਟਮ ਗੁੰਝਲਦਾਰ ਅਤੇ ਮਹਿੰਗਾ ਹੈ, ਅਚਾਨਕ "ਡਿਵੈਲਪਰ ਕਿਸੇ ਚੀਜ਼ 'ਤੇ ਠੋਕਰ ਖਾਂਦੇ ਹਨ ਅਤੇ ਸਭ ਕੁਝ ਤੋੜ ਦਿੰਦੇ ਹਨ।" ਇਸ ਲਈ, ਡਿਵੈਲਪਰਾਂ ਨੇ "ਅਨੁਭਵੀ ਤੌਰ 'ਤੇ" ਬ੍ਰੇਕਾਂ ਦਾ ਸਥਾਨ ਅਤੇ ਕਾਰਨ ਲੱਭਿਆ ਅਤੇ ਇੱਕ ਪੈਚ ਜਾਰੀ ਕੀਤਾ। ਜੇਕਰ ਨੇੜ ਭਵਿੱਖ ਵਿੱਚ DBA ਤੋਂ ਖਤਰਨਾਕ ਪੱਤਰ ਦੁਬਾਰਾ ਨਾ ਆਇਆ, ਤਾਂ ਹਰ ਕੋਈ ਰਾਹਤ ਦਾ ਸਾਹ ਲਵੇਗਾ ਅਤੇ ਆਪਣੇ ਮੌਜੂਦਾ ਕੰਮਾਂ (ਨਵੇਂ ਪੱਤਰ ਤੱਕ) ਵਾਪਸ ਆ ਜਾਵੇਗਾ।

ਪਰ ਨਿਗਰਾਨੀ ਪ੍ਰਕਿਰਿਆ ਵਧੇਰੇ ਮਜ਼ੇਦਾਰ ਅਤੇ ਦੋਸਤਾਨਾ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਹਰ ਕਿਸੇ ਲਈ ਪਹੁੰਚਯੋਗ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ। ਘੱਟੋ-ਘੱਟ ਇਸਦਾ ਮੁਢਲਾ ਹਿੱਸਾ, ਮੁੱਖ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ (ਜੋ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹਨ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਅਟੱਲ ਹੈ) ਦੇ ਇੱਕ ਜੋੜ ਵਜੋਂ। ਕੋਈ ਵੀ DBMS ਆਪਣੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸਾਂਝੀ ਕਰਨ ਲਈ ਸੁਤੰਤਰ ਅਤੇ ਬਿਲਕੁਲ ਮੁਫਤ ਹੈ। ਉਸੇ "ਖੂਨੀ" ਓਰੇਕਲ ਡੀਬੀ ਵਿੱਚ, ਕਾਰਜਕੁਸ਼ਲਤਾ ਬਾਰੇ ਲਗਭਗ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਸਿਸਟਮ ਦ੍ਰਿਸ਼ਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਸੈਸ਼ਨਾਂ ਤੋਂ ਲੈ ਕੇ ਬਫਰ ਕੈਸ਼ ਦੀ ਸਥਿਤੀ ਤੱਕ (ਉਦਾਹਰਨ ਲਈ, DBA ਸਕ੍ਰਿਪਟਾਂ, ਭਾਗ "ਨਿਗਰਾਨੀ"). Postgresql ਕੋਲ ਸਿਸਟਮ ਦ੍ਰਿਸ਼ਾਂ ਦਾ ਇੱਕ ਪੂਰਾ ਸਮੂਹ ਵੀ ਹੈ ਡਾਟਾਬੇਸ ਨਿਗਰਾਨੀ, ਖਾਸ ਤੌਰ 'ਤੇ ਉਹ ਜੋ ਕਿਸੇ ਵੀ DBA ਦੇ ਰੋਜ਼ਾਨਾ ਜੀਵਨ ਵਿੱਚ ਲਾਜ਼ਮੀ ਹਨ, ਜਿਵੇਂ ਕਿ pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL ਕੋਲ ਇਸਦੇ ਲਈ ਇੱਕ ਵੱਖਰੀ ਸਕੀਮਾ ਵੀ ਹੈ। ਪ੍ਰਦਰਸ਼ਨ_ਸਕੀਮਾ. ਏ ਇਨ ਮੋਂਗੋ ਬਿਲਟ-ਇਨ ਪ੍ਰੋਫਾਈਲਰ ਇੱਕ ਸਿਸਟਮ ਸੰਗ੍ਰਹਿ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ system.profile.

ਇਸ ਤਰ੍ਹਾਂ, ਕੁਝ ਕਿਸਮ ਦੇ ਮੈਟ੍ਰਿਕਸ ਕੁਲੈਕਟਰ (ਟੈਲੀਗ੍ਰਾਫ, ਮੈਟ੍ਰਿਕਬੀਟ, ਕਲੈਕਟਡ) ਨਾਲ ਲੈਸ ਜੋ ਕਸਟਮ sql ਪੁੱਛਗਿੱਛ ਕਰ ਸਕਦੇ ਹਨ, ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ (InfluxDB, Elasticsearch, Timescaledb) ਅਤੇ ਇੱਕ ਵਿਜ਼ੂਅਲਾਈਜ਼ਰ (Grafana, Kibana) ਦੀ ਇੱਕ ਸਟੋਰੇਜ, ਤੁਸੀਂ ਕਾਫ਼ੀ ਆਸਾਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਇੱਕ ਲਚਕਦਾਰ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਜੋ ਹੋਰ ਸਿਸਟਮ-ਵਿਆਪਕ ਮੈਟ੍ਰਿਕਸ (ਪ੍ਰਾਪਤ, ਉਦਾਹਰਨ ਲਈ, ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਤੋਂ, OS ਤੋਂ, ਆਦਿ) ਨਾਲ ਨੇੜਿਓਂ ਏਕੀਕ੍ਰਿਤ ਹੋਵੇਗੀ। ਜਿਵੇਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਇਹ pgwatch2 ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ InfluxDB + Grafana ਸੁਮੇਲ ਅਤੇ ਸਿਸਟਮ ਦ੍ਰਿਸ਼ਾਂ ਲਈ ਸਵਾਲਾਂ ਦੇ ਇੱਕ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਐਕਸੈਸ ਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕਸਟਮ ਸਵਾਲ ਸ਼ਾਮਲ ਕਰੋ.

ਕੁੱਲ

ਅਤੇ ਇਹ ਸਿਰਫ ਇੱਕ ਅਨੁਮਾਨਿਤ ਸੂਚੀ ਹੈ ਜੋ ਨਿਯਮਤ SQL ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਾਡੇ ਡੇਟਾਬੇਸ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਉਪਯੋਗ ਲੱਭ ਸਕਦੇ ਹੋ, ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ. ਅਤੇ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਕਿ ਕਿਵੇਂ (ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ) ਇਸ ਸਭ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਅਗਲੀ ਵਾਰ ਤੁਹਾਡੀ CI/CD ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਹੈ।

ਸਰੋਤ: www.habr.com