Chọn theo các thuộc tính dựa trên phạm vi ký tự đại diện SQL


8

Tôi muốn chọn tất cả các bản ghi từ bảng cơ sở dữ liệu địa lý nơi chuỗi bắt đầu bằng một chữ cái, vì vậy tôi đã thử

SELECT *
FROM tbl_names
WHERE "name" LIKE '[A-Z]%'

Điều này trả lại không có hồ sơ. Sau một số tìm kiếm, tôi thấy rằng đây là cú pháp của SQL Server. Tôi đã không nghĩ rằng đây sẽ là một vấn đề, theo như tôi biết tất cả các phiên bản hỗ trợ SQL %. Sau khi xem qua tệp trợ giúp về xây dựng biểu thức truy vấn , tôi thấy rằng cú pháp đúng là

SELECT *
FROM tbl_names
WHERE "name" >= 'A'

Vì tên là tất cả các chuỗi, bản năng đầu tiên của tôi là thử LIKE. Tại sao >=toán tử được sử dụng thay vì LIKE? Các phạm vi ký tự đại diện không được hỗ trợ trong ArcMap?


Tôi không biết cơ sở dữ liệu này, nhưng 'bên' nào sắp xếp các chữ số trên? Đó là, có 0đến sau Z(thông thường, tôi nghĩ), hoặc trước A? Một số DBMS khác không hỗ trợ loại chức năng này, vì vậy bạn phải sử dụng kiến ​​thức về những thứ hơi khác nhau. Ngoài ra, những gì về các ký tự chữ thường (hoặc là tất cả chữ hoa)? Còn những nhân vật không phải người Anh (không phải AZ) thì sao?
Đồng hồ-Muse

Khi sắp xếp một trường theo thứ tự tăng dần, các chuỗi xuất hiện như sau : !z,?,0,0a,1,10,2,ant,A,Ant,z,Z. Vì vậy, các ký tự đặc biệt, chữ số, chữ cái (phân biệt chữ hoa chữ thường).
Cindy Jayakumar

Câu trả lời:


9

Ký tự đại diện nói chung được ArcMap hỗ trợ. Đây là một trích xuất từ ​​trợ giúp bạn nhận được trong khi bạn thực hiện 'Chọn theo các thuộc tính':


Sử dụng toán tử THÍCH (thay vì toán tử =) để xây dựng tìm kiếm chuỗi một phần. Ví dụ: biểu thức này sẽ chọn Mississippi và Missouri trong số các tên tiểu bang của Hoa Kỳ:

"STATE_NAME" LIKE 'Miss%'

Bạn có thể sử dụng lớn hơn (>), nhỏ hơn (<), lớn hơn hoặc bằng (> =), nhỏ hơn hoặc bằng (<=) và toán tử GIỮA để chọn giá trị chuỗi dựa trên thứ tự sắp xếp. Ví dụ: biểu thức này sẽ chọn tất cả các thành phố trong vùng phủ sóng có tên bắt đầu bằng các chữ cái từ M đến Z:

"CITY_NAME" >= 'M'<>Toán tử không bằng ( ) cũng có thể được sử dụng khi truy vấn chuỗi.

Ký tự đại diện Một ký tự đại diện là ký hiệu đặc biệt đại diện cho một hoặc nhiều ký tự.

Đối với bất kỳ dữ liệu dựa trên tệp nào, '%' có nghĩa là mọi thứ đều được chấp nhận ở vị trí của nó: một ký tự, một trăm ký tự hoặc không có ký tự. Ngoài ra, nếu bạn muốn tìm kiếm bằng ký tự đại diện cho một ký tự, hãy sử dụng '_'.

Ví dụ: biểu thức này sẽ chọn bất kỳ tên nào bắt đầu bằng các chữ cái Cath, chẳng hạn như Cathy, Catherine và Catherine Smith:

"NAME" LIKE 'Cath%'

Nhưng biểu hiện này sẽ tìm thấy Catherine Smith và Kinda Smith:

"OWNER_NAME" LIKE '_atherine smith' Các ký tự đại diện bạn sử dụng để truy vấn cơ sở dữ liệu địa lý cá nhân là '*' cho bất kỳ số lượng ký tự và '?' cho một nhân vật.

Ký tự đại diện xuất hiện dưới dạng các nút trên hộp thoại truy vấn. Bạn có thể nhấp vào nút để nhập ký tự đại diện vào biểu thức bạn đang tạo. Chỉ các ký tự đại diện phù hợp với nguồn dữ liệu của lớp hoặc bảng bạn đang truy vấn mới được hiển thị.

Nếu bạn sử dụng ký tự đại diện trong một chuỗi với toán tử =, ký tự đó được coi là một phần của chuỗi, không phải là ký tự đại diện.

Với bảng đã tham gia, hãy sử dụng các ký tự đại diện thích hợp cho phía tham gia mà bạn đang truy vấn. Nếu truy vấn chỉ áp dụng cho các trường trong bảng đích (bảng bên trái), hãy sử dụng các ký tự đại diện của bảng đích. Nếu truy vấn chỉ áp dụng cho các trường trong bảng tham gia (bảng bên phải), hãy sử dụng các ký tự đại diện của bảng tham gia. Nếu truy vấn liên quan đến các trường từ cả hai phía của liên kết, hãy sử dụng ký tự đại diện '%' và '_'.

Ví dụ: nếu bạn tham gia tệp dbf (bảng tham gia) vào lớp tính năng GDB cá nhân (bảng đích):

  1. Sử dụng * cho các truy vấn chỉ liên quan đến các trường GDB cá nhân.

  2. Sử dụng% cho các truy vấn chỉ liên quan đến các cột dbf.

  3. Sử dụng% cho các truy vấn liên quan đến các cột từ cả hai phía của bảng.


Theo điều này: Tôi nghĩ rằng phạm vi không được hỗ trợ, thay vào đó bạn phải sử dụng> và <, giống như cách bạn đã làm.


Tôi hiểu rằng thẻ hoang dã có thể được sử dụng, vì phương pháp tôi đã sử dụng hầu hết thời gian để chọn các chuỗi con là WHERE "name" LIKE '%substring%'. Chỉ đến khi tôi cần tìm một chuỗi ở một định dạng cụ thể, như một biểu thức chính thức ở dạng [0-9][0-9][A-Z]%tôi mới nhận ra rằng nó sẽ không chấp nhận phạm vi ký tự đại diện.
Cindy Jayakumar

Cảm ơn @Torsten! Tôi không bao giờ biết rằng với GDB cá nhân, người ta đã sử dụng * không% cho ký tự đại diện.
lấp lánh

1

Có, bạn có thể sử dụng ký tự đại diện trong các câu lệnh THÍCH. Tôi chưa bao giờ sử dụng phạm vi qua ArcMap nhưng bạn đang sử dụng cú pháp đúng từ quan điểm của SQL Server.

Một lời cảnh báo nhanh nếu bạn định sử dụng toán tử '> ='. Kết quả của điều này sẽ khác nhau tùy thuộc vào đối chiếu nào được đặt. Điều này có thể thay đổi cách sắp xếp được thực hiện trên dữ liệu, ví dụ như trường hợp nhạy cảm hay không. Vì vậy, trong một số trường hợp, bạn có thể thấy truy vấn của mình chỉ trả về các giá trị bắt đầu bằng chữ in hoa và đôi khi cả chữ hoa và chữ thường.

Xem http://sqlblog.com/bloss/louis_davidson/archive/2007/05/20/sorting-and-case-sensitive-collations.aspx .

Ngoài ra, nếu bạn chỉ quan tâm đến ký tự đầu tiên của trường thì bạn có thể sử dụng

WHERE SUBSTRING("name", 1, 1) >= 'A'

thay vì

WHERE "name" >= 'A'

Điều này có thể có lợi ích hiệu suất nếu không có gì khác.


Trên thực tế, không, SUBSTRINGphương pháp này không có khả năng tăng hiệu suất, vì nó (thường) có nghĩa là bất kỳ chỉ số nào trên namesẽ bị bỏ qua. Có, bạn có thể có chi phí cao hơn để so sánh (độ dài ký tự đã cho), nhưng hầu hết các triển khai tôi biết sẽ quay lại sau khi ký tự đầu tiên được so sánh ... Dù sao, tôi nghi ngờ bất kỳ trình tối ưu hóa nào được viết để nhận ra SUBSTRING(column, 1, 1)chỉ là bắt đầu của chuỗi
Clockwork-Muse

Tôi có thể làm việc xung quanh trường hợp nhạy cảm bằng cách sử dụng upperkhông? Tôi không quan tâm đến trường hợp cho bài tập này mặc dù, nhưng nó sẽ tốt để ghi nhớ.
Cindy Jayakumar

Vâng, bạn hoàn toàn đúng. Không thể có lợi ích hiệu suất khi sử dụng SUBSTRING trong trường hợp này và có thể có tác dụng ngược lại.
pecoanddeco
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.