If you're seeing this message, it means we're having trouble loading external resources on our website.

Եթե գտնվում ես վեբ զտիչի հետևում, խնդրում ենք համոզվել, որ *.kastatic.org և *.kasandbox.org տիրույթները հանված են արգելափակումից։

Հիմնական նյութ

Ավելի ապահով դարձրու քո SQL-ը

SQL-ը կարող է շատ գեղեցիկ բան լինել, սակայն այն կարող է նաև վտանգավոր լինել։ Եթե SQL-ով փորձում ես աշխատել հարյուրների կամ հազարների կողմից օգտագործված տվյալների բազայի հետ, պետք է առավելագույնս զգույշ լինես, որովհետև կարող ես պատահմամբ վնասել կամ ջնջել այդ բազայի տվյալները։ Այնուամենայնիվ, գոյություն ունեն տարբեր մեթոդներ, որոնք հնարավորություն են տալիս քո SQL-ն ավելի ապահով և անվտանգ դարձնել։

Խուսափել վատ update-ներից ու delete-ներից

Նախքան UPDATE հրամանն օգտագործելը տուր SELECT հրամանը նույն WHERE-ով, որպեսզի վստահ լինես, որ ճիշտ տողը կամ սյունն ես ընտրել։
Օրինակ՝ մինչև այս կոդն աշխատեցնելը․
UPDATE users SET deleted = true WHERE id = 1;
Աշխատեցրու սա․
SELECT id, deleted FROM users WHERE id = 1;
Մինչև update հրամանն օգտագործելը կարող ես նաև կոդիդ LIMIT ավելացնել, որպեսզի վստահ լինես, որ պատահմամբ անթիվ-անհամար տողեր չես փոխի․
UPDATE users SET deleted = true WHERE id = 1 LIMIT 1;
Կամ եթե ջնջում ես․
DELETE users WHERE id = 1 LIMIT 1;

Գործարքների կիրառում

Երբ օգտագործում ենք SQL հրաման, որն ինչ-որ ձևով փոխում է մեր տվյալների բազան, դա անվանում ենք գործարք։ Գործարքը գործողությունների հաջորդականություն է, որը հասկացվում է որպես մեկ ամբողջական գործողություն (ինչպես բանկի գործարքը), և տվյալների բազաների աշխարհում գործարքն ապահովության համար պետք է համապատասխանի «ACID» սկզբունքներին։
Երբ գրում ենք CREATE, UPDATE, INSERT կամ DELETE հրամաններից մեկը, ինքնաբերաբար սկսում ենք գործարք։ Սակայն ցանկության դեպքում կարող ենք մի քանի հրաման գրել մեկ գործարքի մեջ։ Սա այն դեպքերում է պետք գալիս, երբ մեզ, օրինակ, պետք է UPDATE-ով անցնել UPDATE-ի վրայով, հետևաբար մենք պետք է դրանք դնենք նույն գործարքի ներսում։
Այս դեպքում պետք է մեր հրամանները ծածկենք BEGIN TRANSACTION և COMMIT հրամաններով․
BEGIN TRANSACTION;
UPDATE people SET husband = "Winston" WHERE user_id = 1;
UPDATE people SET wife = "Winnefer" WHERE user_id = 2;
COMMIT;
Եթե տվյալների բազան չի կարողանում կատարել այդ երկու UPDATE հրամանները, այն կչեղարկի գործարքն ու կթողնի տվյալների բազան այնպես, ինչպես մինչ այդ էր։
Մենք նաև օգտագործում ենք գործարքներ, երբ ուզում ենք վստահ լինել, որ բոլոր հրամանները նույն տվյալների վրա են աշխատում, և ուզում ենք վստահ լինել, որ ոչ մի ուրիշ գործարք չի աշխատում նույն տվյալների վրա այն ժամանակ, երբ հրամաններն աշխատում են։ Երբ նայում ես հրամանների հաջորդականությանը, որ ուզում ես աշխատեցնել, ինքդ քեզ հարցրու, թե ինչ կլինի, եթե մեկ այլ օգտատեր նույն ժամանակ հրամաններ աշխատեցնի։ Քո տվյալները կարող են տարօրինակ տեսք ստանալ։ Այս դեպքում պետք է այն աշխատեցնես գործարքի մեջ։
Օրինակ՝ այս հրամանները ստեղծում են տող, որտեղ գրված է, որ օգտատերը ստացել է կրծքանշան և թարմացնում է օգտատիրոջ տվյալները․
INSERT INTO user_badges VALUES (1, "SQL Master", "4pm");
UPDATE user SET recent_activity = "Earned SQL Master badge" WHERE id = 1;
Միևնույն ժամանակ օգտատերը ստանում է մեկ այլ կրծքանշան․
INSERT INTO user_badges VALUES (1, "Great Listener", "4:05pm");
UPDATE user SET recent_activity = "Earned Great Listener badge" WHERE id = 1;
Այս հրամանները կարող են հիմա այսպես դասավորվել․
INSERT INTO user_badges VALUES (1, "SQL Master");
INSERT INTO user_badges VALUES (1, "Great Listener");
UPDATE user SET recent_activity = "Earned Great Listener badge" WHERE id = 1;
UPDATE user SET recent_activity = "Earned SQL Master badge" WHERE id = 1;
Նրա վերջին տվյալը հիմա կլինի «Earned SQL Master badge» նույնիսկ, եթե ամենավերջին ստացած կրծքանշանը լինի «Great listener»-ը։ Դա, իհարկե, աշխարհի վերջը չէ, բայց հավանաբար մեր ուզածն էլ չէ։
Փոխարենը կարող ենք դրանք աշխատեցնել գործարքի մեջ, որպեսզի վստահ լինենք, որ ընթացքում ոչ մի ուրիշ գործարք չի լինի․
BEGIN TRANSACTION;
INSERT INTO user_badges VALUES (1, "SQL Master");
UPDATE user SET recent_activity = "Earned SQL Master badge" WHERE id = 1;
COMMIT;

Ստեղծել կրկնօրինակումներ

Հնարավոր է, որ հետևես բոլոր ցուցումներին, բայց, այնուամենայնիվ, մի ինչ-որ վրիպում թույլ տաս։ Դրա համար շատ ընկերություններ ստեղծում են իրենց տվյալների բազաների կրկնօրինակներ, որոնք թարմացվում են ամեն ժամվա, ամեն օրվա կամ ամեն շաբաթվա կտրվածքով՝ կախված տվյալների բազայի չափսից։ Երբ ինչ-որ վատ բան է լինում, նրանք կարող են հին տվյալների բազայից ներմուծել տվյալները բոլոր վնասված կամ կորած աղյուսակների մեջ։ Այս դեպքում տվյալները կարող են մի փոքր հին լինել, բայց այդ տվյալները ավելի լավ են, քան ոչինչը։

Կրկնություն

Նմանօրինակ մոտեցում է կրկնությունը՝ տվյալների բազայի մի քանի օրինակներ տարբեր տեղերում պահեստավորելը։ Եթե ինչ-ինչ պատճառներով ինչ-որ կրկնօրինակը հասանելի չէ (օրինակ՝ կայծակը խփել է այն շենքին, որի ներսում կրկնօրինակն է), ապա հարցումը կարող է ուղարկվել տվյալների բազայի մեկ այլ կրկնօրինակի մոտ, որը, հուսանք, հասանելի կլինի։ Եթե տվյալները շատ կարևոր են, պետք է մի քանի կրկնօրինակ ունենան, որպեսզի խուսափենք դրանք կորցնելու վտանգից։ Օրինակ, եթե բժիշկը փորձում է հիվանդի ալերգիաների ցուցակ ունենալ, որպեսզի հասկանա, թե ինչպես պետք է բուժել արտակարգ իրավիճակի ժամանակ, նա չի կարող սպասել, մինչև ինժեներները տվյալները հանեն կրկնօրինակված բազայից, բժիշկին այդ տվյալները շտապ են պետք։
Այնուամենայնիվ, ավելի շատ ջանք կպահանջվի տվյալների բազաներ կրկնօրինակելու համար, և շատ հաճախ կհանգեցնի ավելի դանդաղ աշխատելուն, քանի որ գրող գործողություններ պետք է աշխատեն բոլորի ներսում։ Դրա համար ընկերությունները պետք է որոշեն, թե արդյոք հարկավոր է կրկնօրինակել տվյալները, և հասկանան այն օգտագործելու լավագույն եղանակը։

Տալ արտոնություններ

Շատ տվյալների բազաների համակարգեր որոշակի արտոնություններով օգտատերեր ունեն, որովհետև դրանք պահեստավորված են սերվերի մեջ և հասանելի են այլ օգտատերերի համար։ «Քան» ակադեմիայի SQL-ում չկա օգտատեր/արտոնություն գաղափարը, որովհետև SQLite-ն օգտագործվում է մեկ օգտատեր սցենարով, և հետևաբար կարող ես այդտեղ գրել, ինչ կկամենաս այնքան ժամանակ, ինչքան թույլտվություն կունենաս։
Բայց եթե մի օր աշխատես տվյալների բազայի հետ համօգտագործվող սերվերում, հենց ամենասկզբից պետք է օգտատերերին ինչ-որ արտոնություններ տաս։ Որպես ընդհանուր կանոն՝ միշտ հիշիր, որ միայն մի քանի օգտատիրոջ կարող ես տվյալների բազայի արտոնություններ տալ (օրինակ՝ քեզ հետ աշխատող ինժեներներին), քանի որ սխալ մարդու ձեռքում տվյալների բազան կարող էվտանգավոր փոփոխությունների ենթարկվել։
Օրինակ՝ ահա, թե ինչպես կարող ենք ինչ-որ օգտատիրոջ ամբողջական հասանելիություն տալ․
GRANT FULL ON TABLE users TO super_admin;
Ահա, թե ինչպես կարող ենք մեկ այլ օգտատիրոջ տալ միայն SELECT օգտագործելու հնարավորություն․
GRANT SELECT ON TABLE users TO analyzing_user;
Մեծ ընկերությունում դու երբեմն նույնիսկ չես էլ ուզենա օգտատիրոջը SELECT-ի հնարավորություն տալ, որովհետև բազան կարող է գաղտնի տվյալներ ունենալ, օրինակ՝ օգտատիրոջ էլ․ փոստը կամ անունը։ Շատ ընկերություններ ունեն իրենց տվյալների բազաների անանուն տարբերակները, որոնց վրա կարող են հարցումներ կատարել՝ առանց անհանգստանալու, որ ինչ-որ մեկը գաղտնի տեղեկություն կտեսնի։
Բոնուս: Տես այս հայտնի XKCD ծաղրանկարը ավելի ապահով SQL-ի մասին (նաև այս բացատրությունը

Ուզո՞ւմ ես միանալ խոսակցությանը։

Առայժմ հրապարակումներ չկան։
Անգլերեն հասկանո՞ւմ ես: Սեղմիր այստեղ և ավելի շատ քննարկումներ կգտնես «Քան» ակադեմիայի անգլերեն կայքում: