"Database as Code" အတွေ့အကြုံ

SQL၊ ဘယ်အရာက ပိုရိုးရှင်းနိုင်မလဲ။ ကျွန်ုပ်တို့တစ်ဦးစီသည် ရိုးရှင်းသော တောင်းဆိုချက်ကို ရေးသားနိုင်သည် - ကျွန်ုပ်တို့ စာရိုက်ပါ။ ကို selectထို့နောက် လိုအပ်သောကော်လံများကို စာရင်းပြုစုပါ။ မှဇယားအမည်၊ အခြေအနေအချို့ ဘယ်မှာ ဒါပါပဲ - အသုံးဝင်သောဒေတာသည် ကျွန်ုပ်တို့၏အိတ်ကပ်ထဲတွင်ရှိပြီး (နီးပါး) မည်သည့် DBMS သည် ထိုအချိန်တွင် မည်သည့်အဖုံးအောက်တွင်ရှိနေသည်ဖြစ်စေ (သို့မဟုတ် ဖြစ်နိုင်သည် DBMS လုံးဝမဟုတ်ပါ။) ရလဒ်အနေဖြင့်၊ ဒေတာအရင်းအမြစ်အားလုံးနီးပါး (ဆက်စပ်မှုမရှိသော၊ မဟုတ်ဘဲ) ဖြင့်လုပ်ဆောင်ခြင်းသည် သာမန်ကုဒ်၏ရှုထောင့်မှ (၎င်းကို ဆိုလိုသည်မှာ - ဗားရှင်းထိန်းချုပ်မှု၊ ကုဒ်ပြန်လည်သုံးသပ်မှု၊ တည်ငြိမ်မှုခွဲခြမ်းစိတ်ဖြာမှု၊ အလိုအလျောက်စမ်းသပ်မှုများ၊ နှင့် ဒါတွေအားလုံးပါ)။ ၎င်းသည် ဒေတာကိုယ်တိုင်၊ အစီအစဉ်များနှင့် ရွှေ့ပြောင်းမှုများတွင်သာမက ယေဘုယျအားဖြင့် သိုလှောင်မှုဘဝတစ်ခုလုံးနှင့် သက်ဆိုင်ပါသည်။ ဤဆောင်းပါးတွင် ကျွန်ုပ်တို့သည် “ဒေတာဘေ့စ်ကဲ့သို့ကုဒ်” ၏ မှန်ဘီလူးအောက်ရှိ ဒေတာဘေ့စ်အမျိုးမျိုးနှင့် လုပ်ဆောင်ခြင်းဆိုင်ရာ ပြဿနာများအကြောင်း ဆွေးနွေးပါမည်။

ပြီးတော့ ညာဘက်ကနေ စလိုက်ရအောင် ORM. "SQL vs ORM" အမျိုးအစား၏ ပထမဆုံးတိုက်ပွဲများကို ပြန်လည်သတိပြုမိခဲ့သည်။ Petrine Rus အကြို၊.

Object-relational mapping

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 ကုဒ်အချို့ကို အများအပြားထုတ်ပေးပြီး လုပ်ဆောင်သည်။ စကားမစပ်၊ developer များသည် အချို့သော abstractions များကို ညွှန်ပြသည့် ကီလိုမီတာများဖြင့် ၎င်းတို့၏ database မှ ၎င်းတို့ကိုယ်ကို သီးခြားခွဲထုတ်ရန် အစွမ်းကုန် ကြိုးစားနေကြသည်။ "SQL အမုန်း".

အတားအဆီးများ၏အခြားတစ်ဖက်တွင်၊ စစ်မှန်သော“ လက်လုပ်” SQL ၏လိုက်နာသူများသည်နောက်ထပ်အလွှာများနှင့် abstraction များမပါဘဲ၎င်းတို့၏ DBMS မှဖျော်ရည်အားလုံးကိုညှစ်ထုတ်နိုင်စွမ်းကိုသတိပြုမိသည်။ ရလဒ်အနေဖြင့် database တွင် အထူးလေ့ကျင့်ထားသောလူများပါဝင်သည့် “ဒေတာဗဟိုပြု” ပရောဂျက်များ ပေါ်လာသည် (၎င်းတို့သည် “အခြေခံပညာရှင်များ” လည်းဖြစ်ကြသည်၊ ၎င်းတို့သည် “အခြေခံပညာရှင်များ” လည်းဖြစ်ကြသည်၊ ၎င်းတို့သည် “basdeners” စသည်ဖြင့်) နှင့် developer များ၊ အဆင်သင့်လုပ်ထားသည့် အမြင်များနှင့် သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းများကို အသေးစိတ်မလေ့လာဘဲ “ဆွဲ” ရန်သာ လိုအပ်သည်။

ငါတို့မှာ ကမ္ဘာနှစ်ခုလုံးမှာ အကောင်းဆုံးတွေရှိနေရင် ဘယ်လိုလုပ်မလဲ။ ဤအရာသည် အသက်ကို ခိုင်ခံ့စေသော အမည်ဖြင့် အံ့သြဖွယ်ကောင်းသော ကိရိယာတစ်ခုဖြင့် ပြုလုပ်ပုံဖြစ်သည်။ Yesql. ကျွန်ုပ်၏အခမဲ့ဘာသာပြန်မှုတွင် ယေဘူယျသဘောတရားမှ စာကြောင်းနှစ်ကြောင်းကို ကျွန်ုပ်တင်ပြမည်ဖြစ်ပြီး ပိုမိုအသေးစိတ်သိရှိနိုင်သည် ဒီမှာ.

Clojure သည် DSL များကိုဖန်တီးရန်အတွက် ဆွဲဆောင်မှုရှိသောဘာသာစကားတစ်ခုဖြစ်သည်၊ သို့သော် SQL ကိုယ်တိုင်က အမိုက်စား DSL တစ်ခုဖြစ်ပြီး ကျွန်ုပ်တို့သည် နောက်ထပ်တစ်ခုမလိုအပ်ပါ။ S-အသုံးအနှုန်းများသည် ကောင်းမွန်သော်လည်း၊ ၎င်းတို့သည် ဤနေရာတွင် အသစ်အဆန်းများကို ထည့်မထားပါ။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် ကွင်းစကွင်းပိတ်များကို ထောက်၍ ကွင်းစကွင်းပိတ်များကို ရယူသည်။ သဘောမတူဘူးလား? ထို့နောက် ဒေတာဘေ့စ်ပေါ်ရှိ abstraction များ ပေါက်ကြားလာသည်နှင့် သင် function ကို စတင်တိုက်ခိုက်သည့်အချိန်ကို စောင့်ပါ။ (အကြမ်း-စတုရန်းမိုင်)

ဒါဆို ဘာလုပ်ရမလဲ။ SQL ကို ပုံမှန် SQL အဖြစ် ထားခဲ့ကြပါစို့ - တောင်းဆိုမှုတစ်ခုအတွက် ဖိုင်တစ်ခု။

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

... ထို့နောက် ဤဖိုင်ကိုဖတ်ပါ၊ ၎င်းကို ပုံမှန် Clojure လုပ်ဆောင်ချက်အဖြစ် ပြောင်းလဲပါ။

(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 ကို သူ့အလိုလို၊ သူ့ဘာသာသူ Clojure" နိယာမကို လိုက်နာခြင်းဖြင့်၊ သင်ရရှိသည်-

• Syntactic အံ့သြဖွယ်မရှိပါ။ သင်၏ဒေတာဘေ့စ် (အခြားမည်သည့်အရာများကဲ့သို့) သည် SQL စံနှုန်းနှင့် 100% မကိုက်ညီပါ - သို့သော် Yesql အတွက် အရေးမကြီးပါ။ SQL equivalent syntax ဖြင့် လုပ်ဆောင်ချက်များကို ရှာဖွေရာတွင် အချိန်ဖြုန်းမည်မဟုတ်ပါ။ လုပ်ဆောင်ချက်တစ်ခုသို့ သင်ဘယ်တော့မှ ပြန်သွားစရာ မလိုပါ။ (raw-sql "some('funky'::SYNTAX)")).
• အကောင်းဆုံးအယ်ဒီတာပံ့ပိုးမှု။ သင့်အယ်ဒီတာသည် ကောင်းမွန်သော SQL ပံ့ပိုးမှုရှိပြီးဖြစ်သည်။ SQL ကို SQL အဖြစ် သိမ်းဆည်းခြင်းဖြင့် ၎င်းကို ရိုးရိုးရှင်းရှင်း အသုံးပြုနိုင်သည်။
• အသင်းလိုက်လိုက်ဖက်မှု။ သင်၏ DBA များသည် သင်၏ Clojure ပရောဂျက်တွင် သင်အသုံးပြုသည့် SQL ကို ဖတ်နိုင်ပြီး ရေးနိုင်သည်။
• စွမ်းဆောင်ရည် ချိန်ညှိခြင်း ပိုမိုလွယ်ကူခြင်း။ ပြဿနာရှိသောမေးမြန်းမှုများအတွက် အစီအစဉ်တစ်ခုတည်ဆောက်ရန် လိုအပ်ပါသလား။ သင့်မေးမြန်းချက်သည် ပုံမှန် SQL ဖြစ်သောအခါ ၎င်းသည် ပြဿနာမဟုတ်ပါ။
• မေးခွန်းများကို ပြန်လည်အသုံးပြုခြင်း။ ၎င်းသည် ရိုးရိုး SQL ဟောင်းဖြစ်သောကြောင့် အခြားပရောဂျက်များထဲသို့ တူညီသော SQL ဖိုင်များကို ဆွဲယူ၍ချပါ - ၎င်းကိုမျှဝေပါ။

ကျွန်တော့်အမြင်အရတော့ အိုင်ဒီယာက အရမ်းမိုက်ပြီး ပရောဂျက်များစွာကို ရရှိခဲ့တဲ့အတွက်ကြောင့် တစ်ချိန်တည်းမှာ အလွန်ရိုးရှင်းပါတယ်။ နောက်လိုက်များ ဘာသာစကားအမျိုးမျိုးဖြင့်။ ထို့အပြင် ကျွန်ုပ်တို့သည် ORM ထက်ဝေးသော အခြားအရာများနှင့် SQL ကုဒ်ကို ပိုင်းခြားခြင်းဆိုင်ရာ အလားတူအတွေးအခေါ်ကို ကျင့်သုံးရန် ကြိုးစားပါမည်။

IDE နှင့် DB မန်နေဂျာများ

ရိုးရှင်းတဲ့နေ့စဉ်အလုပ်တစ်ခုနဲ့ စလိုက်ရအောင်။ မကြာခဏဆိုသလို ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်ရှိ အရာဝတ္ထုအချို့ကို ရှာဖွေရလေ့ရှိသည်၊ ဥပမာအားဖြင့်၊ ဇယားကွက်တစ်ခုကို ရှာပြီး ၎င်း၏ဖွဲ့စည်းပုံကို လေ့လာခြင်း (မည်သည့်ကော်လံများ၊ သော့များ၊ အညွှန်းများ၊ ကန့်သတ်ချက်များ၊ စသည်ဖြင့် အသုံးပြုကြသည်)။ ဂရပ်ဖစ် IDE သို့မဟုတ် DB-မန်နေဂျာအနည်းငယ်ထံမှ၊ ပထမဆုံးအနေဖြင့်၊ ကျွန်ုပ်တို့သည် ဤအရည်အချင်းများကို အတိအကျမျှော်လင့်ပါသည်။ ထို့ကြောင့် မြန်ဆန်ပြီး လိုအပ်သောအချက်အလက်များပါရှိသည့် ဝင်းဒိုးတစ်ခုအား (အထူးသဖြင့် အဝေးမှဒေတာဘေ့စ်သို့ နှေးကွေးသောချိတ်ဆက်မှုဖြင့်) ရေးဆွဲသည်အထိ နာရီဝက်စောင့်စရာမလိုဘဲ တစ်ချိန်တည်းမှာပင် ရရှိလာသော အချက်အလက်များသည် လတ်ဆတ်ပြီး ဆီလျော်မှုရှိ၊ အမှိုက်ပုံးများကို သိမ်းဆည်းထားခြင်း မရှိပါ။ ထို့အပြင်၊ ဒေတာဘေ့စ်ပိုမိုရှုပ်ထွေးလေ ပိုကြီးလေ၊ ၎င်းတို့အရေအတွက်များလေလေ၊ ဒါကိုလုပ်ဆောင်ရန် ပို၍ခက်ခဲလေဖြစ်သည်။

ဒါပေမယ့် များသောအားဖြင့် ကျွန်တော် mouse ကို လွှင့်ပစ်ပြီး ကုဒ်ရေးလိုက်ရုံပါပဲ။ "HR" schema တွင် မည်သည့်ဇယားများ (နှင့် မည်သည့် ဂုဏ်သတ္တိများ) ကို ရှာဖွေရန် လိုအပ်သည်ဆိုပါစို့။ DBMS အများစုတွင် information_schema မှ ဤရိုးရှင်းသောမေးမြန်းချက်ဖြင့် လိုချင်သောရလဒ်ကို ရနိုင်သည်-

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'

Oracle သည် information_schema ကို မသိသော်လည်း ၎င်းတွင်ရှိသည်။ Oracle metadata၊ ပြဿနာကြီးကြီးမားမားမပေါ်ပေါက်ပါ

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'

အလားတူတစ်ခုခုကို Cassandra တွင်လုပ်ဆောင်နိုင်သည် (ဇယားများနှင့် သော့ကွက်များအစား ကော်လံမိသားစုများပါရှိသည်)

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

အခြားသော ဒေတာဘေ့စ်အများစုအတွက်၊ အလားတူမေးခွန်းများ (Mongo ပင်လျှင်) ရှိလာနိုင်သည်။ အထူးစနစ်စုစည်းမှုစနစ်အတွင်းရှိ စုစည်းမှုအားလုံးနှင့်ပတ်သက်သည့် အချက်အလက်များပါ၀င်သည်)။

ဟုတ်ပါတယ်၊ ဤနည်းဖြင့် သင်သည် ဇယားများအကြောင်းသာမက ယေဘုယျအားဖြင့် မည်သည့်အရာဝတ္ထုနှင့်ပတ်သက်သည့် အချက်အလက်ကိုမဆို သင်ရနိုင်မည်ဖြစ်သည်။ အခါအားလျော်စွာ၊ ကြင်နာသူများသည် မတူညီသောဒေတာဘေ့စ်များအတွက် ထိုကုဒ်ကို မျှဝေကြသည်၊ ဥပမာ၊ habra ဆောင်းပါးစီးရီးများတွင် “PostgreSQL ဒေတာဘေ့စ်များကို မှတ်တမ်းတင်ရန်အတွက် လုပ်ဆောင်ချက်များ” (ဥပမာ၊Ayb, ဘင်, အားကစားရုံ) ဟုတ်ပါတယ်၊ ဒီမေးခွန်းတွေရဲ့ တောင်ကြီးတစ်ခုလုံးကို ငါ့ခေါင်းထဲမှာ ထားရှိပြီး အဲဒါတွေကို အဆက်မပြတ်ရိုက်ရတာက ကြည်နူးစရာပါပဲ၊ ဒါကြောင့် ငါအကြိုက်ဆုံး IDE/editor မှာ မကြာခဏ အသုံးပြုလေ့ရှိတဲ့ queries အတွက် ကြိုတင်ပြင်ဆင်ထားတဲ့ အတိုအထွာတွေ ရှိပြီး ကျန်တာတွေကတော့ စာရိုက်ဖို့ပါပဲ။ template ထဲသို့ အရာဝတ္ထုအမည်များ။

ရလဒ်အနေဖြင့်၊ အရာဝတ္ထုများကို သွားလာရှာဖွေခြင်းနှင့် ရှာဖွေခြင်းနည်းလမ်းသည် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ဖြစ်ပြီး အချိန်ကုန်သက်သာစေကာ ယခုလိုအပ်သည့်ပုံစံဖြင့် အချက်အလက်အတိအကျကို သင်ရနိုင်စေသည် (ဥပမာ၊ ပို့စ်တွင်ဖော်ပြထားသည့်အတိုင်း၊ "မည်သည့်ပုံစံဖြင့် ဒေတာဘေ့စ်မှဒေတာကို ထုတ်ယူခြင်း- IntelliJ ပလပ်ဖောင်းပေါ်တွင် IDE များ လုပ်ဆောင်နိုင်သည်").

အရာဝတ္ထုများနှင့် လုပ်ဆောင်မှုများ

လိုအပ်သော အရာဝတ္ထုများကို ရှာဖွေတွေ့ရှိပြီး လေ့လာပြီးနောက်၊ ၎င်းတို့နှင့် အသုံးဝင်သော အရာတစ်ခုကို ပြုလုပ်ရန် အချိန်တန်ပါပြီ။ ကီးဘုတ်မှ လက်ချောင်းများကို မဖြုတ်ဘဲ သဘာဝအတိုင်းပင်။

ဇယားတစ်ခုကို ဖျက်လိုက်ရုံဖြင့် databases အားလုံးနီးပါးတွင် တူညီနေမည်မှာ လျှို့ဝှက်ချက်မဟုတ်ပေ။

drop table hr.persons

ဒါပေမယ့် စားပွဲဖန်တီးမှုနဲ့အတူ ပိုစိတ်ဝင်စားဖို့ကောင်းလာပါတယ်။ မည်သည့် DBMS မဆို (NoSQL အများအပြားအပါအဝင်) သည် ပုံစံတစ်မျိုး သို့မဟုတ် အခြားတစ်ခုဖြင့် “ဇယားကိုဖန်တီးနိုင်သည်” နှင့် ၎င်း၏အဓိကအစိတ်အပိုင်းသည် အနည်းငယ် (အမည်၊ ကော်လံစာရင်း၊ ဒေတာအမျိုးအစားများ) ကွဲပြားသော်လည်း အခြားအသေးစိတ်အချက်အလက်များမှာ သိသိသာသာကွဲပြားနိုင်ပြီး ၎င်းပေါ်တွင်မူတည်သည်။ သီးခြား DBMS ၏ အတွင်းပိုင်း ကိရိယာနှင့် စွမ်းရည်များ။ ကျွန်တော်အကြိုက်ဆုံးဥပမာမှာ Oracle documentation တွင် "create table" syntax အတွက် "naked" BNFs များသာရှိသည်၊ 31 စာမျက်နှာကိုသိမ်းပိုက်. အခြား DBMS များတွင် အနည်းငယ်သာလွန်သော စွမ်းဆောင်ရည်များ ရှိသော်လည်း ၎င်းတို့တစ်ခုစီတွင် ဇယားများဖန်တီးရန်အတွက် စိတ်ဝင်စားစရာကောင်းပြီး ထူးခြားသောအင်္ဂါရပ်များစွာ ပါရှိသည်။နေပြည်တော်, mysql, ပိုးဟပ်, သရက်) အခြား IDE မှ ဂရပ်ဖစ် "မှော်ဆရာ" (အထူးသဖြင့် စကြဝဠာတစ်ခု) သည် ဤစွမ်းရည်အားလုံးကို အပြည့်အဝ လွှမ်းခြုံနိုင်လိမ့်မည်မဟုတ်ပေ၊ ၎င်းသည် တတ်နိုင်လျှင်ပင် ၎င်းသည် စိတ်မပျက်သူများအတွက် မြင်ကွင်းတစ်ခု ဖြစ်လာမည်မဟုတ်ပါ။ တစ်ချိန်တည်းမှာပင် မှန်မှန်ကန်ကန်နှင့် အချိန်နှင့်တစ်ပြေးညီ ရေးသားဖော်ပြထားပါသည်။ ဇယားဖန်တီးပါ။ ၎င်းတို့အားလုံးကို အလွယ်တကူ အသုံးပြုနိုင်ရန်၊ သိုလှောင်မှုနှင့် သင့်ဒေတာကို ယုံကြည်စိတ်ချရသော၊ အကောင်းဆုံးနှင့် တတ်နိုင်သမျှ သက်တောင့်သက်သာဖြစ်စေရန် ခွင့်ပြုမည်ဖြစ်သည်။

ထို့အပြင်၊ DBMS အများအပြားတွင် အခြား DBMS များတွင် မရရှိနိုင်သော သီးခြားအရာဝတ္ထုအမျိုးအစားများရှိသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်အရာဝတ္တုများပေါ်တွင်သာမက DBMS ကိုယ်တိုင်တွင်လည်း လုပ်ဆောင်မှုများကို လုပ်ဆောင်နိုင်သည်၊ ဥပမာအားဖြင့်၊ လုပ်ငန်းစဉ်တစ်ခုကို "သတ်ပစ်ရန်"၊ မန်မိုရီဧရိယာအချို့ကို ဖယ်ရှားပေးခြင်း၊ ခြေရာခံခြင်းကို ဖွင့်ခြင်း၊ "ဖတ်ရန်သာ" မုဒ်သို့ ပြောင်းခြင်းနှင့် အခြားအရာများစွာကို လုပ်ဆောင်နိုင်ပါသည်။

အခုနည်းနည်းဆွဲကြည့်ရအောင်

အသုံးအများဆုံးအလုပ်များထဲမှတစ်ခုမှာ ဒေတာဘေ့စ်အရာဝတ္တုများပါရှိသော မြေပုံတစ်ခုတည်ဆောက်ရန်နှင့် ၎င်းတို့ကြားရှိ အရာဝတ္ထုများနှင့် ချိတ်ဆက်မှုများကို လှပသောရုပ်ပုံဖြင့်ကြည့်ရှုရန်ဖြစ်သည်။ ဂရပ်ဖစ် IDE၊ သီးခြား "command line" utilities၊ အထူးပြု ဂရပ်ဖစ်ကိရိယာများနှင့် မော်ဒယ်လ်များ နီးပါးသည် ၎င်းကို လုပ်ဆောင်နိုင်သည်။ ၎င်းတို့သည် သင့်အတွက် "တတ်နိုင်သလောက်" တစ်ခုခုကို ဆွဲပေးမည်ဖြစ်ပြီး၊ ဖွဲ့စည်းမှုဖိုင် သို့မဟုတ် အင်တာဖေ့စ်ရှိ အမှတ်ခြစ်ကွက်များတွင် ပါရာမီတာအနည်းငယ်၏အကူအညီဖြင့် ဤလုပ်ငန်းစဉ်ကို အနည်းငယ်လွှမ်းမိုးနိုင်သည်။

ဒါပေမယ့် ဒီပြဿနာကို ကုဒ်ရဲ့အကူအညီနဲ့ အများကြီး ရိုးရှင်းစွာ ဖြေရှင်းနိုင်ပါတယ်။ မည်သည့်ရှုပ်ထွေးမှု၏ ပုံချပ်များကို ဖန်တီးရန်အတွက်၊ ကျွန်ုပ်တို့တွင် အထူးပြု markup ဘာသာစကားများစွာ (DOT၊ GraphML စသည်) ရှိပြီး ၎င်းတို့အတွက် ထိုညွှန်ကြားချက်များကို ဖတ်ရှုပြီး ဖော်မက်အမျိုးမျိုးဖြင့် မြင်ယောင်နိုင်သော အပလီကေးရှင်းတစ်ခုလုံး (GraphViz၊ PlantUML၊ Mermaid) ရှိသည်။ . ကောင်းပြီ၊ ၎င်းတို့ကြားရှိ အရာဝတ္ထုများနှင့် ချိတ်ဆက်မှုများအကြောင်း သတင်းအချက်အလက်များ မည်သို့ရယူရမည်ကို ကျွန်ုပ်တို့ သိထားပြီးဖြစ်သည်။

ဤသည်မှာ PlantUML နှင့် အသုံးပြု၍ ၎င်းသည် မည်သို့မည်ပုံဖြစ်နိုင်သည်ဟူသော နမူနာလေးတစ်ခုဖြစ်သည်။ PostgreSQL အတွက်သရုပ်ပြဒေတာဘေ့စ် (ဘယ်ဘက်တွင် PlantUML အတွက်လိုအပ်သောညွှန်ကြားချက်ကိုထုတ်ပေးမည့် SQL query တစ်ခုဖြစ်ပြီးညာဘက်တွင်ရလဒ်ဖြစ်သည်) ။

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 diagram နှင့် အလွန်ဆင်တူသောအရာကို သင်ရနိုင်သည်-

SQL query သည် အနည်းငယ် ပိုရှုပ်ထွေးသည်။

-- Шапка
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'

အနီးကပ်ကြည့်မည်ဆိုလျှင် ဘောင်အောက်တွင် စိတ်ကူးပုံဖော်ခြင်းကိရိယာများစွာသည်လည်း အလားတူမေးမြန်းချက်များကို အသုံးပြုပါသည်။ မှန်ပါသည်၊ ဤတောင်းဆိုမှုများသည် များသောအားဖြင့် လေးနက်သည်။ အပလီကေးရှင်း၏ကုဒ်ထဲသို့ “hardwired” သည် နားလည်ရခက်သည်။၎င်းတို့ကို မည်သည့် ပြုပြင်မွမ်းမံမှုဟု မဆိုလိုပါ။

မက်ထရစ်များနှင့် စောင့်ကြည့်ခြင်း။

အစဉ်အလာအားဖြင့် ရှုပ်ထွေးသော အကြောင်းအရာတစ်ခုသို့ ဆက်သွားကြပါစို့ - ဒေတာဘေ့စ် စွမ်းဆောင်ရည် စောင့်ကြည့်ခြင်း။ “သူငယ်ချင်းတစ်ယောက်” က ကျွန်တော့်ကို ပြောပြတဲ့ ဖြစ်ရပ်မှန်လေးတစ်ခုကို သတိရမိပါတယ်။ အခြားပရောဂျက်တစ်ခုတွင် အားကောင်းမောင်းသန် DBA တစ်ခုရှိ၍ developer အနည်းငယ်က သူ့ကို ကိုယ်တိုင်ကိုယ်ကျ သိကြပြီး၊ သို့မဟုတ် လူကိုယ်တိုင် မြင်ဖူးသည် (ကောလဟာလအရ၊ သူသည် နောက်ထပ် အဆောက်အအုံတွင် အလုပ်လုပ်နေသော်လည်း)။ “X” နာရီတွင်၊ လက်လီရောင်းချသူကြီးများ၏ အရောင်းအ၀ယ်စနစ်သည် တစ်ဖန် “ဆိုးရွား” လာသောအခါတွင် Oracle Enterprise Manager ထံမှ ဂရပ်ဖစ်ပုံများကို တိတ်တဆိတ်ပေးပို့ပြီး “နားလည်နိုင်မှု” အတွက် အနီရောင်အမှတ်အသားဖြင့် အရေးကြီးသောနေရာများကို ဂရုတစိုက် မီးမောင်းထိုးပြခဲ့သည် ( ဒါကို ပေါ့ပေါ့ပါးပါး ထားဖို့က အများကြီး မကူညီခဲ့ဘူး)။ ပြီးတော့ ဒီ "ဓာတ်ပုံကတ်" ကို အခြေခံပြီး ကျွန်မ ကုသခဲ့ရတယ်။ တစ်ချိန်တည်းမှာပင်၊ အဘယ်ကြောင့်ဆိုသော် Enterprise Manager သည် အဖိုးတန်သော (စကားလုံး၏ အာရုံနှစ်ရပ်လုံးတွင်) ရတနာကို မည်သူမျှ သုံးစွဲခွင့်မရခဲ့ပေ။ စနစ်သည် ရှုပ်ထွေးပြီး စျေးကြီးသည်၊ ရုတ်တရက် "ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် တစ်ခုခုကို ထိမိ၍ အရာအားလုံးကို ချိုးဖျက်သည်" ထို့ကြောင့်၊ developer များသည် ဘရိတ်များ၏တည်နေရာနှင့် အကြောင်းရင်းကို "မျက်မြင်ကိုယ်တွေ့" တွေ့ရှိပြီး patch တစ်ခုကို ထုတ်ပြန်ခဲ့သည်။ မဝေးတော့သောအနာဂတ်တွင် DBA မှ ခြိမ်းခြောက်စာတစ်စောင် ထပ်မံရောက်ရှိမလာပါက လူတိုင်း သက်ပြင်းချ၍ ၎င်းတို့၏ လက်ရှိတာဝန်များ (ပေးစာအသစ်အထိ) သို့ ပြန်သွားကြမည်ဖြစ်သည်။

သို့သော် စောင့်ကြည့်ရေးလုပ်ငန်းစဉ်သည် ပိုမိုပျော်စရာကောင်းပြီး ဖော်ရွေစွာကြည့်ရှုနိုင်ကာ အရေးအကြီးဆုံးမှာ လူတိုင်းအတွက် ဝင်ရောက်အသုံးပြုနိုင်ပြီး ပွင့်လင်းမြင်သာမှုဖြစ်သည်။ ပင်မစောင့်ကြည့်ရေးစနစ်များ (အမှန်တကယ်အသုံးဝင်ပြီး များစွာသောကိစ္စများတွင် အစားထိုး၍မရသော) အပိုတစ်ခုအနေဖြင့် ၎င်း၏အခြေခံအစိတ်အပိုင်း အနည်းဆုံးဖြစ်သည်။ မည်သည့် DBMS မဆို ၎င်း၏ လက်ရှိအခြေအနေနှင့် စွမ်းဆောင်ရည်ဆိုင်ရာ အချက်အလက်များကို မျှဝေရန် လွတ်လပ်စွာ အခမဲ့ဖြစ်သည်။ တူညီသော “သွေးစွန်းသော” Oracle DB တွင်၊ လုပ်ငန်းစဉ်များနှင့် ဆက်ရှင်များမှ ကြားခံကက်ရှ်အခြေအနေအထိ စနစ်ကြည့်ရှုမှုများမှ စွမ်းဆောင်ရည်နှင့်ပတ်သက်သည့် အချက်အလက်အားလုံးနီးပါးကို ရရှိနိုင်ပါသည်။ (ဥပမာ၊ DBA Scriptsအပိုင်း "စောင့်ကြည့်လေ့လာရေး")။ Postgresql သည် စနစ်အမြင်များစွာလည်း ရှိသည်။ ဒေတာဘေ့စ်စောင့်ကြည့်ရေးအထူးသဖြင့် DBA ၏နေ့စဉ်ဘဝတွင် မရှိမဖြစ်လိုအပ်သော အရာများ၊ pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL တွင် ဤအတွက် သီးခြား schema တစ်ခုရှိသည်။ Performance_schema. Mongo တွင် တပ်ဆင်ထားသော A ပရိုဖိုင်း စွမ်းဆောင်ရည်ဒေတာကို စနစ်စုစည်းမှုအဖြစ် စုစည်းသည်။ system.profile.

ထို့ကြောင့် စိတ်ကြိုက် sql queries များကိုလုပ်ဆောင်နိုင်သော မက်ထရစ်စုဆောင်းသူ (Telegraf၊ Metricbeat၊ Collectd) ၊ ဤမက်ထရစ်များ သိုလှောင်မှု (InfluxDB၊ Elasticsearch၊ Timescaledb) နှင့် visualizer (Grafana၊ Kibana) တို့ကို သင်ရနိုင်သည် ။ နှင့် အခြားစနစ်တစ်ခုလုံး မက်ထရစ်များ (ဥပမာ၊ အပလီကေးရှင်းဆာဗာမှ၊ OS မှရရှိသော စသည်ဖြင့်) နှင့် အနီးကပ်ပေါင်းစည်းမည့် ပြောင်းလွယ်ပြင်လွယ် စောင့်ကြည့်ရေးစနစ်။ ဥပမာအားဖြင့်၊ ၎င်းကို InfluxDB + Grafana ပေါင်းစပ်မှုနှင့် စနစ်ကြည့်ရှုမှုများအတွက် မေးမြန်းချက်အစုံကို အသုံးပြုသည့် pgwatch2 တွင် လုပ်ဆောင်သည်၊ စိတ်ကြိုက်မေးခွန်းများကိုထည့်ပါ။.

စုစုပေါင်း

၎င်းသည် ပုံမှန် SQL ကုဒ်ကို အသုံးပြု၍ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်တွင် လုပ်ဆောင်နိုင်သည့် အနီးစပ်ဆုံးစာရင်းတစ်ခုမျှသာဖြစ်သည်။ နောက်ထပ်အသုံးပြုမှုများစွာကို သင်တွေ့နိုင်မည်ဟု ယုံကြည်ပါသည်၊ comment တွင်ရေးပါ။ ထို့အပြင် ဤအရာအားလုံးကို အလိုအလျောက်ပြန်လုပ်နည်း (နှင့် အရေးကြီးဆုံးမှာ အဘယ်ကြောင့်) အကြောင်းနှင့် ၎င်းကို သင်၏ CI/CD ပိုက်လိုင်းတွင် နောက်တစ်ကြိမ် ထည့်သွင်းရန် ဆွေးနွေးပါမည်။

source: www.habr.com