Creating Other Schema Objects – AbdulAli Personal Blog

Salam, Bloguma xoş gəlmisiniz!

Bu yazımda sizlərə bir neçə baza obyektlərinin yaradılması və üzərində dəyişiklik edilməsi haqqında yazacağam. Yazımız əsasən bu baza obyektlərindən ibarət olacaq: VIEW, SEQUENCES , INDEX, SYNONYMS.

Sıra ilə hər biri haqqında geniş məlumat verməyə çalışacağam.

VIEW

View-lar adlandırılmış və bazada daimi saxlanılan SELECT sorğulardır. Keçən yazımızda alt sorğuları WITH ilə adlandırmağı görmüşdüy ancaq bu adlar sadəcə yazdığımız kod daxilində keçərli idi, view-lar isə verilmiş ad ilə bazada saxlanılan baza oyektləridir.

View-lar yarandıqdan sonra eynilə cədvəl kimi davranırlar ancaq cədvəl deyildirlər və ümumilikdə heç bir məlumat saxlamırlar yalnız və yalnız adlandırılmış SELECT sorğulardır.

View-lar nə zaman yararlı olur bəs? Misallarla izah edim bunu:

Böyük bir cədvəliniz olduğunu düşünün, bu cədvəlin bəzi sütunlarındakı məlumatlara heç kimin müdaxilə etməsini istəmirsiniz digər sütunlara isə normal hər kəs müdaxilə edə bilər. Bu zaman hərkəsin müdaxilə edə biləcəyi sütunlardakı məlumatlardan ibarət bir view yaradırsınız və bu view-a istifadəçiləriniz üçün lazımi olan imtiyazları verirsiniz və beləcə cədvəlinizdəki digər məlumatlara istifadəçilər mudaxilə edə bilmir.

Bir digər yararlı olan yanı isə kompleks join-lər yazdığımız zaman bizi uzun-uzadı SELECT yazmaqdan qurtarır.

İndi isə view-ların necə yaradıldığına baxaq.

“EMPLOYEES” cədvəlimizdən istifadə edək.

CREATE VIEW VW_EMPLOYEES AS

SELECT EMPLOYEE_ID, LAST_NAME, FIRST_NAME, PRIMARY_PHONE

FROM EMPLOYEES;

Qeyd: Unutmamız gərəkən bir nüans var ki, eyni schema daxilində cədvəl və view adları eyni ola bilməz. Bu haqda buradan daha geniş oxuya bilərsiniz.

DESC əmri ilə yaratdığımız view-un strukturuna axa bilərik.

DESC VW_EMPLOYEES;

Name Null Type

———————————— ——————— ————-

EMPLOYEE_ID NOT NULL NUMBER

LAST_NAME VARCHAR2(30)

FIRST_NAME VARCHAR2(20)

PRIMARY_PHONE VARCHAR2(20)

View yaradarkən ümumi sintaksisə əməl etmək lazımdır.

CREATE VIEW mütləqdir
OR REPLACE əlavədir
View-nun adı baza oyektlərini adlandırma qaydalarına uyğun olmalıdır.
AS mütləqdir
Sonda isə düzgün(həm sintaksis həm məntiqi cəhətdən) SELECT sorğusu olmalıdır.

Qeyd: Bir digər diqqət etməli olduğumuz nöqtə isə view yaratdıqda SELECT hissəsində sütun adlarıdır, əgər sütunlarda hər hansı funksiya və hər hansı əməliyyat varsa o sütunlara mütləq alians verilməlidir və ya CREATE VIEW hissəsində sütunların adları qeyd olunmaldır əks təqdirdə xəta alacaqsınız. Aşağıdaki kimi:

CREATE OR REPLACE VIEW VW_EMPLOYEES AS

SELECT EMPLOYEE_ID,

LAST_NAME || ‘, ‘ || FIRST_NAME,

PRIMARY_PHONE

FROM EMPLOYEES;

Nəticə:

Error starting at line 1 in command:

CREATE OR REPLACE VIEW VW_EMPLOYEES AS

SELECT EMPLOYEE_ID,

LAST_NAME || ‘, ‘ || FIRST_NAME,

PRIMARY_PHONE

FROM EMPLOYEES

Error at Command Line:3 Column:33

Error report:

SQL Error: ORA-00998: must name this expression with a column alias

Həll yolları:

(1)

CREATE OR REPLACE VIEW VW_EMPLOYEES AS

SELECT EMPLOYEE_ID,

LAST_NAME || ‘, ‘ || FIRST_NAME EMP_FULL_NAME,

PRIMARY_PHONE

FROM EMPLOYEES;

(2)

CREATE OR REPLACE VIEW VW_EMPLOYEES (ID, NAME, PHONE) AS

SELECT EMPLOYEE_ID,

LAST_NAME || ‘, ‘ || FIRST_NAME EMP_NAME,

PRIMARY_PHONE

FROM EMPLOYEES;

Yenilənə bilən VIEW-lar

Yaratdığımız view-dan cədvəllərdə olduğu kimi SELECT edə bilərik bəs digər DML(INSERT, DELETE, UPDATE) ifadələri view-lar üzərinda istifadə edəbilərikmi? Əgər DML ifadə ilə view-nu yaratdığımız cədvəlin heç bir constraint-ini pozmuruqsa DML ifadələri(cədvəlin constraint-lərindən asılı olaraq bəzən tamamını, bəzən sadəcə bəzilərini) view-larda istifadə edə bilərik, əks təqdirdə istifadə edə bilmərik.

Məs: Employees cədvəlinə baxaq və bu cədvəl əsasında bir view yaradıb ona məlumat daxil edək görək nə nəticə alacağıq.

VIEW yaradaq:

CREATE OR REPLACE VIEW EMP_PHONE_BOOK

AS SELECT LAST_NAME, FIRST_NAME, PRIMARY_PHONE FROM EMPLOYEES;

SELECT ilə view-dakı məlumatlara baxaq.

SELECT LAST_NAME,

FIRST_NAME,

PRIMARY_PHONE

FROM EMP_PHONE_BOOK

ORDER BY LAST_NAME, FIRST_NAME;

View-a yeni sətir əlavə edək.

INSERT INTO EMP_PHONE_BOOK (LAST_NAME, FIRST_NAME, PRIMARY_PHONE)

VALUES (‘Abdulali’, ‘Aliyev’, ‘0994515534149’);

Nəticə:

Error starting at line 1 in command:

INSERT INTO EMP_PHONE_BOOK (LAST_NAME, FIRST_NAME, PRIMARY_PHONE)

VALUES (‘Abdulali’, ‘Aliyev’, ‘0994515534149’)

Error report:

SQL Error: ORA-01400: cannot insert NULL into (“EFCODD”.”EMPLOYEES”.”EMPLOYEE_ID”)

01400. 00000 – “cannot insert NULL into (%s)”

Qeyd: EMPLOYEES cədvəlinin strukturuna baxdığımız zaman görürük ki, EMPLOYEE_ID primary key constrainti ilə təyin olunub yəni həm NOT NULL həm UNIQUE-dir və belə olan halda bu sütun boş buraxıla bilməz, biz isə view-ya INSERT edərkən bu sütunu boş buraxdıq deyə bu xətanı aldıq. Yadda saxlamaq lazımdır ki, view-lar ayrıca cədvəllər deyildirlər, onlara məlumat daxil etmək, onların aid olduğu cədvələ məlumat daxil etmək deməkdir.

Gördüyümüz kimi INSERT xəta verdi ancaq UPDATE heç bir xəta verməyəcək:

UPDATE EMP_PHONE_BOOK

SET PRIMARY_PHONE = ‘202-555-1212’

WHERE LAST_NAME = ‘Hoddlestein’

AND FIRST_NAME = ‘Howard’;

Bu hallarda view-lar üzərində DML ifadələri(SELECT xaric) istifadə edə bilməzsiniz:

View hansı cədvəl əsasında yaradılmışsa o cədvəlin constraintlərinin pozulması zamanı
View yaradılarkən sorğuda GROUP BY və ya aqreqat funksiyalar, iyerarxik sorğular istifadə edildikdə
DISTINCT istifadə olunduğu zaman
SELECT zamanı FROM hissəsində 1-dən çox cədvəl istifadə olunduqda qısaca subquery və join-lərdən istifadə edildikdə

RECOMPILE VIEW

View yaradıldaq sonra aid olduğu cədvəldə dəyişiklik edildiyi zaman həmin view-un statusu “invalid” olaraq dəyişilir və data dictionary-də saxlanılır. İnvalid olan view-larınıza bu sorğu ilə baxa bilərsiniz:

SELECT object_type, object_name

FROM user_objects

WHERE object_type=’VIEW’ and status = ‘INVALID’

ORDER BY object_type, object_name;

Statusu “INVALID” olan view-larınızı “ALTER VIEW view_name COMPILE” yazaraq yenidən statusu “VALID” hala gətirə bilərsiniz.

Qeyd: View yaradıldıqdan sonra view-un aid olduğu cədvəldə sütun adı dəyişdirilib və ya sütun drop edilibsə bu zaman “ALTER VIEW view_name COMPILE” işinizə yaramayacaq, həmin view drop edilib yenidən yaradılmalıdır. Həmçinin view yaratdıqdan sonra SELECT sorğusunda dəyişiklik etmək istəsəniz bunu view-nu drop edi yenidən yaratmaqla etməlisiniz “ALTER VIEW” işinizə yaramayacaq.

SEQUENCE-lər

Sequence-lər əsasən cədvəllərdəki primary key constraint-ne aid sütunlara avtomatik və unikal qiymət vermək üçün istifadə olunur.

Ümumi sintaksisi bu şəkildədir:

CREATE SEQUENCE sequence_name sequence_options;

Sequence_name – yaradacağımız sequence-in adıdır, ümumi baza oyektlərini adlandırma qaydalarına uyğun olmalıdır.

Sequence_options – yaratmış olduğumuz sequence-in necə artacağını təyin edir. Aşağıdakı parametrlərə sahibdir:

INCREMENT BY integer – sequence-in qiymətini hər dəfə integer qədər artıracaq. Mənfi ədəd verilərsə o zaman sequence azalan formada işləyəcək. Əgər bu parametr yazılmazsa sequence susmaya görə hər dəfə 1 vahid artacaq.
START WITH integer – Sequence-in başlayacağı ilkin qiyməti bildirir.Əgər bu parametr yazılmazsa susmaya görə artan sequence-lər üçün MINVALUE, azalan sequence-lər üçün MAXVALUE-a bərabərdir.
MAXVALUE integer – Sequence üçün maksimum qiyməti təyin edir.Yazılmazsa avtomatik NOMAXVALUE dəyərini alır.
NOMAXVALUE – MAXVALUE –un olmadığını bildirir.
MINVALUE integer – sequence üçün minimum qiyməti təyin edir. Yazılmazsa NOMINVALUE dəyərini alır.
NOMINVALUE – MINVALUE –un olmadığını bildirir.
CYCLE – Sequence onun üçün təyin olunmuş aralıqlardan hər hansı birinə çatdıqda digər tərəfdən başdan davam etməsi üçündür.Məsələn davamlı artan sequence MAXVALUE-a çatdığı zaman növbəti qiymət MINVALUE olacaq, davamli azalan sequence isə əksinə MINVALUE-a çatdığı zaman növbəti qiymət MAXVALUE olacaq.
NOCYCLE – Sequence onun üçün təyin olunmuş aralıqlardan hər hansı birinə çatdıqda dayanır. Susmaya görə NOCYCLE parametric təyin olunur.

SEQUENCE-lərin istifadəsi

Həmən bir misal göstərim 🙂

INSERT INTO ORDERS (ORDER_ID, ORDER_DATE, CUSTOMER_ID) VALUES (SEQ_ORDER_ID.NEXTVAL, SYSDATE, 28);

Yaratdığımız sequence-lərin hər zaman 2 psevdosütunu vardır.

NEXTVAL

CREATE SEQUENCE –də təyin etdiyiniz sequence_option-a uyğun olaraq sequence-in yaratdığı növbəti qiymətdir.

CURRVAL

Sequence-in cari saxladığı qiymətdir. CURRVAL sessiya daxilində NEXTVAL olmadan və ya NEXTVAL-dan əvvəl çağırıla bilməz.

CURRVAL-ın bir biri ilə primary key-foreign key əlaqəsində olan cədvəllər arasında işimizə yarayan sintaksisinə baxaq.

INSERT INTO CRUISE_CUSTOMERS

(CRUISE_CUSTOMER_ID, FIRST_NAME, LAST_NAME)

VALUES

(SEQ_CRUISE_CUSTOMER_ID.NEXTVAL, ‘Joe’, ‘Schmoe’);

INSERT INTO CRUISE_ORDERS

(CRUISE_ORDER_ID, ORDER_DATE, CRUISE_CUSTOMER_ID)

VALUES

(SEQ_CRUISE_ORDER_ID.NEXTVAL, SYSDATE, SEQ_CRUISE_CUSTOMER_ID.CURRVAL);

NEXTVAL və CURRVAL-ın istifadəsində bəzi diqqət etməmiz gərəkən məqamlar var:

Sessiya daxilində NEXTVAL CURRVAL-dan əvvəl işlənməlidir.
Əgər hər hansı INSERT daxilində NEXTVAL istifadə edirsinizsə, INSERT zamanı xəta baş versə belə sequence təyin olunmuş sequence_option-a görə qiymətini dəyişir.
NEXTVAL və CURRVAL – CREATE TABLE və ALTER TABLE-in DEFAULT parametri ilə istifadə edilə bilməz.
NEXTVAL və CURRVAL – CREATE VIEW–nun subquery-sində istifadə edilə bilməz həmçinin SELECT, DELETE, UPDATE-in suquery-ləri ilə də istifadə oluna bilməz.
NEXTVAL və CURRVAL – DISTINCT ilə istifadə edilə bilməz
NEXTVAL və CURRVAL – SELECT-in WHERE şərtində istifadə oluna bilməz.
NEXTVAL və CURRVAL – CHECK constraint–i ilə istifadə oluna bilməz.
NEXTVAL və CURRVAL – set operatorları(UNION, MINUS, INTERSECT) ilə istifadə oluna bilməz.
NEXTVAL – SELECT-in daxilində istifadə edilə bilər bu zaman xəta baş versə belə sequence oz qiymətini sequence_option-a görə dəyişəcək.

INDEX-lərin yaradılması və istifadəsi

INDEX–lər bazamızda yerləşən və yazdığımız sorğuların daha sürətli icra olunmasına səbəb olan obyektlərdir. INDEX-lər verilmiş cədvəl üçün təyin edilmiş sütunlardan məlumatları sıralanmış şəkildə saxlayırlar. SQL sorğularda istifadə etdiyimiz WHERE və ORDER BY kimi ifadələrin daha sürətli işləməsi üçün INDEX-lər önəmlidir.

LOB və ya RAW verilən tipində olan sütunlar üçün INDEX yarada bilməzsiniz. Digər bütün verilən tiplərinə sahib sütunlar üçün istədiyiniz qədər index yarada bilərsiniz ancaq çox index yaratmaq sizə gələcəkdə INSERT, DELETE, UPDATE kimi DML ifadələrinin iş yükünün artmasına səbəb olacaqdır.

IMPLICIT INDEX-lər

İmplicit index-lər bizim dilə tərcümədə gizli index-lər kimi tərcümə edilə bilər. Cədvəl yaradarkən PRIMARY KEY və UNIQUE constraint-lərində istifadə etdiyimiz zaman sql avtomatik olaraq index yaradacaq bu cür yaradılan indexlərə implicit(gizli) index-lər deyəcəyik. Implicit olaraq yaradılan index-lərə sistemin özü ad verəcək.

Məs:

CREATE TABLE SEMINARS(

SEMINAR_ID NUMBER(11) PRIMARY KEY,

SEMINAR_NAME VARCHAR2(30) UNIQUE

);

İndi isə USER_INDEXES və USER_IND_COLUMNS adlı data dictionary-lərdən yaratdığımız indexlərin adlarına baxaq. Data dictionary-lərə aid ayrıca yazım olacaq 😉

SELECT TABLE_NAME,

INDEX_NAME

FROM USER_INDEXES

WHERE TABLE_NAME = ‘SEMINARS’;

TABLE_NAME INDEX_NAME

—————————— ——————————

SEMINARS SYS_C009932

SEMINARS SYS_C009931

Belə bir sorğu daha ətraflı məlumat verəcək bizə:

SELECT TABLE_NAME,

INDEX_NAME,

COLUMN_NAME

FROM USER_IND_COLUMNS

WHERE TABLE_NAME = ‘SEMINARS’;

TABLE_NAME INDEX_NAME COLUMN_NAME

————————————- ———————————- ———————————

SEMINARS SYS_C009931 SEMINAR_ID

SEMINARS SYS_C009932 SEMINAR_NAME

EXPLICIT INDEX-lər

Bu tip index-ləri yaradarkən adlarını özümüz verə bilirik.

Məs:

CREATE INDEX IX_INV_INVOICE_DATE ON INVOICES(INVOICE_DATE);

Bu kodla INVOICES cədvəlində INVOICE_DATE sütunu üzərində IX_INV_INVOICE_DATE adında index yaranmış olacaq. Bu sütun üzərindən edəcəyimiz hər axtarış zamanı “optimizer” ilk öncə bu sütun üzərində yaratmış olduğumuz index-də axtarış edəcək və cədvəldən məlumatları bizə qaytaracaq.

Məs:

SELECT * FROM INVOICES WHERE INVOICE_DATE = SYSDATE;

OPTIMIZER

Bütün SQL sorğular, ifadələr ORACLE Database Optimizer-i istifadə edir. Optimizer sql sorğuların hansı yolla ən yaxşı performansı göstərərək nəticə verməsinə qərar verir. Sorğularımızda WHERE və ORDER BY kimi ifadələrin bir başa cədvələ yoxsa yaradılmış index-ə müraciət edəcəyini təyin edir yəni axtarış etdiyimiz sütun üzərində index-in yaradılmış olması onun hər dəfə istifadə olunacağı mənasına gəlmir.Məsələn: İndex yaratdığınız sütunda ancaq eyni qiymətlər saxlanılırsa yəni unikal qiymətlər yoxdursa bu zaman optimizer index-ə müraciət etməyəcək ancaq sizin sütunda saxladığınız qiymətlər unikaldırsa bu zaman optimizer böyük ehtimalla index-ə müraciət edəcək buna isə “selectivity” deyilir. Optimizer-in, “selectivity”-ni yaratdığınız index-ə üstünlük verməsi üçün bir neçə üsul vardır:

Index olunmuş sütunlar bərabərlik işarəsi ilə müqayisə edilməlidir.
Böyükdür(>) , Kiçikdir (<) kimi müqayisə operatorları istifadə edilməlidir.
Bərabər deyil(<>, !=, ^=) operatoru istifadə olunarsa index-ə müraciət edilməyəcək.
LIKE operatoru-nun işarəsi olan “%” başlanğıc formada işlənərsə index-ə müraciət edilməyəcək, ortada və ya axırda istifadəsi zamanı index-ə müraciət ediləcək.
Funksiyaların istifadəsi index-ə müraciət olunmağın qarşısını alacaq, ancaq funksiya əsaslı index-lər(function based index) yaratdığınız zaman onlara müraciət olunacaq.
IS NULL və ya IS NOT NULL istifadə etdiyiniz zaman optimizer index-ə müraciət etməyəcək.

COMPOSITE INDEX-lər

Composite index-lər 2 və ya daha çox sütun üzərində yaradılmış index-lərdir.

CREATE INDEX IX_INV_INVOICE_VENDOR_ID ON INVOICES(VENDOR_ID, INVOICE_DATE);

Belə bir sorğu optimizer-in index-ə müraciət etməsinə səbəb olacaqdır:

SELECT * FROM INVOICES WHERE VENDOR_ID = 10 AND INVOICE_DATE = SYSDATE;

Bu sorğuda index yaradılmasında istifadə olunan hər 2 sütunu istifadə etdik deyə optimizer index-ə müraciət etdi ancaq bu sütunlardan yalnız 1-ni istifadə etdikdə optimizer “skip scanning” xüsusiyəti ilə index-ə müraciət edilib edilməyəcəyini təyin edəcək. Composite index-lərdə 1ci sütun 1ci, 2ci sütun 2ci …nci sütun isə n-ci sıralanır.

Məs:

SELECT * FROM INVOICES WHERE VENDOR_ID = 10;

Bu sorğuda optimizer index-ə müraciət edəcək çünki index-in ilk sütununa müraciət var.

SELECT * FROM INVOICES WHERE INVOICE_DATE = SYSDATE;

Bu sorğuda isə index-in 1ci sütunun olmamasına baxmayaraq yenə index-ə müraciət olunacaq buna səbəb skip scanning xususiyətidir.

UNIQUE INDEX-lər

Unique index o sütunlarda yaradılır ki, sütunlarda yalnız unikal qiymətlər saxlanılır.

CREATE UNIQUE INDEX IX_EMP_SSN ON EMPLOYEES(SSN);

Cədvəl yaratdığımız zaman PRIMARY KEY və ya UNIQUE constraint-lərindən istifadə etdyimiz zaman yaranan avtomatik index-lər də həmçinin UNIQUE index-lərdir.

DROP INDEX

Yaratdığımız index-ləri silmək üçün DROP əmrindən istifadə edirik.

DROP INDEX IX_INV_INVOICE_DATE;

Qeyd: Əgər index yaratdığınız cədvəli silsəniz o zaman cədvəl üzərində olan index-ləri də silmiş olursunuz. Cədvəli yenidən yaratdıqda index-ləri də yenidən yaratmalısınız.

PRIVATE və PUBLIC SYNONYMS

SYNONYM – bazada olan obyektə bir digər alternativ addır. Cədvəllər, view, index və həmçinin synonym-lər üçün də synonym yarada bilərsiniz. 2 tip synonym vardır.

PRIVATE SYNONYM və ya SYNONYM
PUBLIC SYNONYM

PRIVATE SYNONYM

Private synonym və ya sadəcə synonym onu yaradan istifadəçiyə məxsus olur və yalnız onu yaradan istifadəçi tərəfindən görünür. İstifadəçi yaratmış olduğu synonym(private synonym) –i digər istifadəçilərə imtiyazlar verərək istifadəsinə icazə verə bilər.

Private synonym yaradarkən ümumi sintaksisə əməl etmək lazımdır.

CREATE mütləqdir
OR REPLACE əlavədir
SYNONYM mütləqdir
FOR mütləqdir
Synonym-ə verəcəyiniz ad baza oyektlərini adlandırma qaydalarına uyğun olmalıdır.

CREATE OR REPLACE SYNONYM CO FOR CRUISE_ORDERS;

1)SELECT * FROM CRUISE_ORDERS;

2)SELECT * FROM CO;

1 və 2 sorğuları bizə eyni nəticəni qaytaracaq.

PUBLIC SYNONYM

Public synonym-lər oracle-ın xüsusi sistem istifadəçilərindən olan PUBLIC istifadəçəsinə aiddir. Bazada hər bir istifadəçi tərəfindən görünə bilər ancaq bu həmin synonym-in bütün istifadəçilərin istifadə edə biləcəyi demək deyil bunun üçün istifadəçilərə xüsusi imtiyazlar verilməlidir.

CREATE PUBLIC SYNONYM WH FOR WORK_HISTORY;

OBYEKT IMTIYAZLARI(OBJECT PRIVILEGES)

Public synonym-lər yaradərkən bu synonym-ləri digər istifadəçilər trəfindən necə istifadə olunacağına baxaq. Fərz edək ki, “PORTS” cədvəlimiz var və bu cədvəl “ALI” istifadəçisinə aiddir. “ALI” istifadəçisi başqa bir “TEHMASIB” adlı istifadəçiyə bu cədvəl üzərində bəzi imtiyazlar versin.

GRANT SELECT ON PORTS TO TEHMASIB;

Hal hazırda “TEHMASIB” istifadəçisi “PORTS” cədvəlinə belə müraciət edəcək.

SELECT * FROM ALI.PORTS;

Bu yazılış bizim üçün əlverişsizdir çünki zamanla siz hansı cədvəlin kimə aid olduğunu unuda bilərsiniz, bunun üçün belə bir kod bizi bu çətinlikdən qurtaracaq.

CREATE PUBLIC SYNONYM PORTS FOR ALI.PORTS;

Bu kod icra olunduqdan sonra artıq TEHMASIB istifadəçisi PORTS cədvəlinə 2 cür müraciət edə bilər.

SELECT * FROM ALI.PORTS;
SELECT * FROM PORTS;

Əgər public synonym yarandıqdan sonra PORTS cədvəli başqa istifadəçiyə məxsus olarsa bu zaman “ALI” belə bir kod-la yenə “TEHMASİB”-ə bu cədvəli istifadə etməyə imkan yaradacaq.

CREATE OR REPLACE PUBLIC SYNONYM PORTS FOR NEWOWNER.PORTS;

SYNONYM-lərdə AD ÖNCƏLİYİ

Bu mövzunu belə bir sual qoyaraq izah edim. Tutaqki aşağıdakı kimi bir kodumuz olsun bu zaman hansı cədvəlin məlumatlarını qaytarılacağını diyə bilərsinizmi?

CREATE SYNONYM ACCT_01 FOR LAB_RESULTS;

CREATE PUBLIC SYNONYM ACCT_01 FOR CABINETS;

SELECT * FROM ACCT_01;

Cavab: LAB_RESULTS;

Biz əvvəlki yazılarımızda namespace-lərdən danışmışdıq. Buradan göründüyü kimi private synonym-lər cədvəllərimiz-lər birlikdə eyni namespace-də yerləşir və biz hər hansı sorğunu cra etdikdə axtarılan oyektlər local->global şəklində axtarılır yəni birinci namespace daxilindəki obyektlərə sorğu göndərilir. Aşağıdakı şəkil daha aydın izah edir məncə:

DROP SYNONYM

Yaratmış olduğumuz synonym-ləri bazadan silmək üçün:

Private synonym -> DROP SYNONYM CO;

Public synonym -> DROP PUBLIC SYNONYM CO;

Bu mövzudan da bu qədər, ümid edirəm faydalı bilgilər paylaşa bildim. Tənqid, təklif və suallarınız üçün şərh yazın dostlar 🙂

December 3, 2015 abdulalialiyev