วิธีการพิสูจน์การขาดคำสั่งโดยนัยในฐานข้อมูลหรือไม่

เมื่อเร็ว ๆ นี้ฉันอธิบายให้เพื่อนร่วมงานทราบถึงความสำคัญของการมีคอลัมน์ที่จะเรียงลำดับข้อมูลในตารางฐานข้อมูลหากจำเป็นต้องทำเช่นสำหรับข้อมูลที่เรียงตามลำดับเวลา สิ่งนี้พิสูจน์ได้ค่อนข้างยากเพราะพวกเขาสามารถเรียกใช้คิวรีของพวกเขาอีกครั้งโดยไม่สิ้นสุดและจะส่งคืนชุดของแถวเดียวกันในลำดับเดียวกันเสมอ

ฉันได้สังเกตสิ่งนี้มาก่อนและสิ่งที่ฉันทำได้จริงๆคือยืนยันว่าพวกเขาเชื่อใจฉันและไม่เพียงแค่คิดว่าตารางฐานข้อมูลจะทำตัวเหมือนไฟล์ CSV หรือ Excel แบบดั้งเดิม

ตัวอย่างเช่นการดำเนินการแบบสอบถาม (PostgreSQL)

create table mytable (
    id INTEGER PRIMARY KEY,
    data TEXT
);
INSERT INTO mytable VALUES
    (0, 'a'),
    (1, 'b'),
    (2, 'c'),
    (3, 'd'),
    (4, 'e'),
    (5, 'f'),
    (6, 'g'),
    (7, 'h'),
    (8, 'i'),
    (9, 'j');

จะสร้างตารางที่มีลำดับความคิดที่ชัดเจน การเลือกข้อมูลเดียวกันด้วยวิธีที่ง่ายที่สุดคือ:

SELECT * FROM mytable;

ให้ผลลัพธ์ดังต่อไปนี้กับฉันเสมอ:

 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  5 | f
  6 | g
  7 | h
  8 | i
  9 | j
(10 rows)

ฉันสามารถทำสิ่งนี้ซ้ำแล้วซ้ำอีกและมันจะกลับมาหาฉันข้อมูลเดียวกันในลำดับเดียวกันเสมอ อย่างไรก็ตามฉันรู้ว่าคำสั่งโดยปริยายนี้สามารถใช้งานไม่ได้ฉันเคยเห็นมาก่อนโดยเฉพาะในชุดข้อมูลขนาดใหญ่ซึ่งค่าสุ่มบางอย่างจะถูกส่งไปยังสถานที่ "ผิด" เมื่อถูกเลือก แต่มันเกิดขึ้นกับฉันโดยที่ฉันไม่รู้ว่าสิ่งนี้เกิดขึ้นได้อย่างไรหรือจะทำซ้ำได้อย่างไร ฉันพบว่ามันยากที่จะได้รับผลลัพธ์ใน Google เพราะคำค้นหามีแนวโน้มที่จะเพียงแค่ส่งคืนความช่วยเหลือทั่วไปในการเรียงลำดับชุดผลลัพธ์

ดังนั้นคำถามของฉันเป็นหลักเหล่านี้:

1. ฉันจะได้เห็นถึงรูปธรรมและพิสูจน์ให้เห็นว่าการสั่งการกลับมาของแถวจากแบบสอบถามโดยไม่ต้องมีORDER BYคำสั่งไม่น่าเชื่อถืออย่างยิ่งโดยก่อให้เกิดและแสดงรายละเอียดของการสั่งซื้อนัยแม้ในขณะที่ตารางในคำถามที่จะไม่มีการปรับปรุงหรือแก้ไข ?

2. มันสร้างความแตกต่างหรือไม่ถ้าข้อมูลถูกแทรกครั้งเดียวมาสค์และไม่เคยอัพเดทอีกเลย?

ฉันต้องการคำตอบจาก postgres เนื่องจากเป็นคำตอบที่ฉันคุ้นเคยมากที่สุด แต่ฉันก็สนใจทฤษฎีมากกว่า

ฉันเห็นสามวิธีในการพยายามโน้มน้าวพวกเขา:

1. ให้พวกเขาลองใช้แบบสอบถามเดียวกัน แต่มีตารางที่ใหญ่กว่า (จำนวนแถวมากขึ้น) หรือเมื่อตารางกำลังถูกอัพเดตระหว่างการประมวลผล หรือแทรกแถวใหม่และแถวเก่าจะถูกลบ หรือมีการเพิ่มหรือลบดัชนีระหว่างการประมวลผล หรือตารางสูญญากาศ (ใน Postgres) หรือดัชนีถูกสร้างใหม่ (ใน SQL Server) หรือตารางเปลี่ยนจากคลัสเตอร์เป็นฮีป หรือบริการฐานข้อมูลเริ่มต้นใหม่

2. คุณสามารถแนะนำให้พวกเขาพิสูจน์ว่าการประหารชีวิตที่แตกต่างกันนั้นจะกลับมาเป็นลำดับเดียวกัน พวกเขาสามารถพิสูจน์ได้หรือไม่ พวกเขาสามารถให้ชุดการทดสอบที่พิสูจน์ว่าแบบสอบถามใด ๆจะให้ผลลัพธ์ในลำดับเดียวกันไม่ว่าจะถูกดำเนินการกี่ครั้ง?

3. จัดทำเอกสารของ DBMS ต่างๆในเรื่องนั้น ตัวอย่างเช่น:

PostgreSQL :

จัดเรียงแถว

หลังจากแบบสอบถามได้สร้างตารางผลลัพธ์ (หลังจากประมวลผลรายการที่เลือกแล้ว) คุณสามารถเรียงลำดับทางเลือกได้ หากไม่ได้เลือกการเรียงลำดับแถวจะถูกส่งกลับในลำดับที่ไม่ระบุ ลำดับที่แท้จริงในกรณีนั้นจะขึ้นอยู่กับประเภทของการสแกนและการเข้าร่วมและลำดับบนดิสก์แต่จะต้องไม่พึ่งพา สามารถรับประกันการสั่งซื้อเอาต์พุตเฉพาะเมื่อขั้นตอนการจัดเรียงนั้นถูกเลือกอย่างชัดเจน

เซิร์ฟเวอร์ SQL :

SELECT- ORDER BYข้อ (Transact-SQL)

เรียงลำดับข้อมูลที่ส่งคืนโดยแบบสอบถามใน SQL Server ใช้ข้อนี้เพื่อ:

สั่งซื้อชุดผลลัพธ์ของแบบสอบถามโดยรายการคอลัมน์ที่ระบุและเลือกที่จะ จำกัด แถวที่ส่งคืนไปยังช่วงที่ระบุ ลำดับที่จะส่งคืนแถวในชุดผลลัพธ์ไม่ได้รับการรับรองเว้นแต่ORDER BYจะระบุข้อไว้

ออราเคิล :

order_by_clause

ใช้ส่วนORDER BYคำสั่งเพื่อสั่งซื้อแถวที่ส่งคืนโดยคำสั่ง หากไม่มี order_by_clause จะไม่มีการรับประกันว่าแบบสอบถามเดียวกันที่ดำเนินการมากกว่าหนึ่งครั้งจะดึงแถวในลำดับเดียวกัน

นี่คือเรื่องราวของหงส์ดำทั้งหมดอีกครั้ง หากคุณยังไม่เคยเห็นใครไม่ได้หมายความว่าพวกเขาไม่มีตัวตน หวังว่าในกรณีของคุณมันจะไม่นำไปสู่วิกฤติการเงินโลกกว้างอีกต่อไปสำหรับลูกค้าที่ไม่มีความสุข

Postgres เอกสารกล่าวว่านี้อย่างชัดเจน:

หากไม่ได้รับ ORDER BY แถวจะถูกส่งคืนตามลำดับที่ระบบค้นหาได้เร็วที่สุดในการสร้าง

"ระบบ" ในกรณีนี้ประกอบด้วย postgres ภูตตัวเอง (รวมถึงการดำเนินการตามวิธีการเข้าถึงข้อมูลและเพิ่มประสิทธิภาพการค้นหา) ระบบปฏิบัติการที่รองรับรูปแบบตรรกะและทางกายภาพของการจัดเก็บฐานข้อมูลอาจยังแคช CPU เนื่องจากคุณในฐานะผู้ใช้ฐานข้อมูลไม่สามารถควบคุมสแต็กนั้นได้คุณไม่ควรพึ่งพามันต่อไปเพื่อให้ทำงานได้อย่างต่อเนื่องในลักษณะที่มันทำงานในนาทีนี้

เพื่อนร่วมงานของคุณจะกระทำเข้าใจผิดรีบร้อนทั่วไป เพื่อพิสูจน์จุดของพวกเขามันก็เพียงพอที่จะแสดงให้เห็นว่าการสันนิษฐานของพวกเขานั้นผิดเพียงครั้งเดียวเช่นโดยdbfiddleนี้

ลองพิจารณาตัวอย่างต่อไปนี้โดยที่เรามีสามตารางที่เกี่ยวข้อง คำสั่งซื้อผู้ใช้และรายละเอียดการสั่งซื้อ OrderDetails ถูกเชื่อมโยงกับกุญแจต่างประเทศไปยังตารางคำสั่งซื้อและตารางผู้ใช้ นี่คือการตั้งค่าทั่วไปสำหรับฐานข้อมูลเชิงสัมพันธ์ เนื้อหาวัตถุประสงค์ทั้งหมดของDBMS เชิงสัมพันธ์

USE tempdb;

IF OBJECT_ID(N'dbo.OrderDetails', N'U') IS NOT NULL
DROP TABLE dbo.OrderDetails;

IF OBJECT_ID(N'dbo.Orders', N'U') IS NOT NULL
DROP TABLE dbo.Orders;

IF OBJECT_ID(N'dbo.Users', N'U') IS NOT NULL
DROP TABLE dbo.Users;

CREATE TABLE dbo.Orders
(
    OrderID int NOT NULL
        CONSTRAINT OrderTestPK
        PRIMARY KEY
        CLUSTERED
    , SomeOrderData varchar(1000)
        CONSTRAINT Orders_somedata_df
        DEFAULT (CRYPT_GEN_RANDOM(1000))
);

CREATE TABLE dbo.Users
(
    UserID int NOT NULL
        CONSTRAINT UsersPK
        PRIMARY KEY
        CLUSTERED
    , SomeUserData varchar(1000)
        CONSTRAINT Users_somedata_df
        DEFAULT (CRYPT_GEN_RANDOM(1000))
);

CREATE TABLE dbo.OrderDetails
(
    OrderDetailsID int NOT NULL
        CONSTRAINT OrderDetailsTestPK
        PRIMARY KEY
        CLUSTERED
    , OrderID int NOT NULL
        CONSTRAINT OrderDetailsOrderID
        FOREIGN KEY
        REFERENCES dbo.Orders(OrderID)
    , UserID int NOT NULL
        CONSTRAINT OrderDetailsUserID
        FOREIGN KEY
        REFERENCES dbo.Users(UserID)
    , SomeOrderDetailsData varchar(1000)
        CONSTRAINT OrderDetails_somedata_df
        DEFAULT (CRYPT_GEN_RANDOM(1000))
);

INSERT INTO dbo.Orders (OrderID)
SELECT TOP(100) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM sys.syscolumns sc;

INSERT INTO dbo.Users (UserID)
SELECT TOP(100) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM sys.syscolumns sc;

INSERT INTO dbo.OrderDetails (OrderDetailsID, OrderID, UserID)
SELECT TOP(10000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
    , o.OrderID
    , u.UserID
FROM sys.syscolumns sc
    CROSS JOIN dbo.Orders o
    CROSS JOIN dbo.Users u
ORDER BY NEWID();

CREATE INDEX OrderDetailsOrderID ON dbo.OrderDetails(OrderID);
CREATE INDEX OrderDetailsUserID ON dbo.OrderDetails(UserID);

ที่นี่เรากำลังสอบถามตาราง OrderDetails โดยที่ UserID คือ 15:

SELECT od.OrderDetailsID
    , o.OrderID
    , u.UserID
FROM dbo.OrderDetails od
    INNER JOIN dbo.Users u ON u.UserID = od.UserID
    INNER JOIN dbo.Orders o ON od.OrderID = o.OrderID
WHERE u.UserID = 15

ผลลัพธ์จากแบบสอบถามดูเหมือนว่า:

╔════════════════╦═════════╦════════╗
║ OrderDetailsID ║ OrderID ║ UserID ║
╠════════════════╬═════════╬════════╣
00 2200115 ║ 2 ║ 15 ║
║ 630215 ║ 3 ║ 15 ║
║ 1990215 ║ 3 ║ 15 ║
║ 4960215 ║ 3 ║ 15 ║
║ 100715 ║ 8 ║ 15 ║
║ 3930815 ║ 9 ║ 15 ║
║ 6310815 ║ 9 ║ 15 ║
║ 4441015 ║ 11 ║ 15 ║
║ 2171315 ║ 14 ║ 15 ║
║ 3431415 ║ 15 ║ 15 ║
║ 4571415 ║ 15 ║ 15 ║
║ 6421515 ║ 16 ║ 15 ║
║ 2271715 ║ 18 ║ 15 ║
║ 2601715 ║ 18 ║ 15 ║
║ 3521715 ║ 18 ║ 15 ║
18 221815 ║ 19 ║ 15 ║
║ 3381915 ║ 20 ║ 15 ║
║ 4471915 ║ 20 ║ 15 ║
╚════════════════╩═════════╩════════╝

อย่างที่คุณเห็นลำดับของเอาท์พุทแถวไม่ตรงกับลำดับของแถวในตาราง OrderDetails

การเพิ่มORDER BYแถวชัดเจนจะส่งกลับไปยังลูกค้าตามลำดับที่ต้องการ:

SELECT od.OrderDetailsID
    , o.OrderID
    , u.UserID
FROM dbo.OrderDetails od
    INNER JOIN dbo.Users u ON u.UserID = od.UserID
    INNER JOIN dbo.Orders o ON od.OrderID = o.OrderID
WHERE u.UserID = 15
ORDER BY od.OrderDetailsID;

╔════════════════╦═════════╦════════╗
║ OrderDetailsID ║ OrderID ║ UserID ║
╠════════════════╬═════════╬════════╣
║ 3915 ║ 40 ║ 15 ║
║ 100715 ║ 8 ║ 15 ║
18 221815 ║ 19 ║ 15 ║
║ 299915 ║ 100 ║ 15 ║
║ 368215 ║ 83 ║ 15 ║
║ 603815 ║ 39 ║ 15 ║
║ 630215 ║ 3 ║ 15 ║
║ 728515 ║ 86 ║ 15 ║
║ 972215 ║ 23 ║ 15 ║
║ 992015 ║ 21 ║ 15 ║
║ 1017115 ║ 72 ║ 15 ║
║ 1113815 ║ 39 ║ 15 ║
╚════════════════╩═════════╩════════╝

หากคำสั่งของแถวมีความจำเป็นและวิศวกรของคุณรู้ว่าคำสั่งนั้นมีความจำเป็นพวกเขาควรจะต้องการใช้ORDER BYคำสั่งเพียงอย่างเดียวเนื่องจากอาจทำให้พวกเขาต้องเสียค่าใช้จ่ายหากพวกเขามีข้อผิดพลาดที่เกี่ยวข้องกับคำสั่งที่ไม่ถูกต้อง

ตัวอย่างที่สองอาจเป็นคำแนะนำเพิ่มเติมโดยใช้OrderDetailsตารางจากด้านบนซึ่งเราไม่ได้เข้าร่วมตารางอื่น ๆ แต่มีข้อกำหนดง่าย ๆ ในการค้นหาแถวที่ตรงกับทั้งรหัสผู้ใช้และรหัสผู้ใช้เราเห็นปัญหา

เราจะสร้างดัชนีเพื่อสนับสนุนการสืบค้นตามที่คุณน่าจะทำในชีวิตจริงหากประสิทธิภาพนั้นสำคัญไม่ว่าจะเป็นอย่างไร

CREATE INDEX OrderDetailsOrderIDUserID ON dbo.OrderDetails(OrderID, UserID);

นี่คือแบบสอบถาม:

SELECT od.OrderDetailsID
FROM dbo.OrderDetails od
WHERE od.OrderID = 15
    AND (od.UserID = 21 OR od.UserID = 22)

และผลลัพธ์:

╔════════════════╗
║ OrderDetailsID ║
╠════════════════╣
║ 21421 ║
║ 5061421 ║
║ 7091421 ║
║ 691422 ║
║ 3471422 ║
║ 7241422 ║
╚════════════════╝

การเพิ่มส่วนORDER BYคำสั่งจะช่วยให้แน่ใจว่าเราจะได้รับการจัดเรียงที่ถูกต้องที่นี่เช่นกัน

ตัวอย่างเหล่านี้เป็นเพียงตัวอย่างง่ายๆที่ไม่รับประกันว่าแถวจะ "อยู่ในลำดับ" โดยไม่มีORDER BYคำสั่งที่ชัดเจน มีตัวอย่างอีกมากมายเช่นนี้และเนื่องจากรหัสเครื่องยนต์ DBMS มีการเปลี่ยนแปลงค่อนข้างบ่อยลักษณะการทำงานที่เฉพาะเจาะจงอาจเปลี่ยนแปลงตลอดเวลา

เป็นตัวอย่างที่ใช้งานได้จริงใน Postgres ลำดับปัจจุบันจะเปลี่ยนเมื่อคุณอัปเดตแถว:

% SELECT * FROM mytable;
 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  5 | f
  6 | g
  7 | h
  8 | i
  9 | j
(10 rows)

% UPDATE mytable SET data = 'ff' WHERE id = 5;
UPDATE 1
% SELECT * FROM mytable;
 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  6 | g
  7 | h
  8 | i
  9 | j
  5 | ff
(10 rows)

ฉันไม่คิดว่ากฎของการสั่งซื้อโดยปริยายที่มีอยู่นี้จะถูกบันทึกไว้ที่ใดก็ได้และอาจมีการเปลี่ยนแปลงได้โดยไม่ต้องแจ้งให้ทราบล่วงหน้าและไม่ใช่พฤติกรรมแบบพกพาในเครื่องมือ DB

ไม่ใช่ตัวอย่าง แต่ยาวเกินไปสำหรับความคิดเห็น

บนโต๊ะขนาดใหญ่ฐานข้อมูลบางส่วนจะทำการสแกนแบบขนาน interleaved:

หากแบบสอบถามสองรายการต้องการสแกนตารางเดียวกันและมาถึงเกือบจะในเวลาเดียวกันการสืบค้นแรกอาจเป็นส่วนหนึ่งผ่านตารางเมื่อการเริ่มต้นครั้งที่สอง

แบบสอบถามที่สองอาจได้รับระเบียนที่เริ่มต้นจากกลางตาราง (เนื่องจากแบบสอบถามแรกเสร็จสมบูรณ์) จากนั้นรับระเบียนจากจุดเริ่มต้นของตาราง

สร้างดัชนีคลัสเตอร์ที่มีคำสั่ง "ผิด" ID DESCยกตัวอย่างเช่นคลัสเตอร์บน สิ่งนี้มักจะส่งออกลำดับกลับกัน (แม้ว่าจะไม่รับประกันเช่นกัน)