DBMS ທີ່ໃຊ້ໄດ້

ໂລກຂອງຖານຂໍ້ມູນໄດ້ຖືກຄອບງໍາມາດົນນານໂດຍ DBMSs ທີ່ກ່ຽວຂ້ອງ, ເຊິ່ງໃຊ້ພາສາ SQL. ຫຼາຍດັ່ງນັ້ນ variants ທີ່ພົ້ນເດັ່ນຂື້ນຖືກເອີ້ນວ່າ NoSQL. ພວກເຂົາເຈົ້າສາມາດແກະສະຫຼັກສະຖານທີ່ສະເພາະໃດຫນຶ່ງສໍາລັບຕົນເອງໃນຕະຫຼາດນີ້, ແຕ່ DBMSs ທີ່ກ່ຽວຂ້ອງຈະບໍ່ຕາຍ, ແລະສືບຕໍ່ຖືກນໍາໃຊ້ຢ່າງຈິງຈັງເພື່ອຈຸດປະສົງຂອງເຂົາເຈົ້າ.

ໃນບົດຄວາມນີ້ຂ້ອຍຕ້ອງການອະທິບາຍແນວຄວາມຄິດຂອງຖານຂໍ້ມູນທີ່ເປັນປະໂຫຍດ. ສໍາລັບຄວາມເຂົ້າໃຈທີ່ດີກວ່າ, ຂ້າພະເຈົ້າຈະເຮັດສິ່ງນີ້ໂດຍການປຽບທຽບມັນກັບຕົວແບບຄວາມສໍາພັນຄລາສສິກ. ບັນຫາຈາກການທົດສອບ SQL ຕ່າງໆທີ່ພົບເຫັນຢູ່ໃນອິນເຕີເນັດຈະຖືກນໍາໃຊ້ເປັນຕົວຢ່າງ.

ການນໍາສະເຫນີ

ຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງດໍາເນີນການຢູ່ໃນຕາຕະລາງແລະພາກສະຫນາມ. ໃນຖານຂໍ້ມູນທີ່ເປັນປະໂຫຍດ, ຫ້ອງຮຽນແລະຫນ້າທີ່ຈະຖືກໃຊ້ແທນ, ຕາມລໍາດັບ. ຊ່ອງຂໍ້ມູນໃນຕາຕະລາງທີ່ມີປຸ່ມ N ຈະຖືກສະແດງເປັນຫນ້າທີ່ຂອງ N ພາລາມິເຕີ. ແທນທີ່ຈະເປັນການພົວພັນລະຫວ່າງຕາຕະລາງ, ຟັງຊັນຈະຖືກນໍາໃຊ້ທີ່ສົ່ງຄືນວັດຖຸຂອງຊັ້ນທີ່ເຊື່ອມຕໍ່. ອົງປະກອບຟັງຊັນຈະຖືກໃຊ້ແທນ JOIN.

ກ່ອນທີ່ຈະເຄື່ອນຍ້າຍໂດຍກົງກັບວຽກງານ, ຂ້າພະເຈົ້າຈະອະທິບາຍວຽກງານຂອງເຫດຜົນຂອງໂດເມນ. ສໍາລັບ DDL ຂ້ອຍຈະໃຊ້ syntax PostgreSQL. ສໍາລັບການເຮັດວຽກ, ມັນມີ syntax ຂອງຕົນເອງ.

ຕາຕະລາງແລະພາກສະຫນາມ

ວັດຖຸ Sku ງ່າຍໆທີ່ມີຊື່ ແລະລາຄາ:

ຄວາມສຳພັນ

CREATE TABLE Sku
(
    id bigint NOT NULL,
    name character varying(100),
    price numeric(10,5),
    CONSTRAINT id_pkey PRIMARY KEY (id)
)

ໜ້າ ທີ່

CLASS Sku;
name = DATA STRING[100] (Sku);
price = DATA NUMERIC[10,5] (Sku);


ພວກເຮົາປະກາດສອງ ປະຕິບັດຫນ້າ, ເຊິ່ງໃຊ້ເວລາຫນຶ່ງພາລາມິເຕີ Sku ເປັນ input ແລະສົ່ງຄືນເປັນປະເພດ primitive.

ມັນສົມມຸດວ່າໃນ DBMS ທີ່ເປັນປະໂຫຍດແຕ່ລະວັດຖຸຈະມີລະຫັດພາຍໃນບາງຢ່າງທີ່ຖືກສ້າງຂຶ້ນໂດຍອັດຕະໂນມັດແລະສາມາດເຂົ້າເຖິງໄດ້ຖ້າຈໍາເປັນ.

ໃຫ້ກໍານົດລາຄາສໍາລັບຜະລິດຕະພັນ / ຮ້ານ / ຜູ້ສະຫນອງ. ມັນອາດຈະມີການປ່ຽນແປງຕາມເວລາ, ສະນັ້ນໃຫ້ເພີ່ມຊ່ອງເວລາໃສ່ຕາຕະລາງ. ຂ້ອຍຈະຂ້າມການປະກາດຕາຕະລາງສໍາລັບໄດເລກະທໍລີໃນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງເພື່ອຫຍໍ້ລະຫັດ:

ຄວາມສຳພັນ

CREATE TABLE prices
(
    skuId bigint NOT NULL,
    storeId bigint NOT NULL,
    supplierId bigint NOT NULL,
    dateTime timestamp without time zone,
    price numeric(10,5),
    CONSTRAINT prices_pkey PRIMARY KEY (skuId, storeId, supplierId)
)

ໜ້າ ທີ່

CLASS Sku;
CLASS Store;
CLASS Supplier;
dateTime = DATA DATETIME (Sku, Store, Supplier);
price = DATA NUMERIC[10,5] (Sku, Store, Supplier);


ດັດນີ

ຕົວຢ່າງສຸດທ້າຍ, ພວກເຮົາຈະສ້າງດັດສະນີໃນທຸກຄີແລະວັນທີເພື່ອໃຫ້ພວກເຮົາສາມາດຊອກຫາລາຄາໄດ້ໄວໃນເວລາສະເພາະ.

ຄວາມສຳພັນ

CREATE INDEX prices_date
    ON prices
    (skuId, storeId, supplierId, dateTime)

ໜ້າ ທີ່

INDEX Sku sk, Store st, Supplier sp, dateTime(sk, st, sp);


ວຽກງານ

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍບັນຫາທີ່ຂ້ອນຂ້າງງ່າຍດາຍທີ່ເອົາມາຈາກທີ່ສອດຄ້ອງກັນ ບົດຄວາມ ສຸດ Habr.

ທໍາອິດ, ໃຫ້ປະກາດເຫດຜົນຂອງໂດເມນ (ສໍາລັບຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງນີ້ແມ່ນເຮັດໂດຍກົງໃນບົດຄວາມຂ້າງເທິງ).

CLASS Department;
name = DATA STRING[100] (Department);

CLASS Employee;
department = DATA Department (Employee);
chief = DATA Employee (Employee);
name = DATA STRING[100] (Employee);
salary = DATA NUMERIC[14,2] (Employee);


ວຽກງານ 1.1

ສະແດງລາຍຊື່ຂອງພະນັກງານທີ່ໄດ້ຮັບເງິນເດືອນຫຼາຍກວ່າຜູ້ຄຸມງານຂອງເຂົາເຈົ້າທັນທີ.

ຄວາມສຳພັນ

select a.*
from   employee a, employee b
where  b.id = a.chief_id
and    a.salary > b.salary

ໜ້າ ທີ່

SELECT name(Employee a) WHERE salary(a) > salary(chief(a));


ວຽກງານ 1.2

ລາຍຊື່ພະນັກງານທີ່ໄດ້ຮັບເງິນເດືອນສູງສຸດໃນພະແນກຂອງພວກເຂົາ

ຄວາມສຳພັນ

select a.*
from   employee a
where  a.salary = ( select max(salary) from employee b
                    where  b.department_id = a.department_id )

ໜ້າ ທີ່

maxSalary 'Максимальная зарплата' (Department s) = 
    GROUP MAX salary(Employee e) IF department(e) = s;
SELECT name(Employee a) WHERE salary(a) = maxSalary(department(a));

// или если "заинлайнить"
SELECT name(Employee a) WHERE 
    salary(a) = maxSalary(GROUP MAX salary(Employee e) IF department(e) = department(a));


ການປະຕິບັດທັງສອງແມ່ນທຽບເທົ່າ. ສໍາລັບກໍລະນີທໍາອິດ, ໃນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງທ່ານສາມາດນໍາໃຊ້ CREATE VIEW, ເຊິ່ງໃນລັກສະນະດຽວກັນທໍາອິດຈະຄິດໄລ່ເງິນເດືອນສູງສຸດສໍາລັບພະແນກສະເພາະໃນນັ້ນ. ໃນສິ່ງທີ່ຕໍ່ໄປນີ້, ສໍາລັບຄວາມຊັດເຈນ, ຂ້າພະເຈົ້າຈະນໍາໃຊ້ກໍລະນີທໍາອິດ, ເນື່ອງຈາກວ່າມັນສະທ້ອນໃຫ້ເຫັນດີກວ່າການແກ້ໄຂ.

ວຽກງານ 1.3

ສະ​ແດງ​ບັນ​ຊີ​ລາຍ​ຊື່​ຂອງ​ພະ​ແນກ​, ຈໍາ​ນວນ​ຂອງ​ພະ​ນັກ​ງານ​ທີ່​ບໍ່​ເກີນ 3 ຄົນ​.

ຄວາມສຳພັນ

select department_id
from   employee
group  by department_id
having count(*) <= 3

ໜ້າ ທີ່

countEmployees 'Количество сотрудников' (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
SELECT Department d WHERE countEmployees(d) <= 3;


ວຽກງານ 1.4

ສະແດງບັນຊີລາຍຊື່ຂອງພະນັກງານທີ່ບໍ່ມີຜູ້ຈັດການທີ່ກໍານົດໄວ້ເຮັດວຽກຢູ່ໃນພະແນກດຽວກັນ.

ຄວາມສຳພັນ

select a.*
from   employee a
left   join employee b on (b.id = a.chief_id and b.department_id = a.department_id)
where  b.id is null

ໜ້າ ທີ່

SELECT name(Employee a) WHERE NOT (department(chief(a)) = department(a));


ວຽກງານ 1.5

ຊອກຫາລາຍການ ID ຂອງພະແນກທີ່ມີເງິນເດືອນພະນັກງານສູງສຸດ.

ຄວາມສຳພັນ

with sum_salary as
  ( select department_id, sum(salary) salary
    from   employee
    group  by department_id )
select department_id
from   sum_salary a       
where  a.salary = ( select max(salary) from sum_salary )

ໜ້າ ທີ່

salarySum 'Максимальная зарплата' (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;
maxSalarySum 'Максимальная зарплата отделов' () = 
    GROUP MAX salarySum(Department d);
SELECT Department d WHERE salarySum(d) = maxSalarySum();


ຂໍໃຫ້ກ້າວໄປສູ່ວຽກງານທີ່ສັບສົນຫຼາຍຈາກວຽກອື່ນ ບົດຄວາມ. ມັນປະກອບດ້ວຍການວິເຄາະລາຍລະອຽດຂອງວິທີການປະຕິບັດວຽກງານນີ້ໃນ MS SQL.

ວຽກງານ 2.1

ຜູ້ຂາຍໃດທີ່ຂາຍຫຼາຍກວ່າ 1997 ຫນ່ວຍຂອງຜະລິດຕະພັນ 30 ໃນປີ 1?

ເຫດຜົນຂອງໂດເມນ (ເຊັ່ນດຽວກັບໃນ RDBMS ພວກເຮົາຂ້າມການປະກາດ):

CLASS Employee 'Продавец';
lastName 'Фамилия' = DATA STRING[100] (Employee);

CLASS Product 'Продукт';
id = DATA INTEGER (Product);
name = DATA STRING[100] (Product);

CLASS Order 'Заказ';
date = DATA DATE (Order);
employee = DATA Employee (Order);

CLASS Detail 'Строка заказа';

order = DATA Order (Detail);
product = DATA Product (Detail);
quantity = DATA NUMERIC[10,5] (Detail);


ຄວາມສຳພັນ

select LastName
from Employees as e
where (
  select sum(od.Quantity)
  from [Order Details] as od
  where od.ProductID = 1 and od.OrderID in (
    select o.OrderID
    from Orders as o
    where year(o.OrderDate) = 1997 and e.EmployeeID = o.EmployeeID)
) > 30

ໜ້າ ທີ່

sold (Employee e, INTEGER productId, INTEGER year) = 
    GROUP SUM quantity(OrderDetail d) IF 
        employee(order(d)) = e AND 
        id(product(d)) = productId AND 
        extractYear(date(order(d))) = year;
SELECT lastName(Employee e) WHERE sold(e, 1, 1997) > 30;


ວຽກງານ 2.2

ສໍາລັບຜູ້ຊື້ແຕ່ລະຄົນ (ຊື່, ນາມສະກຸນ), ຊອກຫາສອງສິນຄ້າ (ຊື່) ທີ່ຜູ້ຊື້ໃຊ້ເງິນຫຼາຍທີ່ສຸດໃນປີ 1997.

ພວກເຮົາຂະຫຍາຍເຫດຜົນຂອງໂດເມນຈາກຕົວຢ່າງທີ່ຜ່ານມາ:

CLASS Customer 'Клиент';
contactName 'ФИО' = DATA STRING[100] (Customer);

customer = DATA Customer (Order);

unitPrice = DATA NUMERIC[14,2] (Detail);
discount = DATA NUMERIC[6,2] (Detail);


ຄວາມສຳພັນ

SELECT ContactName, ProductName FROM (
SELECT c.ContactName, p.ProductName
, ROW_NUMBER() OVER (
    PARTITION BY c.ContactName
    ORDER BY SUM(od.Quantity * od.UnitPrice * (1 - od.Discount)) DESC
) AS RatingByAmt
FROM Customers c
JOIN Orders o ON o.CustomerID = c.CustomerID
JOIN [Order Details] od ON od.OrderID = o.OrderID
JOIN Products p ON p.ProductID = od.ProductID
WHERE YEAR(o.OrderDate) = 1997
GROUP BY c.ContactName, p.ProductName
) t
WHERE RatingByAmt < 3

ໜ້າ ທີ່

sum (Detail d) = quantity(d) * unitPrice(d) * (1 - discount(d));
bought 'Купил' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y;
rating 'Рейтинг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;


ຕົວປະຕິບັດການ PARTITION ເຮັດວຽກຢູ່ໃນຫຼັກການຕໍ່ໄປນີ້: ມັນລວມເອົາການສະແດງອອກທີ່ລະບຸໄວ້ຫຼັງຈາກ SUM (ທີ່ນີ້ 1), ພາຍໃນກຸ່ມທີ່ລະບຸ (ທີ່ນີ້ລູກຄ້າແລະປີ, ແຕ່ອາດຈະເປັນການສະແດງອອກໃດກໍ່ຕາມ), ການຈັດຮຽງພາຍໃນກຸ່ມໂດຍສໍານວນທີ່ລະບຸໄວ້ໃນຄໍາສັ່ງ ( ທີ່ນີ້ຊື້, ແລະຖ້າເທົ່າທຽມກັນ, ຫຼັງຈາກນັ້ນອີງຕາມລະຫັດຜະລິດຕະພັນພາຍໃນ).

ວຽກງານ 2.3

ຕ້ອງສັ່ງສິນຄ້າຈາກຜູ້ສະໜອງຈໍານວນເທົ່າໃດເພື່ອບັນລຸຄໍາສັ່ງໃນປະຈຸບັນ.

ໃຫ້ພວກເຮົາຂະຫຍາຍເຫດຜົນຂອງໂດເມນອີກເທື່ອຫນຶ່ງ:

CLASS Supplier 'Поставщик';
companyName = DATA STRING[100] (Supplier);

supplier = DATA Supplier (Product);

unitsInStock 'Остаток на складе' = DATA NUMERIC[10,3] (Product);
reorderLevel 'Норма продажи' = DATA NUMERIC[10,3] (Product);


ຄວາມສຳພັນ

select s.CompanyName, p.ProductName, sum(od.Quantity) + p.ReorderLevel — p.UnitsInStock as ToOrder
from Orders o
join [Order Details] od on o.OrderID = od.OrderID
join Products p on od.ProductID = p.ProductID
join Suppliers s on p.SupplierID = s.SupplierID
where o.ShippedDate is null
group by s.CompanyName, p.ProductName, p.UnitsInStock, p.ReorderLevel
having p.UnitsInStock < sum(od.Quantity) + p.ReorderLevel

ໜ້າ ທີ່

orderedNotShipped 'Заказано, но не отгружено' (Product p) = 
    GROUP SUM quantity(OrderDetail d) IF product(d) = p;
toOrder 'К заказу' (Product p) = orderedNotShipped(p) + reorderLevel(p) - unitsInStock(p);
SELECT companyName(supplier(Product p)), name(p), toOrder(p) WHERE toOrder(p) > 0;


ມີບັນຫາກັບເຄື່ອງໝາຍດາວ

ແລະຕົວຢ່າງສຸດທ້າຍແມ່ນມາຈາກຂ້ອຍສ່ວນຕົວ. ມີເຫດຜົນຂອງເຄືອຂ່າຍສັງຄົມ. ປະຊາຊົນສາມາດເປັນເພື່ອນກັບກັນແລະກັນແລະມັກເຊິ່ງກັນແລະກັນ. ຈາກທັດສະນະຖານຂໍ້ມູນທີ່ເປັນປະໂຫຍດ, ມັນຈະເບິ່ງຄືວ່ານີ້:

CLASS Person;
likes = DATA BOOLEAN (Person, Person);
friends = DATA BOOLEAN (Person, Person);


ມັນເປັນສິ່ງຈໍາເປັນເພື່ອຊອກຫາຜູ້ສະຫມັກທີ່ເປັນໄປໄດ້ສໍາລັບມິດຕະພາບ. ຢ່າງເປັນທາງການ, ທ່ານຈໍາເປັນຕ້ອງຊອກຫາຄົນທັງຫມົດ A, B, C ເຊັ່ນວ່າ A ແມ່ນຫມູ່ເພື່ອນກັບ B, ແລະ B ແມ່ນຫມູ່ເພື່ອນກັບ C, A ມັກ C, ແຕ່ A ບໍ່ແມ່ນເພື່ອນກັບ C.
ຈາກທັດສະນະຖານຂໍ້ມູນທີ່ເປັນປະໂຫຍດ, ຄໍາຖາມຈະມີລັກສະນະນີ້:

SELECT Person a, Person b, Person c WHERE 
    likes(a, c) AND NOT friends(a, c) AND 
    friends(a, b) AND friends(b, c);


ຜູ້ອ່ານໄດ້ຖືກຊຸກຍູ້ໃຫ້ແກ້ໄຂບັນຫານີ້ໃນ SQL ດ້ວຍຕົວເອງ. ມັນສົມມຸດວ່າມີຫມູ່ເພື່ອນຫນ້ອຍກວ່າຄົນທີ່ທ່ານມັກ. ເພາະສະນັ້ນພວກເຂົາຢູ່ໃນຕາຕະລາງແຍກຕ່າງຫາກ. ຖ້າປະສົບຜົນສໍາເລັດ, ຍັງມີວຽກງານທີ່ມີສອງດາວ. ໃນມັນ, ມິດຕະພາບບໍ່ແມ່ນຄວາມສົມມາດ. ໃນຖານຂໍ້ມູນທີ່ເປັນປະໂຫຍດ, ມັນຈະມີລັກສະນະນີ້:

SELECT Person a, Person b, Person c WHERE 
    likes(a, c) AND NOT friends(a, c) AND 
    (friends(a, b) OR friends(b, a)) AND 
    (friends(b, c) OR friends(c, b));


UPD: ການແກ້ໄຂບັນຫາທີ່ມີດາວທໍາອິດແລະທີສອງຈາກ dss_kalika:

SELECT 
   pl.PersonAID
  ,pf.PersonAID
  ,pff.PersonAID
FROM Persons                 AS p
--Лайки                      
JOIN PersonRelationShip      AS pl ON pl.PersonAID = p.PersonID
                                  AND pl.Relation  = 'Like'
--Друзья                     
JOIN PersonRelationShip      AS pf ON pf.PersonAID = p.PersonID 
                                  AND pf.Relation = 'Friend'
--Друзья Друзей              
JOIN PersonRelationShip      AS pff ON pff.PersonAID = pf.PersonBID
                                   AND pff.PersonBID = pl.PersonBID
                                   AND pff.Relation = 'Friend'
--Ещё не дружат         
LEFT JOIN PersonRelationShip AS pnf ON pnf.PersonAID = p.PersonID
                                   AND pnf.PersonBID = pff.PersonBID
                                   AND pnf.Relation = 'Friend'
WHERE pnf.PersonAID IS NULL 

;WITH PersonRelationShipCollapsed AS (
  SELECT pl.PersonAID
        ,pl.PersonBID
        ,pl.Relation 
  FROM #PersonRelationShip      AS pl 
  
  UNION 

  SELECT pl.PersonBID AS PersonAID
        ,pl.PersonAID AS PersonBID
        ,pl.Relation
  FROM #PersonRelationShip      AS pl 
)
SELECT 
   pl.PersonAID
  ,pf.PersonBID
  ,pff.PersonBID
FROM #Persons                      AS p
--Лайки                      
JOIN PersonRelationShipCollapsed  AS pl ON pl.PersonAID = p.PersonID
                                 AND pl.Relation  = 'Like'                                  
--Друзья                          
JOIN PersonRelationShipCollapsed  AS pf ON pf.PersonAID = p.PersonID 
                                 AND pf.Relation = 'Friend'
--Друзья Друзей                   
JOIN PersonRelationShipCollapsed  AS pff ON pff.PersonAID = pf.PersonBID
                                 AND pff.PersonBID = pl.PersonBID
                                 AND pff.Relation = 'Friend'
--Ещё не дружат                   
LEFT JOIN PersonRelationShipCollapsed AS pnf ON pnf.PersonAID = p.PersonID
                                   AND pnf.PersonBID = pff.PersonBID
                                   AND pnf.Relation = 'Friend'
WHERE pnf.[PersonAID] IS NULL 

ສະຫລຸບ

ມັນຄວນຈະສັງເກດວ່າ syntax ພາສາທີ່ເປັນພຽງແຕ່ຫນຶ່ງໃນທາງເລືອກໃນການຈັດຕັ້ງປະຕິບັດແນວຄວາມຄິດທີ່ໃຫ້. SQL ໄດ້ຖືກປະຕິບັດເປັນພື້ນຖານ, ແລະເປົ້າຫມາຍແມ່ນເພື່ອໃຫ້ມັນຄ້າຍຄືກັນເທົ່າທີ່ເປັນໄປໄດ້. ແນ່ນອນ, ບາງຄົນອາດຈະບໍ່ມັກຊື່ຂອງຄໍາຫລັກ, ບັນທຶກຄໍາ, ແລະອື່ນໆ. ສິ່ງທີ່ສໍາຄັນຢູ່ທີ່ນີ້ແມ່ນແນວຄວາມຄິດຂອງມັນເອງ. ຖ້າທ່ານຕ້ອງການ, ທ່ານສາມາດສ້າງ syntax ຄ້າຍຄືກັນ C ++ ແລະ Python.

ແນວຄວາມຄິດຖານຂໍ້ມູນທີ່ອະທິບາຍ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ມີຂໍ້ດີດັ່ງຕໍ່ໄປນີ້:

• ຄວາມສະດວກ. ນີ້ແມ່ນຕົວຊີ້ວັດທີ່ຂ້ອນຂ້າງທີ່ບໍ່ຊັດເຈນໃນກໍລະນີງ່າຍໆ. ແຕ່ຖ້າທ່ານເບິ່ງກໍລະນີທີ່ສັບສົນຫຼາຍ (ຕົວຢ່າງ, ບັນຫາກັບດາວ), ຫຼັງຈາກນັ້ນ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ການຂຽນແບບສອບຖາມດັ່ງກ່າວແມ່ນງ່າຍຂຶ້ນຫຼາຍ.
• ລາຍະລະອຽດ. ໃນບາງຕົວຢ່າງຂ້າພະເຈົ້າໄດ້ປະກາດຫນ້າທີ່ລະດັບກາງ (ຕົວຢ່າງ: ຂາຍໄດ້, ຊື້ໄດ້ ແລະອື່ນໆ), ຈາກຫນ້າທີ່ຕໍ່ມາໄດ້ຖືກສ້າງຂຶ້ນ. ນີ້ອະນຸຍາດໃຫ້ທ່ານສາມາດປ່ຽນເຫດຜົນຂອງຫນ້າທີ່ສະເພາະໃດຫນຶ່ງ, ຖ້າຈໍາເປັນ, ໂດຍບໍ່ມີການປ່ຽນເຫດຜົນຂອງສິ່ງທີ່ຂຶ້ນກັບພວກມັນ. ຕົວຢ່າງ, ເຈົ້າສາມາດຂາຍໄດ້ ຂາຍໄດ້ ໄດ້ຖືກຄິດໄລ່ຈາກວັດຖຸທີ່ແຕກຕ່າງກັນຫມົດ, ໃນຂະນະທີ່ສ່ວນທີ່ເຫຼືອຂອງເຫດຜົນຈະບໍ່ປ່ຽນແປງ. ແມ່ນແລ້ວ, ນີ້ສາມາດຖືກປະຕິບັດໃນ RDBMS ໂດຍໃຊ້ CREATE VIEW. ແຕ່ຖ້າເຫດຜົນທັງຫມົດຖືກຂຽນດ້ວຍວິທີນີ້, ມັນຈະເບິ່ງບໍ່ໄດ້ອ່ານຫຼາຍ.
• ບໍ່ມີຊ່ອງຫວ່າງ semantic. ຖານຂໍ້ມູນດັ່ງກ່າວດໍາເນີນການກ່ຽວກັບຫນ້າທີ່ແລະຊັ້ນຮຽນ (ແທນທີ່ຈະເປັນຕາຕະລາງແລະພາກສະຫນາມ). ຄືກັນກັບການຂຽນໂປລແກລມຄລາສສິກ (ຖ້າພວກເຮົາສົມມຸດວ່າວິທີການແມ່ນຫນ້າທີ່ທີ່ມີພາລາມິເຕີທໍາອິດໃນຮູບແບບຂອງຫ້ອງຮຽນທີ່ມັນຂຶ້ນກັບ). ຕາມນັ້ນແລ້ວ, ມັນຄວນຈະງ່າຍຂຶ້ນຫຼາຍທີ່ຈະ “ສ້າງເພື່ອນ” ດ້ວຍພາສາການຂຽນໂປຣແກຣມທົ່ວໄປ. ນອກຈາກນັ້ນ, ແນວຄວາມຄິດນີ້ອະນຸຍາດໃຫ້ປະຕິບັດຫນ້າທີ່ສະລັບສັບຊ້ອນຫຼາຍ. ຕົວຢ່າງ, ທ່ານສາມາດຝັງຕົວປະຕິບັດການເຊັ່ນ:

  CONSTRAINT sold(Employee e, 1, 2019) > 100 IF name(e) = 'Петя' MESSAGE  'Что-то Петя продает слишком много одного товара в 2019 году';


• ມໍລະດົກແລະ polymorphism. ໃນຖານຂໍ້ມູນທີ່ເປັນປະໂຫຍດ, ທ່ານສາມາດແນະນໍາການສືບທອດຫຼາຍໂດຍຜ່ານ CLASS ClassP: Class1, Class2 ການກໍ່ສ້າງແລະປະຕິບັດຫຼາຍ polymorphism. ຂ້ອຍອາດຈະຂຽນແນວໃດແທ້ໃນບົດຄວາມໃນອະນາຄົດ.

ເຖິງແມ່ນວ່ານີ້ແມ່ນພຽງແຕ່ແນວຄວາມຄິດ, ພວກເຮົາມີການປະຕິບັດບາງຢ່າງໃນ Java ທີ່ແປເຫດຜົນທີ່ເປັນປະໂຫຍດທັງຫມົດເຂົ້າໄປໃນເຫດຜົນທີ່ກ່ຽວຂ້ອງ. ນອກຈາກນັ້ນ, ເຫດຜົນຂອງການເປັນຕົວແທນແລະສິ່ງອື່ນໆຫຼາຍແມ່ນຕິດກັບມັນທີ່ສວຍງາມ, ຂອບໃຈທີ່ພວກເຮົາໄດ້ຮັບທັງຫມົດ. ເວທີ. ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາໃຊ້ RDBMS (ພຽງແຕ່ PostgreSQL ສໍາລັບໃນປັດຈຸບັນ) ເປັນ "ເຄື່ອງ virtual". ບາງຄັ້ງບັນຫາເກີດຂື້ນກັບການແປນີ້ເພາະວ່າຕົວເພີ່ມປະສິດທິພາບແບບສອບຖາມ RDBMS ບໍ່ຮູ້ສະຖິຕິທີ່ແນ່ນອນທີ່ FDBMS ຮູ້. ໃນທາງທິດສະດີ, ມັນເປັນໄປໄດ້ທີ່ຈະປະຕິບັດລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນທີ່ຈະນໍາໃຊ້ໂຄງສ້າງສະເພາະໃດຫນຶ່ງເປັນການເກັບຮັກສາ, ດັດແປງໂດຍສະເພາະສໍາລັບເຫດຜົນທີ່ເປັນປະໂຫຍດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com