কিভাবে একটি ডাটাবেসে অন্তর্নিহিত আদেশের অভাব প্রমাণ করতে?


21

সম্প্রতি আমি সহকর্মীদের কাছে একটি কলাম থাকার গুরুত্ব ব্যাখ্যা করছিলাম যার সাহায্যে ডাটাবেস টেবিলের মধ্যে ডেটাটি সাজানোর প্রয়োজন হয় যদি উদাহরণস্বরূপ কালানুক্রমিকভাবে অর্ডার করা ডেটার জন্য for এটি কিছুটা কঠিন প্রমাণিত হয়েছিল কারণ তারা সহজেই অবিরাম আপাতদৃষ্টিতে তাদের ক্যোয়ারীটি আবার চালাতে পারে এবং এটি সর্বদা একই ক্রমের একই সারিতে ফিরে আসবে।

আমি এটি আগেও লক্ষ্য করেছি এবং আমি যা করতে পেরেছি তা হ'ল জোর দেওয়া উচিত যে তারা আমাকে বিশ্বাস করে এবং কেবল ধরে নেওয়া যায় না যে একটি ডাটাবেস টেবিলটি একটি aতিহ্যবাহী সিএসভি বা এক্সেল ফাইলের মতো আচরণ করবে।

উদাহরণস্বরূপ, (পোস্টগ্রাইএসকিউএল) কোয়েরি কার্যকর করা হচ্ছে

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)

আমি এটি বারবার করতে পারি এবং এটি সর্বদা একই ক্রমে একই ডেটা আমার কাছে ফিরে আসবে। তবে আমি জানি যে এই অন্তর্নিহিত আদেশটি ভেঙে যেতে পারে, আমি এটি আগে দেখেছি, বিশেষত বড় ডেটাসেটগুলিতে, যেখানে কিছু এলোমেলো মান নির্বাচন করার সময় স্পষ্টতই "ভুল" জায়গায় ফেলে দেওয়া হবে। তবে আমার কাছে এটি ঘটেছে যে আমি জানি না এটি কীভাবে হয় বা কীভাবে এটি পুনরুত্পাদন করতে হয়। গুগলে ফলাফল পেতে আমার অসুবিধা হয়েছে কারণ অনুসন্ধান কোয়েরিতে ফলাফল সেটগুলি বাছাইয়ের ক্ষেত্রে কেবল সাধারণ সহায়তা ফিরে আসে।

সুতরাং, আমার প্রশ্নগুলি মূলত এগুলি:

  1. আমি কীভাবে প্রদর্শিত এবং দৃ concrete়তার সাথে প্রমাণ করতে পারি যে কোনও ORDER BYবিবৃতি ছাড়াই সন্ধানের সারিগুলির রিটার্ন ক্রম নির্ভরযোগ্য নয়, পছন্দসই প্রশ্নে সারণীটি আপডেট না করা বা সম্পাদিত না হওয়া সত্ত্বেও অন্তর্নিহিত আদেশের একটি ভাঙ্গন সৃষ্টি করে এবং প্রদর্শন করে ?

  2. ডেটা কেবলমাত্র একবার ম্যাসে প্রবেশ করানো এবং তারপরে আর কখনও আপডেট না করা থাকলে এগুলি কি কোনও পার্থক্য করে?

আমি পোস্টগ্র্রেস-ভিত্তিক উত্তরটি পছন্দ করবো কারণ এটির সাথে আমি সবচেয়ে বেশি পরিচিত তবে তত্ত্বের ক্ষেত্রে আমি আরও আগ্রহী।


6
"আর কখনও লিখিত বা আপডেট হয়নি" - এটি একটি টেবিল কেন? একটি ফাইল মত শব্দ। বা একটি এনাম। বা এমন কিছু যা ডাটাবেসে থাকা দরকার নেই। যদি এটি কালানুক্রমিক হয়, আদেশের জন্য কোনও তারিখের কলাম নেই? কালানুক্রমিক বিষয়গুলি যদি আপনি মনে করেন যে তথ্যটি সারণীতে থাকার জন্য যথেষ্ট গুরুত্বপূর্ণ হবে। যাইহোক, কেউ নতুন সূচক বাদ দেওয়া বা তৈরি করার কারণে বা মেমরির পরিবর্তনের মতো ঘটনা, পতাকাগুলি চিহ্নিত করতে বা অন্যান্য প্রভাবগুলির কারণে পরিকল্পনা পরিবর্তন হতে পারে। মত "। আমি আমার seatbelt কখনো পরতে এবং আমি আমার উইন্ডশীল্ড মাধ্যমে চলে না করেছি, তাই আমি আমার seatbelt না পরা অব্যাহত থাকবে" :-( তাদের যুক্তি শব্দসমূহ
হারুন বারট্রান্ড

9
কিছু যুক্তিযুক্ত সমস্যাগুলি কেবল প্রযুক্তিগতভাবে বা এইচআর জড়িত ছাড়া সমাধান করা যায় না। যদি আপনার সংস্থা যদি বিকাশকারী অনুশীলনগুলিকে ভুডুতে বিশ্বাস এবং ডকুমেন্টেশন উপেক্ষা করার উপর নির্ভর করে এবং আপনার ব্যবহারের ঘটনাটি এমন একটি ছোট টেবিলের মধ্যে সীমাবদ্ধ থাকে যা কখনই আপডেট হয় না, তবে তাদের উপায় থাকতে দিন এবং আপনার জীবনবৃত্তিকে আপডেট করুন। এটি তর্ক করার মতো নয়।
অ্যারন বারট্র্যান্ড

1
আপনার কাছে "সর্বদা থাকবে" দাবি করার কোনও ভিত্তি নেই। আপনি কেবল "সর্বদা আছে", "যখন আমি পরীক্ষা করে দেখি" দাবি করতে পারি। ভাষার একটি সংজ্ঞা রয়েছে - এটি ব্যবহারকারীর সাথে চুক্তি।
ফিলিপ্সি

10
আমি আগ্রহী যে আপনার এই সহকর্মীরা কেনorder by তাদের অনুসন্ধানগুলিতে ধারা যুক্ত করার বিরোধিতা করছেন ? তারা কি সোর্স কোড স্টোরেজে সংরক্ষণ করার চেষ্টা করছে? কীবোর্ড পরা এবং টিয়ার? ভয়ঙ্কর ধারাটি টাইপ করতে সময় লাগে?
মোস্তাকাসিও

2
আমি সবসময়ই ভেবেছিলাম যে ডাটাবেস ইঞ্জিনগুলি এলোমেলোভাবে প্রথম কয়েক সারি ক্যোয়ারির ক্রমগুলি অনুমোদন করা উচিত যার জন্য শব্দার্থবিজ্ঞান কোনও আদেশের গ্যারান্টি দেয় না, পরীক্ষার সুবিধার্থে সহায়তা করে।
ডগ ম্যাকক্লেইন

উত্তর:


30

আমি তাদের বোঝানোর চেষ্টা করার তিনটি উপায় দেখছি:

  1. তাদের একই জিজ্ঞাসাটি চেষ্টা করে দেখতে দিন তবে বড় টেবিল (সারিগুলির আরও সংখ্যক) সহ বা টেবিলে কার্যকর করার সময় টেবিলটি আপডেট করা হচ্ছে। অথবা নতুন সারি areোকানো হয় এবং কিছু পুরানো মুছে ফেলা হয়। অথবা মৃত্যুদন্ড কার্যকর করার মধ্যে একটি সূচক যুক্ত করা বা সরিয়ে দেওয়া হয়। অথবা টেবিলটি শূন্য হয়েছে (পোস্টগ্রিসে)। বা সূচীগুলি পুনর্নির্মাণ করা হয় (এসকিউএল সার্ভারে)। অথবা টেবিলটি ক্লাস্টার থেকে একটি গাদা হয়ে গেছে। অথবা ডাটাবেস পরিষেবা পুনরায় চালু করা হয়।

  2. আপনি পরামর্শ দিতে পারেন যে তারা প্রমাণ করেছে যে বিভিন্ন ফাঁসি কার্যকর একই আদেশ দেয়। তারা কি তা প্রমাণ করতে পারে? তারা কি এমন একাধিক পরীক্ষার টেস্ট সরবরাহ করতে পারে যা প্রমাণ করে যে কোনও জিজ্ঞাসা কতবার কার্যকর করা হলেও তা একই ক্রমে ফলাফল দেবে?

  3. এক্ষেত্রে বিভিন্ন ডিবিএমএসের ডকুমেন্টেশন সরবরাহ করুন। উদাহরণ স্বরূপ:

পোস্টগ্র্যাস এসকিউএল :

সারি বাছাই করা হচ্ছে

কোনও জিজ্ঞাসা একটি আউটপুট টেবিল তৈরি করার পরে (নির্বাচনী তালিকাটি প্রক্রিয়া করার পরে) এটি allyচ্ছিকভাবে বাছাই করা যায়। যদি বাছাই না করা হয়, সারিগুলি একটি অনির্দিষ্ট ক্রমে ফিরে আসবে। সেক্ষেত্রে প্রকৃত অর্ডার স্ক্যানের উপর নির্ভর করবে এবং পরিকল্পনার ধরণ এবং ডিস্কের অর্ডারে যোগ দেবে, তবে এটির উপর নির্ভর করা উচিত নয়। একটি নির্দিষ্ট আউটপুট অর্ডারিং কেবলমাত্র গ্যারান্টিযুক্ত হতে পারে যদি সাজানোর পদক্ষেপটি স্পষ্টভাবে চয়ন করা হয়।

এসকিউএল সার্ভার :

SELECT- ORDER BYধারা (লেনদেন-এসকিউএল)

এসকিউএল সার্ভারে কোয়েরিতে ডেটা সাজানো। এই ধারাটি ব্যবহার করুন:

নির্দিষ্ট কলাম তালিকা অনুসারে একটি কোয়েরির ফলাফল সেট অর্ডার করুন এবং optionচ্ছিকভাবে সারিগুলি নির্দিষ্ট ব্যাপ্তিতে সীমাবদ্ধ করুন। ফলস সেটটিতে সারিগুলি যে ক্রমে ফিরে আসে সেটির গ্যারান্টি দেওয়া হয় না যদি না কোনও ORDER BYধারা নির্দিষ্ট না করা হয়।

ওরাকল :

order_by_clause

ORDER BYবিবৃতি দিয়ে ফিরে আসা সারিগুলিকে অর্ডার করতে ক্লজটি ব্যবহার করুন । অর্ডার_বাই_ক্লেজ ব্যতীত কোনও গ্যারান্টি উপস্থিত নেই যে একই ক্যোয়ারী একাধিকবার কার্যকর করা একই ক্রমে সারিগুলি পুনরুদ্ধার করবে।


খুব ছোট টেবিল যে পরিবর্তন করা হয় সঙ্গে, আপনি হতে পারে এই আচরণ দেখুন। এটা প্রত্যাশিত তবে এটিরও গ্যারান্টি নেই। অর্ডার পরিবর্তন হতে পারে কারণ আপনি একটি সূচক যুক্ত করেছেন বা আপনি একটি সূচি সংশোধন করেছেন বা আপনি ডাটাবেস পুনরায় শুরু করেছেন এবং সম্ভবত অন্যান্য অনেকগুলি ক্ষেত্রে।
ypercubeᵀᴹ

6
যদি অর্ডারটি গুরুত্বপূর্ণ হয়ে থাকে, তবে তাদের কোড পর্যালোচনা করার জন্য যিনি সর্বদা দায়বদ্ধ তিনি যতক্ষণ না তারা অর্ডার ব্যবহার করেন ততক্ষণ প্রত্যাখ্যান করা উচিত। ডিবিএমএসের বিকাশকারীরা (ওরাকল, এসকিউএল সার্ভার, পোস্টগ্রিস) সকলেই তাদের পণ্যের গ্যারান্টিস এবং কোনটি নয় (এবং তাদের আমার চেয়ে অনেক বেশি অর্থ প্রদান করা হয়, তাই তারা জানে যে তারা কী বলছে, এই জঘন্য নির্মাণের পাশাপাশি কিছু)।
ypercubeᵀᴹ

1
এমনকি যদি আদেশটি এখন একই রকম হয় তবে এটি কি নিশ্চিত যে আপনি যে সফ্টওয়্যারটি তৈরি করছেন তার পুরো জীবনকালে এই টেবিলগুলি কখনই আপডেট হবে না? আর কোনও সারি owsোকানো হবে না, কখনও?
ypercubeᵀᴹ

1
এই টেবিলটি সর্বদা এই ছোট হবে কি গ্যারান্টি আছে? গ্যারান্টি আছে যে আর কোনও কলাম যুক্ত হবে না? আমি দশ সহস্র বিভিন্ন কেস দেখতে পাচ্ছি যেখানে ভবিষ্যতে টেবিলটি পরিবর্তন করা যেতে পারে (এবং এর কিছু পরিবর্তন কোনও প্রশ্নের ফলাফলের ক্রমকে প্রভাবিত করতে পারে)। আমি আপনাকে তাদের এই সমস্তটির উত্তর দিতে বলার পরামর্শ দিচ্ছি। তারা কি গ্যারান্টি দিতে পারে যে এর আগে কখনও ঘটবে না? এবং কেন তারা সরল যুক্ত করবেন না ORDER BY, যা আদেশের গ্যারান্টি দেবে, টেবিলটি কীভাবে পরিবর্তিত হচ্ছে তা বিবেচনা করে না ? কেন কোনও নিরাপদ যুক্ত নেই, যা কোনও ক্ষতি করে না?
ypercubeᵀᴹ

10
ডকুমেন্টেশন পর্যাপ্ত হওয়া উচিত। অন্য যে কোনও কিছুই দ্বিতীয় অনুমান করা হয় এবং যে কোনও হারে আপনি কখনই প্রমাণিত হোন না কেন কখনও তাকে চূড়ান্ত হিসাবে দেখা যাবে না। এটি সর্বদা এমন কিছু হবে যা আপনি করেছেন এবং ব্যাখ্যাযোগ্য, সম্ভবত আপনার ব্যয়ে, যা কিছু তার চেয়ে বেশি । ডকুমেন্টেশন সহ সশস্ত্র, আপনার "ওয়্যারেন্টি" লিখিতভাবে জমা দিন, এবং প্রয়োজনীয় ক্রমে সারিগুলি না ফেরানোর জন্য কেবল লিখিত অনুমতি চাইতে (আপনি এটি পাবেন না)।

19

এটি আবার কালো রাজহাঁসের গল্প। আপনি যদি এখনও না দেখে থাকেন তবে এর অর্থ এই নয় যে তাদের উপস্থিতি নেই। আশা করি আপনার ক্ষেত্রে এটি আর কিছু বিশ্বব্যাপী আর্থিক সংকট ঘটাবে না, কেবলমাত্র কিছু অসন্তুষ্ট গ্রাহকদের কাছে।

পোস্টগ্রিজ ডকুমেন্টেশন এটিকে স্পষ্ট করে বলেছে :

যদি অর্ডার দেওয়া না হয় তবে সিস্টেমটি সবচেয়ে দ্রুত উত্পাদন করতে সন্ধান করে সারিগুলি ফিরিয়ে দেওয়া হয়।

এই ক্ষেত্রে "সিস্টেম" পোস্টগ্র্রেস ডিমন নিজেই রয়েছে (এর ডেটা অ্যাক্সেস পদ্ধতি এবং ক্যোয়ারী অপ্টিমাইজার বাস্তবায়ন সহ), অন্তর্নিহিত অপারেটিং সিস্টেম, ডাটাবেস স্টোরেজটির যৌক্তিক এবং শারীরিক বিন্যাস, সম্ভবত এমনকি সিপিইউ ক্যাশে রয়েছে। যেহেতু ডাটাবেস ব্যবহারকারী হিসাবে আপনার এই স্ট্যাকের কোনও নিয়ন্ত্রণ নেই তাই আপনি এই মুহুর্তে যেভাবে আচরণ করেন তা চিরতরে আচরণ করা চালিয়ে যাওয়া উচিত নয়।

আপনার সহকর্মীরা হুট করে সাধারণীকরণের ত্রুটিপূর্ণ প্রতিশ্রুতি দিচ্ছেন । তাদের বক্তব্যকে অস্বীকার করার জন্য এটি দেখানোর পক্ষে যথেষ্ট যে তাদের অনুমান কেবল একবারেই ভুল হয়েছে, যেমন এই ডিবিফিডাল দ্বারা ।


12

নিম্নলিখিত উদাহরণটি বিবেচনা করুন, যেখানে আমাদের তিনটি সম্পর্কিত সারণী রয়েছে। অর্ডার, ব্যবহারকারী এবং অর্ডারডেটেলস। অর্ডারডেটেলগুলি অর্ডার সারণিতে এবং ব্যবহারকারীদের সারণীর সাথে বিদেশী কীগুলির সাথে যুক্ত। এটি মূলত রিলেশনাল ডাটাবেসের জন্য খুব সাধারণ সেটআপ; যুক্তিযুক্তভাবে একটি রিলেশনাল ডিবিএমএসের পুরো উদ্দেশ্য ।

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);

এখানে, আমরা অর্ডার বিবরণ টেবিলটি জিজ্ঞাসা করছি যেখানে ইউজারআইডি 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

ক্যোয়ারী থেকে আউটপুট দেখে মনে হচ্ছে:

╔════════════════╦═════════╦════════╗
║ অর্ডারডেটেলসআইডি ║ অর্ডারআইডি ║ ইউজারআইডি ║
╠════════════════╬═════════╬════════╣
00 2200115 ║ 2 ║ 15 ║ ║
║ 630215 ║ 3 ║ 15 ║ ║
║ 1990215 ║ 3 ║ 15 ║ ║
60 4960215 ║ 3 ║ 15 ║ ║
║ 100715 ║ 8 ║ 15 ║
║ 3930815 ║ 9 ║ 15 ║
10 6310815 ║ 9 ║ 15 ║
║ 4441015 ║ 11 ║ 15 ║ ║
7 2171315 ║ 14 ║ 15 ║ ║
3 3431415 ║ 15 ║ 15 ║ ║
7 4571415 ║ 15 ║ 15 ║ ║
21 6421515 ║ 16 ║ 15 ║ ║
7 2271715 ║ 18 ║ 15 ║ ║
0 2601715 ║ 18 ║ 15 ║ ║
21 3521715 ║ 18 ║ 15 ║ ║
18 221815 ║ 19 ║ 15 ║
8 3381915 ║ 20 ║ 15 ║
7 4471915 ║ 20 ║ 15 ║
╚════════════════╩═════════╩════════╝

আপনি দেখতে পাচ্ছেন, সারি আউটপুট ক্রমটি অর্ডারডেটেল সারণিতে সারিগুলির ক্রমের সাথে মেলে না।

একটি স্পষ্ট যোগ করা 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;
╔════════════════╦═════════╦════════╗
║ অর্ডারডেটেলসআইডি ║ অর্ডারআইডি ║ ইউজারআইডি ║
╠════════════════╬═════════╬════════╣
║ 3915 ║ 40 ║ 15 ║
║ 100715 ║ 8 ║ 15 ║
18 221815 ║ 19 ║ 15 ║
99 299915 ║ 100 ║ 15 ║
║ 368215 ║ 83 ║ 15 ║ ║
38 603815 ║ 39 ║ 15 ║
║ 630215 ║ 3 ║ 15 ║ ║
85 728515 ║ 86 ║ 15 ║ ║
72 972215 ║ 23 ║ 15 ║ ║
║ 992015 ║ 21 ║ 15 ║ ║
17 1017115 ║ 72 ║ 15 ║
13 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)

এবং ফলাফল:

╔════════════════╗
║ অর্ডারডেটেলসআইডি ║
╠════════════════╣
4 21421 ║
6 5061421 ║
║ 7091421 ║
14 691422 ║
║ 3471422 ║
24 7241422 ║
╚════════════════╝

একটি ORDER BYধারা যুক্ত করা অবশ্যই নিশ্চিত করবে যে আমরা এখানেও সঠিক ক্রমটি পেয়েছি।

এই মক-আপগুলি কেবল সহজ উদাহরণ যেখানে সারিগুলি সুস্পষ্ট ORDER BYবিবৃতি ব্যতীত "ক্রম" হওয়ার নিশ্চয়তা দেয় না । এর মতো আরও অনেক উদাহরণ রয়েছে এবং যেহেতু ডিবিএমএস ইঞ্জিন কোডটি বেশ ঘন ঘন পরিবর্তিত হয়, নির্দিষ্ট আচরণ সময়ের সাথে সাথে পরিবর্তিত হতে পারে।


10

ব্যবহারিক উদাহরণ হিসাবে, পোস্টগ্রিসে, আপনি যখন একটি সারি আপডেট করেন তখন অর্ডারটি পরিবর্তিত হয়:

% 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)

আমি মনে করি না যে এই বিদ্যমান অন্তর্নিহিত আদেশের নিয়মগুলি কোথাও নথিভুক্ত করা হয়েছে, অবশ্যই কোনও বিজ্ঞপ্তি ছাড়াই পরিবর্তিত হতে পারে এবং এটি অবশ্যই ডিবি ইঞ্জিনগুলিতে বহনযোগ্য আচরণ নয়।


এটা তোলে হয় নথিভুক্ত: ypercube এর উত্তর ডকুমেন্টেশন আমাদের বলার যাতে অনির্দিষ্ট উদ্ধৃতি।
মনিকার সাথে লাইটনেস রেস

@ লাইটনেসেসেসিন অরবিট আমি নথি হিসাবে স্পষ্টভাবে আমাদের বলছি যে এটি নথিভুক্ত নয় বলে গ্রহণ করব। আমি বলতে চাইছি, এটিও সত্য যে ডকুমেন্টেশনের মধ্যে যা কিছু নেই তা অনির্ধারিত। এটি এক ধরণের টোটোলজি। যাইহোক, আমি উত্তরটির সেই অংশটি আরও নির্দিষ্ট করে সম্পাদনা করেছি।
জোল

3

ঠিক একটি ডেমো নয়, তবে একটি মন্তব্যের জন্য খুব দীর্ঘ for

বড় টেবিলগুলিতে কিছু ডাটাবেস আন্তঃবাহিত সমান্তরাল স্ক্যান করবে:

যদি দুটি প্রশ্ন একই টেবিলটি স্ক্যান করতে চায় এবং প্রায় একই সময়ে উপস্থিত হয়, দ্বিতীয়টি শুরু হওয়ার পরে প্রথমটি টেবিলের মধ্য দিয়ে প্রথম অংশ হতে পারে।

দ্বিতীয় ক্যোয়ারীটি টেবিলের মাঝামাঝি থেকে শুরু হওয়া রেকর্ডগুলি গ্রহণ করতে পারে (যেমন প্রথম ক্যোয়ারীটি সমাপ্ত হচ্ছে) এবং তারপরে সারণির শুরু থেকে রেকর্ডগুলি গ্রহণ করতে পারে।


2

একটি ক্লাস্টার্ড সূচক তৈরি করুন যাতে "ভুল" অর্ডার রয়েছে। উদাহরণস্বরূপ, ক্লাস্টার চালু ID DESC। এটি প্রায়শই বিপরীত ক্রমটিকে আউটপুট দেয় (যদিও এটির কোনও গ্যারান্টিযুক্ত নয়)।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.