Chuyển sang int mysql

Hầu hết các công cụ cơ sở dữ liệu SQL (mọi công cụ cơ sở dữ liệu SQL khác với SQLite, theo như chúng tôi biết) đều sử dụng kiểu gõ tĩnh, cứng nhắc. Với kiểu nhập tĩnh, kiểu dữ liệu của một giá trị được xác định bởi vùng chứa của nó - cột cụ thể trong đó giá trị được lưu trữ

SQLite sử dụng một hệ thống kiểu động tổng quát hơn. Trong SQLite, kiểu dữ liệu của một giá trị được liên kết với chính giá trị đó, không phải với vùng chứa của nó. Hệ thống kiểu động của SQLite tương thích ngược với các hệ thống kiểu tĩnh phổ biến hơn của các công cụ cơ sở dữ liệu khác theo nghĩa là các câu lệnh SQL hoạt động trên cơ sở dữ liệu kiểu tĩnh hoạt động theo cùng một cách trong SQLite. Tuy nhiên, kiểu gõ động trong SQLite cho phép nó thực hiện những việc không thể thực hiện được trong cơ sở dữ liệu kiểu cứng nhắc truyền thống. Gõ linh hoạt là một tính năng của SQLite, không phải lỗi

Cập nhật. Kể từ phiên bản 3. 37. 0 (27-11-2021), SQLite cung cấp các bảng STRICT thực thi kiểu cứng nhắc, dành cho các nhà phát triển thích kiểu đó

Mỗi giá trị được lưu trữ trong cơ sở dữ liệu SQLite (hoặc được thao tác bởi công cụ cơ sở dữ liệu) có một trong các lớp lưu trữ sau

• VÔ GIÁ TRỊ. Giá trị là giá trị NULL

• số nguyên. Giá trị là một số nguyên có dấu, được lưu trữ trong 0, 1, 2, 3, 4, 6 hoặc 8 byte tùy thuộc vào độ lớn của giá trị

• THỰC. Giá trị là một giá trị dấu phẩy động, được lưu trữ dưới dạng số dấu phẩy động IEEE 8 byte

• CHỮ. Giá trị là một chuỗi văn bản, được lưu trữ bằng mã hóa cơ sở dữ liệu (UTF-8, UTF-16BE hoặc UTF-16LE)

• BÃI. Giá trị là một đốm dữ liệu, được lưu trữ chính xác như khi nhập

Một lớp lưu trữ tổng quát hơn một kiểu dữ liệu. Ví dụ, lớp lưu trữ INTEGER bao gồm 7 kiểu dữ liệu số nguyên khác nhau với độ dài khác nhau. Điều này tạo ra sự khác biệt trên đĩa. Nhưng ngay sau khi các giá trị INTEGER được đọc khỏi đĩa và vào bộ nhớ để xử lý, chúng sẽ được chuyển đổi thành kiểu dữ liệu chung nhất (số nguyên có dấu 8 byte). Và do đó, phần lớn, "lớp lưu trữ" không thể phân biệt được với "kiểu dữ liệu" và hai thuật ngữ này có thể được sử dụng thay thế cho nhau

Bất kỳ cột nào trong cơ sở dữ liệu SQLite phiên bản 3, ngoại trừ cột INTEGER PRIMARY KEY, đều có thể được sử dụng để lưu trữ giá trị của bất kỳ lớp lưu trữ nào

Tất cả các giá trị trong các câu lệnh SQL, cho dù chúng là các ký tự được nhúng trong văn bản câu lệnh SQL hay các tham số được liên kết với các câu lệnh SQL được biên dịch trước đều có một lớp lưu trữ ngầm định. Trong các trường hợp được mô tả bên dưới, công cụ cơ sở dữ liệu có thể chuyển đổi các giá trị giữa các lớp lưu trữ số (INTEGER và REAL) và TEXT trong khi thực hiện truy vấn

2. 1. Kiểu dữ liệu Boolean

SQLite không có lớp lưu trữ Boolean riêng. Thay vào đó, các giá trị Boolean được lưu trữ dưới dạng số nguyên 0 (sai) và 1 (đúng)

SQLite nhận ra các từ khóa "TRUE" và "FALSE", kể từ phiên bản 3. 23. 0 (2018-04-02) nhưng những từ khóa đó thực sự chỉ là cách viết thay thế cho các số nguyên lần lượt là 1 và 0

2. 2. Kiểu dữ liệu ngày và giờ

SQLite không có lớp lưu trữ dành riêng để lưu trữ ngày và/hoặc thời gian. Thay vào đó, các Hàm Ngày và Giờ tích hợp của SQLite có khả năng lưu trữ ngày và giờ dưới dạng các giá trị VĂN BẢN, THỰC hoặc SỐ

• TEXT dưới dạng chuỗi ISO8601 ("YYYY-MM-DD HH. MM. SS. SSS")
• REAL như số ngày Julian, số ngày kể từ trưa ở Greenwich ngày 24 tháng 11 năm 4714 B. C. theo lịch Gregorian proleptic
• INTEGER dưới dạng Unix Time, số giây kể từ 1970-01-01 00. 00. 00 UTC

Các ứng dụng có thể chọn lưu trữ ngày và giờ ở bất kỳ định dạng nào trong số này và tự do chuyển đổi giữa các định dạng bằng cách sử dụng chức năng ngày và giờ tích hợp

Các công cụ cơ sở dữ liệu SQL sử dụng kiểu gõ cứng nhắc thường sẽ cố gắng tự động chuyển đổi các giá trị thành kiểu dữ liệu thích hợp. Xem xét điều này

CREATE TABLE t1(a INT, b VARCHAR(10));
INSERT INTO t1(a,b) VALUES('123',456);

Cơ sở dữ liệu được gõ cứng nhắc sẽ chuyển đổi chuỗi '123' thành số nguyên 123 và số nguyên 456 thành chuỗi '456' trước khi thực hiện thao tác chèn

Để tối đa hóa khả năng tương thích giữa SQLite và các công cụ cơ sở dữ liệu khác, đồng thời để ví dụ trên sẽ hoạt động trên SQLite giống như trên các công cụ cơ sở dữ liệu SQL khác, SQLite hỗ trợ khái niệm "mối quan hệ kiểu" trên các cột. Mối quan hệ loại của một cột là loại được khuyến nghị cho dữ liệu được lưu trữ trong cột đó. Ý tưởng quan trọng ở đây là loại được khuyến nghị, không bắt buộc. Bất kỳ cột nào vẫn có thể lưu trữ bất kỳ loại dữ liệu nào. Chỉ là một số cột, được lựa chọn, sẽ thích sử dụng một lớp lưu trữ hơn một lớp lưu trữ khác. Lớp lưu trữ ưa thích cho một cột được gọi là "mối quan hệ" của nó

Mỗi cột trong cơ sở dữ liệu SQLite 3 được gán một trong các kiểu tương đồng sau

• CHỮ
• SỐ
• số nguyên
• THỰC
• BÃI

(Ghi chú lịch sử. Mối quan hệ loại "BLOB" từng được gọi là "KHÔNG". Nhưng thuật ngữ đó rất dễ nhầm lẫn với "không có mối quan hệ" và vì vậy nó đã được đổi tên thành. )

Một cột có mối quan hệ TEXT lưu trữ tất cả dữ liệu bằng cách sử dụng các lớp lưu trữ NULL, TEXT hoặc BLOB. Nếu dữ liệu số được chèn vào một cột có mối quan hệ TEXT, nó sẽ được chuyển đổi thành dạng văn bản trước khi được lưu trữ

Một cột có ái lực NUMERIC có thể chứa các giá trị sử dụng tất cả năm lớp lưu trữ. Khi dữ liệu văn bản được chèn vào cột NUMERIC, lớp lưu trữ của văn bản được chuyển đổi thành INTEGER hoặc REAL (theo thứ tự ưu tiên) nếu văn bản tương ứng là số nguyên hoặc số thực được định dạng tốt. Nếu giá trị TEXT là một số nguyên được định dạng tốt, quá lớn để vừa với số nguyên có dấu 64 bit, thì nó sẽ được chuyển đổi thành REAL. Đối với các chuyển đổi giữa các lớp lưu trữ VĂN BẢN và THỰC, chỉ 15 chữ số thập phân có nghĩa đầu tiên của số được giữ lại. Nếu giá trị TEXT không phải là số nguyên hoặc ký tự thực được định dạng tốt, thì giá trị đó được lưu dưới dạng TEXT. Đối với mục đích của đoạn này, các chữ số nguyên thập lục phân không được coi là định dạng tốt và được lưu trữ dưới dạng TEXT. (Điều này được thực hiện để tương thích lịch sử với các phiên bản SQLite trước phiên bản 3. 8. 6 2014-08-15 nơi các số nguyên thập lục phân lần đầu tiên được đưa vào SQLite. ) Nếu một giá trị dấu phẩy động có thể được biểu diễn chính xác dưới dạng số nguyên được chèn vào một cột có ái lực SỐ, thì giá trị đó được chuyển đổi thành số nguyên. Không có nỗ lực nào được thực hiện để chuyển đổi các giá trị NULL hoặc BLOB

Một chuỗi có thể trông giống như một ký tự dấu chấm động với dấu thập phân và/hoặc ký hiệu số mũ nhưng miễn là giá trị có thể được biểu thị dưới dạng số nguyên, mối quan hệ NUMERIC sẽ chuyển đổi nó thành số nguyên. Do đó, chuỗi '3. 0e+5' được lưu trữ trong một cột có ái lực NUMERIC là số nguyên 300000, không phải là giá trị dấu phẩy động 300000. 0

Cột sử dụng mối quan hệ INTEGER hoạt động giống như cột có mối quan hệ SỐ. Sự khác biệt giữa mối quan hệ INTEGER và NUMERIC chỉ rõ ràng trong biểu thức CAST. Biểu thức "CAST(4. 0 AS INT)" trả về một số nguyên 4, trong khi "CAST(4. 0 AS NUMERIC)" để lại giá trị dưới dạng dấu phẩy động 4. 0

Một cột có ái lực REAL hoạt động giống như một cột có ái lực NUMERIC ngoại trừ việc nó buộc các giá trị nguyên thành biểu diễn dấu phẩy động. (Là một tối ưu hóa nội bộ, các giá trị dấu phẩy động nhỏ không có thành phần phân số và được lưu trữ trong các cột có ái lực THỰC được ghi vào đĩa dưới dạng số nguyên để chiếm ít dung lượng hơn và được tự động chuyển đổi trở lại thành dấu phẩy động khi giá trị được đọc ra. Sự tối ưu hóa này hoàn toàn vô hình ở cấp độ SQL và chỉ có thể được phát hiện bằng cách kiểm tra các bit thô của tệp cơ sở dữ liệu. )

Một cột có mối quan hệ BLOB không ưu tiên lớp lưu trữ này hơn lớp lưu trữ khác và không có nỗ lực nào được thực hiện để ép buộc dữ liệu từ lớp lưu trữ này sang lớp lưu trữ khác

3. 1. Xác định ái lực của cột

Đối với các bảng không được khai báo là STRICT, mối quan hệ của một cột được xác định bởi loại cột đã khai báo, theo các quy tắc sau theo thứ tự được hiển thị

1. Nếu kiểu được khai báo chứa chuỗi "INT" thì nó được gán mối quan hệ INTEGER

2. Nếu loại khai báo của cột chứa bất kỳ chuỗi nào trong số các chuỗi "CHAR", "CLOB" hoặc "TEXT" thì cột đó có mối quan hệ với TEXT. Lưu ý rằng loại VARCHAR chứa chuỗi "CHAR" và do đó được gán mối quan hệ TEXT

3. Nếu loại được khai báo cho một cột chứa chuỗi "BLOB" hoặc nếu không có loại nào được chỉ định thì cột đó có mối quan hệ BLOB

4. Nếu loại được khai báo cho một cột chứa bất kỳ chuỗi nào "REAL", "FLOA" hoặc "DOUB" thì cột đó có mối quan hệ THỰC

5. Mặt khác, mối quan hệ là NUMERIC

Lưu ý rằng thứ tự của các quy tắc để xác định ái lực cột là quan trọng. Một cột có loại được khai báo là "CHARINT" sẽ khớp với cả quy tắc 1 và 2 nhưng quy tắc đầu tiên được ưu tiên và do đó mối quan hệ của cột sẽ là INTEGER

3. 1. 1. Ví dụ về tên sở thích

Bảng sau đây cho biết có bao nhiêu tên kiểu dữ liệu phổ biến từ các triển khai SQL truyền thống hơn được chuyển đổi thành các mối quan hệ theo năm quy tắc của phần trước. Bảng này chỉ hiển thị một tập con nhỏ các tên kiểu dữ liệu mà SQLite sẽ chấp nhận. Lưu ý rằng các đối số số trong ngoặc đơn theo sau tên loại (ví dụ:. "VARCHAR(255)") bị SQLite bỏ qua - SQLite không áp đặt bất kỳ giới hạn độ dài nào (ngoài giới hạn SQLITE_MAX_LENGTH toàn cầu lớn) về độ dài của chuỗi, BLOB hoặc giá trị số

Tên kiểu chữ mẫu từ
Câu lệnh CREATE TABLE
hoặc biểu thức CASTResulting AffinityRule được sử dụng để xác định AffinityINT
INTEGERTINYINT
SMALLINT
MEDIUMINT
BIGINT
UNSIGNED BIG INT
INT2
INT8INTEGER1CHARACTER(20)
VARCHAR(255)
VARYING CHARACTER(255)
NCHAR(55)
NATIVE CHARACTER(70)
NVARCHAR(100)
TEXT
CLOBTEXT2BLOB
no datatype specifiedBLOB3REAL
DOUBLE
DOUBLE PRECISION
FLOATREAL4NUMERIC
DECIMAL(10,5)
BOOLEAN
DATE
DATETIMENUMERIC5

Lưu ý rằng một loại "ĐIỂM NỔI" được khai báo sẽ mang lại mối quan hệ INTEGER, không phải mối quan hệ THỰC, do "INT" ở cuối "POINT". Và loại "CHUỖI" đã khai báo có ái lực là SỐ chứ không phải VĂN BẢN

3. 2. Affinity Of Expressions

Mỗi cột trong bảng có một mối quan hệ loại (một trong BLOB, TEXT, INTEGER, REAL hoặc NUMERIC) nhưng các biểu thức không nhất thiết phải có một mối quan hệ

Mối quan hệ biểu hiện được xác định bởi các quy tắc sau

• Toán hạng bên phải của toán tử IN hoặc NOT IN không có ái lực nếu toán hạng là một danh sách hoặc có cùng ái lực với ái lực của biểu thức tập kết quả nếu toán hạng là một SELECT

• Khi một biểu thức là một tham chiếu đơn giản đến một cột của một bảng thực (không phải là VIEW hoặc truy vấn con) thì biểu thức đó có cùng mối quan hệ với cột của bảng

  • Dấu ngoặc quanh tên cột được bỏ qua. Do đó nếu X và Y. Z là tên cột, sau đó (X) và (Y. Z) cũng được coi là tên cột và có ái lực của các cột tương ứng

  • Bất kỳ toán tử nào được áp dụng cho tên cột, bao gồm toán tử đơn nguyên "+" không hoạt động, chuyển đổi tên cột thành một biểu thức luôn không có ái lực. Do đó, ngay cả khi X và Y. Z là tên cột, các biểu thức +X và +Y. Z không phải là tên cột và không có ái lực

• Một biểu thức có dạng "CAST(expr AS type)" có một mối quan hệ giống như một cột có loại được khai báo là "type"

• Toán tử COLLATE có cùng ái lực với toán hạng bên trái của nó

• Mặt khác, một biểu thức không có ái lực

3. 3. Mối quan hệ của cột đối với lượt xem và truy vấn phụ

Các "cột" của truy vấn con VIEW hoặc mệnh đề TỪ thực sự là các biểu thức trong tập kết quả của câu lệnh SELECT thực thi VIEW hoặc truy vấn con. Do đó, mối quan hệ đối với các cột của CHẾ ĐỘ XEM hoặc truy vấn con được xác định theo quy tắc mối quan hệ biểu thức ở trên. Hãy xem xét một ví dụ

CREATE TABLE t1(a INT, b TEXT, c REAL);
CREATE VIEW v1(x,y,z) AS SELECT b, a+c, 42 FROM t1 WHERE b!=11;

Mối quan hệ của v1. cột x sẽ giống như ái lực của t1. b (TEXT), kể từ v1. x ánh xạ trực tiếp vào t1. b. Nhưng cột v1. y và v1. cả z đều không có ái lực, vì các cột đó ánh xạ vào biểu thức a+c và 42, và các biểu thức luôn không có ái lực

3. 3. 1. Mối quan hệ của cột đối với các chế độ xem phức hợp

Khi câu lệnh CHỌN triển khai truy vấn con mệnh đề XEM hoặc mệnh đề TỪ là một CHỌN phức hợp thì mối quan hệ của mỗi cột của CHỌN XEM hoặc truy vấn con sẽ là mối quan hệ của cột kết quả tương ứng đối với một trong các câu lệnh CHỌN riêng lẻ tạo nên mối quan hệ đó. Tuy nhiên, không xác định được câu lệnh CHỌN nào sẽ được sử dụng để xác định mối quan hệ. Các câu lệnh SELECT thành phần khác nhau có thể được sử dụng để xác định mối quan hệ tại các thời điểm khác nhau trong quá trình đánh giá truy vấn. Lựa chọn có thể khác nhau giữa các phiên bản SQLite khác nhau. Lựa chọn có thể thay đổi giữa một truy vấn và truy vấn tiếp theo trong cùng một phiên bản SQLite. Lựa chọn có thể khác nhau vào những thời điểm khác nhau trong cùng một truy vấn. Do đó, bạn không bao giờ có thể chắc chắn mối quan hệ nào sẽ được sử dụng cho các cột của tổ hợp CHỌN có mối quan hệ khác nhau trong truy vấn con cấu thành

Cách tốt nhất là tránh trộn lẫn các mối quan hệ trong một hợp chất CHỌN nếu bạn quan tâm đến kiểu dữ liệu của kết quả. Trộn các mối quan hệ trong một hợp chất CHỌN có thể dẫn đến kết quả đáng ngạc nhiên và không trực quan. Ví dụ, xem bài đăng trên diễn đàn 02d7be94d7

3. 4. Ví dụ về hành vi mối quan hệ của cột

SQL sau minh họa cách SQLite sử dụng mối quan hệ cột để thực hiện chuyển đổi kiểu khi các giá trị được chèn vào bảng

CREATE TABLE t1(
    t  TEXT,     -- text affinity by rule 2
    nu NUMERIC,  -- numeric affinity by rule 5
    i  INTEGER,  -- integer affinity by rule 1
    r  REAL,     -- real affinity by rule 4
    no BLOB      -- no affinity by rule 3
);

-- Values stored as TEXT, INTEGER, INTEGER, REAL, TEXT.
INSERT INTO t1 VALUES('500.0', '500.0', '500.0', '500.0', '500.0');
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
text|integer|integer|real|text

-- Values stored as TEXT, INTEGER, INTEGER, REAL, REAL.
DELETE FROM t1;
INSERT INTO t1 VALUES(500.0, 500.0, 500.0, 500.0, 500.0);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
text|integer|integer|real|real

-- Values stored as TEXT, INTEGER, INTEGER, REAL, INTEGER.
DELETE FROM t1;
INSERT INTO t1 VALUES(500, 500, 500, 500, 500);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
text|integer|integer|real|integer

-- BLOBs are always stored as BLOBs regardless of column affinity.
DELETE FROM t1;
INSERT INTO t1 VALUES(x'0500', x'0500', x'0500', x'0500', x'0500');
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
blob|blob|blob|blob|blob

-- NULLs are also unaffected by affinity
DELETE FROM t1;
INSERT INTO t1 VALUES(NULL,NULL,NULL,NULL,NULL);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
null|null|null|null|null

SQLite version 3 has the usual set of SQL comparison operators including "=", "==", "<", "<=", ">", ">=", "!=", "", "IN", "NOT IN", "BETWEEN", "IS", and "IS NOT", .

4. 1. Thứ tự sắp xếp

Kết quả so sánh phụ thuộc vào các lớp lưu trữ của toán hạng, theo các quy tắc sau

• Một giá trị với lớp lưu trữ NULL được coi là nhỏ hơn bất kỳ giá trị nào khác (bao gồm một giá trị khác với lớp lưu trữ NULL)

• Giá trị INTEGER hoặc REAL nhỏ hơn bất kỳ giá trị TEXT hoặc BLOB nào. Khi một INTEGER hoặc REAL được so sánh với một INTEGER hoặc REAL khác, một phép so sánh số được thực hiện

• Giá trị TEXT nhỏ hơn giá trị BLOB. Khi hai giá trị TEXT được so sánh, một trình tự đối chiếu thích hợp được sử dụng để xác định kết quả

• Khi hai giá trị BLOB được so sánh, kết quả được xác định bằng memcmp()

4. 2. Loại chuyển đổi trước khi so sánh

SQLite có thể thử chuyển đổi giá trị giữa các lớp lưu trữ INTEGER, REAL và/hoặc TEXT trước khi thực hiện so sánh. Việc có hay không bất kỳ chuyển đổi nào được thử trước khi so sánh diễn ra tùy thuộc vào mối quan hệ loại của toán hạng

Để "áp dụng mối quan hệ" có nghĩa là chuyển đổi một toán hạng thành một lớp lưu trữ cụ thể khi và chỉ khi việc chuyển đổi không làm mất thông tin cần thiết. Các giá trị số luôn có thể được chuyển đổi thành TEXT. Các giá trị TEXT có thể được chuyển đổi thành các giá trị số nếu nội dung văn bản là một số nguyên hoặc ký tự thực được định dạng tốt, nhưng không phải là một ký tự số nguyên thập lục phân. Các giá trị BLOB được chuyển đổi thành các giá trị TEXT bằng cách diễn giải đơn giản nội dung BLOB nhị phân dưới dạng một chuỗi văn bản trong mã hóa cơ sở dữ liệu hiện tại

Mối quan hệ được áp dụng cho toán hạng của toán tử so sánh trước khi so sánh theo các quy tắc sau theo thứ tự được hiển thị

• Nếu một toán hạng có ái lực INTEGER, REAL hoặc NUMERIC và toán hạng kia có TEXT hoặc BLOB hoặc không có ái lực thì ái lực NUMERIC được áp dụng cho toán hạng khác

• Nếu một toán hạng có ái lực TEXT và toán hạng kia không có ái lực, thì ái lực TEXT được áp dụng cho toán hạng kia

• Mặt khác, không có mối quan hệ nào được áp dụng và cả hai toán hạng được so sánh như

Biểu thức "a GIỮA b VÀ c" được coi là hai phép so sánh nhị phân riêng biệt "a >= b VÀ a <= c", ngay cả khi điều đó có nghĩa là các mối quan hệ khác nhau được áp dụng cho 'a' trong mỗi phép so sánh. Chuyển đổi kiểu dữ liệu trong so sánh có dạng "x IN (SELECT y. )" được xử lý như thể phép so sánh thực sự là "x=y". Biểu thức "a IN (x, y, z,. )" tương đương với "a = +x HOẶC a = +y HOẶC a = +z HOẶC. ". Nói cách khác, các giá trị ở bên phải của toán tử IN (các giá trị "x", "y" và "z" trong ví dụ này) được coi là không có ái lực, ngay cả khi chúng là giá trị cột hoặc biểu thức CAST

4. 3. Ví dụ so sánh

CREATE TABLE t1(
    a TEXT,      -- text affinity
    b NUMERIC,   -- numeric affinity
    c BLOB,      -- no affinity
    d            -- no affinity
);

-- Values will be stored as TEXT, INTEGER, TEXT, and INTEGER respectively
INSERT INTO t1 VALUES('500', '500', '500', 500);
SELECT typeof(a), typeof(b), typeof(c), typeof(d) FROM t1;
text|integer|text|integer

-- Because column "a" has text affinity, numeric values on the
-- right-hand side of the comparisons are converted to text before
-- the comparison occurs.
SELECT a < 40,   a < 60,   a < 600 FROM t1;
0|1|1

-- Text affinity is applied to the right-hand operands but since
-- they are already TEXT this is a no-op; no conversions occur.
SELECT a < '40', a < '60', a < '600' FROM t1;
0|1|1

-- Column "b" has numeric affinity and so numeric affinity is applied
-- to the operands on the right.  Since the operands are already numeric,
-- the application of affinity is a no-op; no conversions occur.  All
-- values are compared numerically.
SELECT b < 40,   b < 60,   b < 600 FROM t1;
0|0|1

-- Numeric affinity is applied to operands on the right, converting them
-- from text to integers.  Then a numeric comparison occurs.
SELECT b < '40', b < '60', b < '600' FROM t1;
0|0|1

-- No affinity conversions occur.  Right-hand side values all have
-- storage class INTEGER which are always less than the TEXT values
-- on the left.
SELECT c < 40,   c < 60,   c < 600 FROM t1;
0|0|0

-- No affinity conversions occur.  Values are compared as TEXT.
SELECT c < '40', c < '60', c < '600' FROM t1;
0|1|1

-- No affinity conversions occur.  Right-hand side values all have
-- storage class INTEGER which compare numerically with the INTEGER
-- values on the left.
SELECT d < 40,   d < 60,   d < 600 FROM t1;
0|0|1

-- No affinity conversions occur.  INTEGER values on the left are
-- always less than TEXT values on the right.
SELECT d < '40', d < '60', d < '600' FROM t1;
1|1|1

All of the results in the example are the same if the comparisons are commuted - if expressions of the form "a<40" are rewritten as "40>a".

Mathematical operators (+, -, *, /, %, <<, >>, &, and |) interpret both operands as if they were numbers. STRING or BLOB operands automatically convert into REAL or INTEGER values. If the STRING or BLOB looks like a real number (if it has a decimal point or an exponent) or if the value is outside the range that can be represented as a 64-bit signed integer, then it converts to REAL. Otherwise the operand converts to INTEGER. The implied type conversion of mathematical operands is slightly different from CAST to NUMERIC in that string and BLOB values that look like real numbers but have no fractional part are kept as REAL instead of being converted into INTEGER as they would be for CAST to NUMERIC. The conversion from STRING or BLOB into REAL or INTEGER is performed even if it is lossy and irreversible. Some mathematical operators (%, <<, >>, &, and |) expect INTEGER operands. For those operators, REAL operands are converted into INTEGER in the same way as a CAST to INTEGER. The <<, >>, &, and | operators always return an INTEGER (or NULL) result, but the % operator returns either INTEGER or REAL (or NULL) depending on the type of its operands. A NULL operand on a mathematical operator yields a NULL result. An operand on a mathematical operator that does not look in any way numeric and is not NULL is converted to 0 or 0.0. Division by zero gives a result of NULL.

Khi kết quả truy vấn được sắp xếp theo mệnh đề ORDER BY, các giá trị có lớp lưu trữ NULL sẽ xuất hiện trước, tiếp theo là các giá trị INTEGER và REAL được xen kẽ theo thứ tự số, tiếp theo là các giá trị TEXT theo thứ tự đối chiếu và cuối cùng là các giá trị BLOB theo thứ tự memcmp(). Không có chuyển đổi lớp lưu trữ xảy ra trước khi sắp xếp

Khi nhóm các giá trị với mệnh đề GROUP BY, các giá trị với các lớp lưu trữ khác nhau được coi là khác biệt, ngoại trừ các giá trị INTEGER và REAL được coi là bằng nhau nếu chúng bằng nhau về số lượng. Không có mối quan hệ nào được áp dụng cho bất kỳ giá trị nào là kết quả của mệnh đề GROUP by

Các toán tử SELECT ghép UNION, INTERSECT và EXCEPT thực hiện so sánh ẩn giữa các giá trị. Không có mối quan hệ nào được áp dụng cho các toán hạng so sánh đối với các phép so sánh ẩn được liên kết với UNION, INTERSECT hoặc EXCEPT - các giá trị được so sánh như vốn có

Khi SQLite so sánh hai chuỗi, nó sử dụng một trình tự đối chiếu hoặc hàm đối chiếu (hai thuật ngữ cho cùng một thứ) để xác định chuỗi nào lớn hơn hoặc liệu hai chuỗi có bằng nhau không. SQLite có ba chức năng đối chiếu tích hợp. BINARY, NOCASE và RTRIM

• BINARY - So sánh dữ liệu chuỗi bằng memcmp(), bất kể mã hóa văn bản
• NOCASE - Tương tự như nhị phân, ngoại trừ việc nó sử dụng sqlite3_strnicmp() để so sánh. Do đó, 26 ký tự chữ hoa của ASCII được xếp thành chữ thường tương đương trước khi thực hiện so sánh. Lưu ý rằng chỉ các ký tự ASCII được viết hoa chữ thường. SQLite không cố gắng thực hiện gấp trường hợp UTF đầy đủ do kích thước của các bảng được yêu cầu. Cũng lưu ý rằng bất kỳ ký tự U+0000 nào trong chuỗi đều được coi là ký tự kết thúc chuỗi cho mục đích so sánh
• RTRIM - Giống như nhị phân, ngoại trừ các ký tự dấu cách ở cuối bị bỏ qua

Một ứng dụng có thể đăng ký các chức năng đối chiếu bổ sung bằng giao diện sqlite3_create_collation()

Các chức năng đối chiếu chỉ quan trọng khi so sánh các giá trị chuỗi. Các giá trị số luôn được so sánh bằng số và BLOB luôn được so sánh theo từng byte bằng memcmp()

7. 1. Gán các chuỗi đối chiếu từ SQL

Mỗi cột của mỗi bảng có một chức năng đối chiếu được liên kết. Nếu không có chức năng đối chiếu nào được xác định rõ ràng, thì chức năng đối chiếu sẽ mặc định là BINARY. Mệnh đề COLLATE của định nghĩa cột được sử dụng để xác định các hàm đối chiếu thay thế cho một cột

The rules for determining which collating function to use for a binary comparison operator (=, <, >, <=, >=, !=, IS, and IS NOT) are as follows:

1. Nếu một trong hai toán hạng có phép gán hàm đối chiếu rõ ràng bằng cách sử dụng toán tử COLLATE hậu tố, thì hàm đối chiếu rõ ràng được sử dụng để so sánh, ưu tiên cho hàm đối chiếu của toán hạng bên trái

2. Nếu một trong hai toán hạng là một cột, thì hàm đối chiếu của cột đó được sử dụng ưu tiên cho toán hạng bên trái. Đối với mục đích của câu trước, tên cột đứng trước một hoặc nhiều toán tử "+" và/hoặc toán tử CAST vẫn được coi là tên cột

3. Mặt khác, chức năng đối chiếu BINARY được sử dụng để so sánh

Toán hạng của phép so sánh được coi là có phép gán hàm đối chiếu rõ ràng (quy tắc 1 ở trên) nếu bất kỳ biểu thức con nào của toán hạng sử dụng toán tử COLLATE hậu tố. Do đó, nếu toán tử COLLATE được sử dụng ở bất kỳ đâu trong biểu thức so sánh, thì hàm đối chiếu được xác định bởi toán tử đó được sử dụng để so sánh chuỗi bất kể cột bảng nào có thể là một phần của biểu thức đó. Nếu hai hoặc nhiều biểu thức con của toán tử COLLATE xuất hiện ở bất kỳ đâu trong một phép so sánh, thì hàm đối chiếu rõ ràng nhất bên trái sẽ được sử dụng bất kể các toán tử COLLATE được lồng sâu đến mức nào trong biểu thức và bất kể biểu thức được đặt trong ngoặc đơn như thế nào

Biểu thức "x GIỮA y và z" về mặt logic tương đương với hai phép so sánh "x >= y AND x <= z" và hoạt động đối với các hàm đối chiếu như thể đó là hai phép so sánh riêng biệt. Biểu thức "x IN (SELECT y. )" được xử lý giống như biểu thức "x = y" nhằm mục đích xác định trình tự đối chiếu. Trình tự đối chiếu được sử dụng cho các biểu thức có dạng "x IN (y, z,. )" là dãy đối chiếu của x. Nếu một trình tự đối chiếu rõ ràng được yêu cầu trên toán tử IN thì nó sẽ được áp dụng cho toán hạng bên trái, như thế này. "x COLLATE nocase IN (y,z,. )"

Các điều khoản của mệnh đề ORDER BY là một phần của câu lệnh SELECT có thể được gán một trình tự đối chiếu bằng cách sử dụng toán tử COLLATE, trong trường hợp đó, hàm đối chiếu được chỉ định được sử dụng để sắp xếp. Mặt khác, nếu biểu thức được sắp xếp theo mệnh đề ORDER BY là một cột, thì trình tự đối chiếu của cột được sử dụng để xác định thứ tự sắp xếp. Nếu biểu thức không phải là một cột và không có mệnh đề COLLATE, thì trình tự đối chiếu BINARY được sử dụng

7. 2. Ví dụ về trình tự đối chiếu

Các ví dụ bên dưới xác định trình tự đối chiếu sẽ được sử dụng để xác định kết quả so sánh văn bản có thể được thực hiện bởi các câu lệnh SQL khác nhau. Lưu ý rằng có thể không cần so sánh văn bản và không sử dụng trình tự đối chiếu trong trường hợp giá trị số, blob hoặc NULL