Có, nếu có khả năng, bạn có thể đặt cả last, first và first last vào cơ sở dữ liệu, cách tốt hơn là thiết kế lược đồ của bạn đúng cách.
Nếu bạn đã từng thấy mình đang cố gắng tìm kiếm hoặc thao tác bằng cách khác, các bộ phận của cột, lược đồ của bạn gần như chắc chắn bị hỏng. Nó gần như chắc chắn sẽ giết chết hiệu suất.
Cách chính xác là có bảng như vậy:
T1 FirstName LastName
== ========= ========
1 Pax Diablo
2 Bob Smith
3 George Jones
Sau đó, bạn có thể tách hiệu quả hơn tên do người dùng nhập (một lần, trước khi chạy truy vấn) thay vì cố gắng tách từng tên riêng lẻ trong cơ sở dữ liệu.
Trong trường hợp cơ sở dữ liệu luôn giữ last, first , nó có thể không thực sự cần thiết cho việc thay đổi giản đồ.
Vấn đề bạn gặp phải trong trường hợp đó chỉ đơn giản là diễn giải những gì người dùng đã nhập.
Một khả năng, mặc dù nó là một kẻ hủy diệt hiệu suất, là thực hiện một like cho mỗi từ riêng biệt. Vì vậy, nếu người dùng đã nhập pax diablo , truy vấn kết quả của bạn có thể là:
select T1 from mytable
where T2 like '%pax%'
and T2 like '%diablo%'
Bằng cách đó, bạn không quan tâm đến đơn đặt hàng quá nhiều.
Tuy nhiên, do tôi không thích các truy vấn chậm, tôi sẽ cố gắng tránh xa điều đó trừ khi thực sự cần thiết (hoặc cơ sở dữ liệu của bạn tương đối nhỏ và có khả năng vẫn như vậy).
Có tất cả các cách để tăng tốc các loại truy vấn này, chẳng hạn như:
- sử dụng bất kỳ khả năng tìm kiếm toàn văn bản nào mà DBMS của bạn có.
- mô phỏng những khả năng như vậy bằng cách trích xuất và lưu trữ các từ trong quá trình kích hoạt chèn / cập nhật (và xóa chúng trong khi xóa trình kích hoạt).
- trường hợp trước đó, nhưng cũng đảm bảo các cột bổ sung được sử dụng với các giá trị viết hoa thấp hơn của cột hiện tại (cho tốc độ).
- nói với người dùng rằng họ cần sử dụng
last, firstbiểu mẫu để tìm kiếm. - cố gắng tránh
%something%chuỗi tìm kiếm càng nhiều càng tốt (vớisomething%, các chỉ mục vẫn có thể được sử dụng). - phương pháp "tách tên thành hai cột" đã đề cập trước đây của tôi.
