Tôi tin rằng câu trả lời cho câu hỏi này là "không" nhưng tôi quan tâm đến ý kiến cộng đồng. Giá trị varchar hoặc nvarchar sẽ tự động cắt khoảng trống theo sau, vì vậy tôi không tin rằng tôi sẽ phải gọi RTRIM() trên một giá trị như vậy. Có chuyên gia nào có lý do tôi cần phải làm không?Tôi có nên gọi RTRIM() trên một giá trị varchar hoặc nvarchar không?
(Trong trường hợp các thẻ không làm cho nó rõ ràng, tôi đề cập đặc biệt để Microsoft SQL Server.)
Nếu ANSI_PADDING đang ON thì đuôi sẽ được lưu trữ ngay cả với các kiểu dữ liệu varchar/nvarchar, vì vậy có.
Bạn có thể không cần để RTRIM để có được các giá trị ra trong một lựa chọn đơn giản, nhưng nếu bạn muốn để nối các giá trị (chẳng hạn như kết hợp họ và tên để hiển thị tên đầy đủ), bạn có thể cần.
Chạy thử nghiệm này để xem những gì tôi có nghĩa là:
giancreate table #temp (test varchar (10))
insert #temp
values ('test ')
insert #temp
values ('test2 ')
insert #temp
values ('test ')
insert #temp
values ('test')
select test + '1' from #temp
select rtrim(test) +'1' from #temp
select * from #temp where test = 'test'
Có, Hugh Darwen nói về điều này trong bài giảng huyền thoại của ông có tựa đề "The Askew Wall" và coi đó là một thất bại lớn của SQL DBMSes – McKay
(n)varchar chỉ sử dụng lượng không gian được sử dụng, do đó không được bao gồm khoảng trắng. Nó thường được sử dụng khi loại bỏ khoảng trống thừa khỏi trường char được phân bổ quá mức, tức là một char(30) chỉ với 10 ký tự.
Au contraire. SET ANSI_PADDING ... – gbn
@gbn, bạn đã làm điều đó một lần nữa! :) Tôi học được rất nhiều từ bạn !! Đó là mảnh NULL NULL không bị thiếu. –
Để lưu ý từ MSDN (http://msdn.microsoft.com/en-us/library/ms187403.aspx): Trong phiên bản tương lai của MicrosoftSQL Server ANSI_PADDING sẽ luôn BẬT và mọi ứng dụng đặt rõ ràng tùy chọn TẮT sẽ tạo ra lỗi. Tránh sử dụng tính năng này trong công việc phát triển mới và có kế hoạch sửa đổi các ứng dụng hiện đang sử dụng tính năng này. –
Có trường hợp lạ với toán tử LIKE. Ví dụ:
select 1 where convert(nvarchar(10), 'a') like convert(nvarchar(10), '%a ')
sẽ không trả lại kết quả.
Về lý thuyết, có, vì SET ANSI_PADDING được BẬT theo mặc định và sẽ BẬT trong tương lai.
Thành thật mà nói, tôi có xu hướng RTRIM viết vì điều này để tránh phải đọc mà xảy ra đến nay thường xuyên hơn. Nó chỉ phải xảy ra một lần để làm hỏng ngày của bạn ...
Nó phụ thuộc, ví dụ dữ liệu khách hàng Delphi và midas.dll được sử dụng với nó (ít nhất là phiên bản 7 và trước đó (không biết bây giờ) đã từng có lỗi rằng nếu độ dài của dữ liệu trong trường Nvarchar nhỏ hơn số liệu được chỉ định, thì chúng được sử dụng để được đệm.
Không quá nhiều vấn đề ở phía cơ sở dữ liệu. . lượng rắc rối
SQL server (và SQL DBMS nhất khác) thực sự hút khi nói đến thứ như thế này:
insert into Blah values ('careful ');
insert into Blah values ('careful');
Giả sử có một cột id hoặc một cái gì đó
Các giá trị sẽ so sánh với nhau, sẽ được báo cáo có cùng độ dài, nhưng sẽ không thực sự có cùng dữ liệu. Kết nối
select Bar + 'something' from Blah
và người khác sẽ có chỗ, người kia sẽ không có chỗ.
DATALENGTH sẽ hiển thị sự khác biệt, LEN trims – gbn
@gbn Vâng, dữ liệu trong thực tế khác nhau, đó là quan điểm của tôi. Giống như ví dụ nối, có cách để nhận được sự khác biệt, nhưng chúng so sánh với nhau. Sự thất bại giả định của SQL là nó thất bại trong tiền đề toán học của: cho tất cả a = b, f (a) = f (b) – McKay
Tôi chưa bao giờ phải làm vậy. –