Có bất kỳ lý do để sử dụng varchar trên các cột văn bản trong cơ sở dữ liệu?

Có phải varcharchỉ là tàn dư từ trước khi textxuất hiện, hoặc có trường hợp sử dụng mà bạn muốn sử dụng varcharkhông? (Hoặc charcho vấn đề đó ..)

(Tôi sử dụng Postgres và MySQL (MyISAM) hàng ngày, vì vậy đó là những gì tôi quan tâm nhất, nhưng tất nhiên câu trả lời cho các cơ sở dữ liệu khác đều được chào đón. ^ _-)

— Izkata
nguồn

Ít nhất là đối với SQL Server , textkhông được dùng nữa. Cũng có những cân nhắc về việc sử dụng có liên quan đến nơi lưu trữ dữ liệu và cách thức truy cập dữ liệu.

— Oded

Trên một số DBMS, bạn không thể sử dụng cột văn bản trong mệnh đề sắp xếp hoặc vị trí. Tôi không quen thuộc với Postgres nhưng kiểm tra tài liệu của bạn.

— jqa

Câu hỏi StackOverflow này có thể cung cấp thêm một số thông tin.

— J0ANMM

Câu trả lời:

Nói chung

textcột không chuẩn và thực hiện cụ thể. Trong nhiều trường hợp, tùy thuộc vào cơ sở dữ liệu, họ có thể có sự kết hợp của một hoặc nhiều hạn chế sau: không thể lập chỉ mục , không thể tìm kiếm và không thể sắp xếp .

Trong Postgres

Tất cả các loại này được lưu nội bộ bằng cách sử dụng cùng một cấu trúc dữ liệu C. .

Trong MySQL

Các textcột là một phiên bản đặc biệt củaBLOB và có giới hạn về lập chỉ mục.

Chỉ hai ví dụ này có thể được ngoại suy sang các hệ thống RDBMS SQL khác và phải đủ lý do để hiểu khi nào nên chọn một loại so với loại kia.

Chỉ cần làm cho nó rõ ràng rõ ràng, bạn không bao giờ nên sử dụng TEXTvì nó là độc quyền và không chuẩn. Bất kỳ SQLbạn viết chống lại nó sẽ không thể di động và sẽ đảm bảo gây ra vấn đề cho bạn trong tương lai. Chỉ sử dụng các loại là một phần của Tiêu chuẩn ANSI .

Sử dụng CHARkhi bạn biết bạn có một số ký tự cố định cho mỗi mục.
Sử dụng VARCHARkhi bạn có số lượng ký tự thay đổi cho mỗi mục nhập.
Nếu bạn cần nhiều bộ nhớ hơn mức VARCHARcó thể cung cấp, CLOBvới UTF-8mã hóa hoặc loại tiêu chuẩn tương đương.
KHÔNG BAO GIỜ sử dụng TEXTvì nó không chuẩn.

Được chấp nhận non standard and implementation specificvà not indexable, not searchable and not sortable, điều mà tôi đã không nhận ra. Tôi đã có ấn tượng text được tiêu chuẩn hóa.

— Izkata

bạn có nghĩa là texttiêu chuẩn ASCII hoặc tiêu chuẩn UNICODE text:-) hoặc một trong nửa tá texttiêu chuẩn mã hóa khác?

nếu bạn đi sâu vào các tài liệu tiêu chuẩn SQL, tôi không nghĩ bạn sẽ tìm thấy bất cứ điều gì về textkiểu ký tự. Tôi chưa thấy gì, một số nhà cung cấp gọi nó long charvà tương tự, về cơ bản nó là một BLOB với mã hóa được đính kèm.

@JarrodRoberson thành thật mà nói, có rất nhiều tài nguyên có uy tín để kết luận (khi ở trong môi trường Postgres) mà "luôn luôn sử dụng TEXT". Nếu bạn sẽ di chuyển sang một cơ sở dữ liệu khác, thì đó hầu như không phải là một công cụ giải quyết, đặc biệt là vì bạn sẽ phải xem xét rằng không giới hạn của postgres VARCHAR(do TOAST không có giới hạn hàng như ví dụ với MySQL) có thể không dịch sang không giới hạn VARCHARtrong cơ sở dữ liệu khác nào.

— Kayaman

... và vì Postgres không hỗ trợ CLOB , điểm thứ hai đến điểm cuối không giữ được. Bạn sẽ không bao giờ có thể hỗ trợ thay thế thả vào ngay cả khi tuân thủ tiêu chuẩn. Cũng như viết ANSI SQL không phải là một lựa chọn khả thi trong thế giới thực, trừ khi bạn viết SQL đồ chơi.

— Kayaman

text, varcharvà chartất cả được sử dụng cho các lý do khác nhau. Tất nhiên có sự khác biệt trong việc thực hiện (bao nhiêu kích thước chúng chiếm .. vv), nhưng cũng có những cân nhắc về cách sử dụng và mục đích . Loại bạn sử dụng cũng cho bạn biết điều gì đó về loại dữ liệu sẽ được lưu trữ trong đó (hoặc tất cả chúng ta sẽ sử dụng textcho mọi thứ ). Nếu một cái gì đó có chiều dài cố định, chúng tôi sử dụng char. Nếu nó có độ dài thay đổi với giới hạn trên được xác định rõ thì sử dụng varchar. Nếu đó là một đoạn văn bản lớn mà bạn có ít quyền kiểm soát thì đó textcó lẽ là lựa chọn tốt nhất của bạn.

— Hệ thống xuống
nguồn

Sooooooo, sự khác biệt thực sự duy nhất là sao chép giới hạn - kiểm tra có lẽ nên có trong mã chương trình chứ?

— Izkata

@Izkata - Có sự khác biệt thực hiện là tốt. Nó không phải là về kiểm tra giới hạn, đó là về loại dữ liệu . Mã zip (Hoa Kỳ) luôn là mã gồm 5 chữ số, do đó, sử dụng cái gì đó như 'char' trở thành một phần định nghĩa của đoạn dữ liệu này. Nếu đó chỉ là những thứ như kiểm tra ràng buộc thì tất cả chúng ta chỉ có thể sử dụng một loại dữ liệu cho mọi thứ và thực hiện kiểm tra và truyền mã bên.

— Hệ thống xuống

@SystemDown Theo như tôi biết, char, varchar, và texttất cả đều được thiết kế để lưu trữ cùng một loại dữ liệu. Vì vậy, cả hai câu trả lời ở đây là về kiểm tra giới hạn. Nếu có sự khác biệt về hiệu quả, chúng là gì? Tại sao tôi sẽ sử dụng varcharhơn text?

— Izkata

float và double cũng được sử dụng cho cùng loại dữ liệu, tuy nhiên chúng có sự khác biệt và được sử dụng khác nhau. Về sự khác biệt trong triển khai, tôi không đủ quen thuộc với Postgres để trả lời rằng tôi sợ.

— Hệ thống xuống

@SystemDown Mặc dù lưu trữ mã bưu chính dưới dạng char (5) có thể cắn bạn nếu bạn bắt đầu quốc tế hóa. Mã bưu điện của Anh khác nhau về độ dài và 5 ký tự gần như không bao giờ là đủ. Tuy nhiên, tôi không biết liệu khoảng trống trong mã bưu điện của Vương quốc Anh có liên quan đến phân tích cú pháp hay không.

— Vatine

Cơ sở dữ liệu rất quan tâm đến hiệu suất - tốc độ và giảm thiểu lưu trữ. Trong hầu hết các phần khác của thế giới máy tính, bạn sẽ không bị làm phiền về việc có bao nhiêu ký tự trong chuỗi ký tự của bạn; nó có thể là một, nó có thể là toàn bộ nội dung của một cuốn bách khoa toàn thư; tất cả chỉ là một chuỗi. Trên thực tế, rất nhiều ngôn ngữ thậm chí không làm phiền bạn về việc đó là một chuỗi hay một số.

Nhưng khi máy tính trở nên nhanh hơn và có được nhiều bộ nhớ hơn, mọi người sẽ đưa thêm dữ liệu vào cơ sở dữ liệu của họ và thực hiện các truy vấn nhanh hơn. Đối với một cơ sở dữ liệu, CPU và bộ nhớ cũng hạn chế như ngày nay khi chúng còn ở bộ nhớ chính 64Kb và ổ cứng 10Mb (trên máy tính máy tính lớn ).

Một số byte cố định dễ xử lý hơn nhiều so với số có độ dài thay đổi. 10 byte dễ dàng hơn rất nhiều để xử lý hơn 1.000.000. Vì vậy, cơ sở dữ liệu của bạn muốn bạn cung cấp cho nó một gợi ý để nó có thể cung cấp cho bạn một gigabyte kết quả từ terrabyte dữ liệu trong vài giây. Nếu bạn không sử dụng cơ sở dữ liệu của mình quá nhiều, bạn sẽ không cần tốc độ mà nó cung cấp và sẽ khó chịu với những câu hỏi không cần thiết. Nhưng nếu bạn cần hiệu suất, bạn sẽ vui lòng cung cấp cho nó một số gợi ý.

Như đã lưu ý trong các câu trả lời khác, hãy sử dụng charnếu nó luôn sử dụng một số ký tự nhất định, varcharnếu độ dài có thể thay đổi nhưng nó không quá lớn (tôi đoán là hầu hết DB coi nó như một charhoặc texttùy thuộc vào kích thước) và textnếu nó có thể là bất kỳ chiều dài. Nếu SQL của bạn cố gắng sử dụng một textcột, cách tốt nhất là tóm tắt nó bằng cách nào đó và đặt nó vào một cột charnhỏ hoặc varcharcũng vậy, sau đó hãy thực hiện wherevà order byđó. Tất nhiên, đó chỉ là khi hiệu suất quan trọng với bạn.

— RalphChapin
nguồn