Loại dữ liệu nào nên được sử dụng để lưu trữ số điện thoại trong SQL Server 2005?

Tôi cần lưu trữ số điện thoại trong một bảng. Vui lòng đề xuất loại dữ liệu nào tôi nên sử dụng? Chờ đợi. Vui lòng đọc tiếp trước khi bạn nhấn trả lời ..

Trường này cần được lập chỉ mục nhiều vì Đại diện bán hàng có thể sử dụng trường này để tìm kiếm (bao gồm cả tìm kiếm ký tự hoang dã).

Hiện tại, chúng tôi đang mong đợi số điện thoại có một số định dạng (từ tệp XML). Tôi có phải viết trình phân tích cú pháp để chuyển đổi sang định dạng thống nhất không? Có thể có hàng triệu dữ liệu (có trùng lặp) và tôi không muốn buộc tài nguyên máy chủ (trong các hoạt động như xử lý trước quá nhiều) mỗi khi một số dữ liệu nguồn đi qua ..

Mọi đề xuất đều được hoan nghênh ..

Cập nhật: Tôi không có quyền kiểm soát dữ liệu nguồn. Chỉ cần cấu trúc của tệp xml là tiêu chuẩn. Muốn giữ phân tích cú pháp xml ở mức tối thiểu. Khi nó nằm trong cơ sở dữ liệu, việc truy xuất sẽ nhanh chóng. Một gợi ý điên rồ đang diễn ra xung quanh đây là nó thậm chí sẽ hoạt động với tính năng Tự động điền của Ajax (vì vậy Đại diện bán hàng có thể thấy những cái phù hợp ngay lập tức). CHÚA ƠI!!

Điều này có bao gồm:

• Số quốc tế?
• Phần mở rộng?
• Thông tin khác ngoài con số thực tế (như "yêu cầu bobby")?

Nếu tất cả những điều này đều không, tôi sẽ sử dụng trường 10 ký tự và loại bỏ tất cả dữ liệu không phải số. Nếu trường đầu tiên là có và hai trường còn lại là không, tôi sẽ sử dụng hai trường varchar (50), một cho dữ liệu đầu vào ban đầu và một trường có tất cả dữ liệu không phải số và được sử dụng để lập chỉ mục. Nếu 2 hoặc 3 là có, tôi nghĩ tôi sẽ thực hiện hai trường và một số loại phân tích cú pháp điên rồ để xác định đâu là tiện ích mở rộng hoặc dữ liệu khác và xử lý nó một cách thích hợp. Tất nhiên bạn có thể tránh cột thứ 2 bằng cách làm gì đó với chỉ mục nơi nó loại bỏ các ký tự thừa khi tạo chỉ mục, nhưng tôi chỉ tạo cột thứ hai và có thể thực hiện việc loại bỏ các ký tự bằng một trình kích hoạt.

Cập nhật: để giải quyết vấn đề AJAX, nó có thể không tệ như bạn nghĩ. Nếu thực tế đây là cách chính của bất kỳ thứ gì được thực hiện với bảng, chỉ lưu trữ các chữ số trong cột phụ như tôi đã nói, và sau đó đặt chỉ mục cho cột đó thành một nhóm.

Chúng tôi sử dụng varchar (15) và chắc chắn chỉ mục trên trường đó.

Lý do là các tiêu chuẩn quốc tế có thể hỗ trợ tới 15 chữ số

Wikipedia - Định dạng số điện thoại

Nếu bạn thực sự hỗ trợ số điện thoại Quốc tế, tôi khuyên bạn nên lưu trữ riêng Mã vùng thế giới hoặc Mã quốc gia để lọc các truy vấn tốt hơn để bạn không thấy mình phải phân tích cú pháp và kiểm tra độ dài của các trường số điện thoại của mình để giới hạn các cuộc gọi trả lại cho thí dụ

Sử dụng CHAR (10) nếu bạn chỉ lưu trữ Số điện thoại của Hoa Kỳ. Xóa mọi thứ trừ các chữ số.

Tôi có lẽ đang thiếu điều hiển nhiên ở đây, nhưng một varchar không đủ dài để số điện thoại mong đợi dài nhất của bạn hoạt động tốt?

Nếu tôi đang thiếu một cái gì đó rõ ràng, tôi rất muốn nó nếu ai đó sẽ trỏ nó ra ...

Tôi sẽ sử dụng một varchar (22). Đủ lớn để chứa một số điện thoại Bắc Mỹ có phần mở rộng. Bạn muốn loại bỏ tất cả các ký tự '(', ')', '-' khó chịu hoặc chỉ phân tích cú pháp tất cả chúng thành một định dạng thống nhất.

Alex

SQL Server 2005 được tối ưu hóa khá tốt cho các truy vấn chuỗi con đối với văn bản trong các trường varchar được lập chỉ mục. Đối với năm 2005, họ đã giới thiệu thống kê mới cho tóm tắt chuỗi cho các trường chỉ mục. Điều này giúp ích đáng kể cho việc tìm kiếm toàn văn.

sử dụng varchar là khá kém hiệu quả. sử dụng loại tiền và tạo loại "phonenumber" do người dùng khai báo và tạo quy tắc chỉ cho phép các số dương.

nếu bạn khai báo nó là (19,4), bạn thậm chí có thể lưu trữ phần mở rộng 4 chữ số và đủ lớn cho các số quốc tế và chỉ chiếm 9 byte dung lượng. Ngoài ra, các chỉ mục cũng nhanh chóng.

nvarchar với tiền xử lý để chuẩn hóa chúng nhiều nhất có thể. Có thể bạn sẽ muốn trích xuất các tiện ích mở rộng và lưu trữ chúng trong một trường khác.

Chuẩn hóa dữ liệu sau đó lưu trữ dưới dạng varchar. Việc chuẩn hóa có thể rất phức tạp.

Đó phải là một hit một lần. Sau đó, khi một bản ghi mới xuất hiện, bạn đang so sánh nó với dữ liệu chuẩn hóa. Nên rất nhanh.

Vì bạn cần phải đáp ứng nhiều định dạng số điện thoại khác nhau (và có thể bao gồm những thứ như tiện ích mở rộng, v.v.) nên có thể hợp lý nhất nếu bạn coi nó như bất kỳ varchar nào khác. Nếu bạn có thể kiểm soát đầu vào, bạn có thể thực hiện một số cách tiếp cận để làm cho dữ liệu hữu ích hơn, nhưng nghe có vẻ không đúng như vậy.

Một khi bạn quyết định đơn giản coi nó như bất kỳ chuỗi nào khác, bạn có thể tập trung vào việc khắc phục các vấn đề không thể tránh khỏi liên quan đến dữ liệu xấu, định dạng số điện thoại bí ẩn và bất cứ điều gì khác sẽ bật lên. Thách thức sẽ nằm ở việc xây dựng một chiến lược tìm kiếm tốt cho dữ liệu chứ không phải cách bạn lưu trữ dữ liệu theo quan điểm của tôi. Luôn là một nhiệm vụ khó khăn khi phải giải quyết một đống dữ liệu lớn mà bạn không thể kiểm soát được việc thu thập.

Sử dụng SSIS để trích xuất và xử lý thông tin. Bằng cách đó, bạn sẽ xử lý các tệp XML được tách ra từ SQL Server. Bạn cũng có thể thực hiện chuyển đổi SSIS trên một máy chủ riêng biệt nếu cần. Lưu trữ số điện thoại ở định dạng chuẩn bằng cách sử dụng VARCHAR. NVARCHAR sẽ không cần thiết vì chúng ta đang nói về các con số và có thể là một vài ký tự khác, như '+', '', '(', ')' và '-'.

Sử dụng varchartrường có giới hạn độ dài.

Khá phổ biến khi sử dụng "x" hoặc "ext" để biểu thị phần mở rộng, vì vậy hãy cho phép 15 ký tự (đối với hỗ trợ quốc tế đầy đủ) cộng với 3 (đối với "ext") cộng với 4 (đối với chính tiện ích mở rộng) cho tổng cộng 22 ký tự . Điều đó sẽ giữ cho bạn an toàn.

Ngoài ra, chuẩn hóa đầu vào để mọi "ext" đều được dịch thành "x", tối đa là 20.

Sẽ tốt hơn nếu có các bảng riêng biệt cho các thuộc tính đa giá trị như số điện thoại.

Vì bạn không có quyền kiểm soát dữ liệu nguồn nên bạn có thể phân tích cú pháp dữ liệu từ tệp XML và chuyển đổi nó thành định dạng thích hợp để không có bất kỳ vấn đề nào xảy ra với các định dạng của một quốc gia cụ thể và lưu trữ nó trong một bảng riêng để lập chỉ mục và truy xuất cả hai sẽ hiệu quả .

Cảm ơn bạn.

Tôi nhận ra rằng chuỗi này đã cũ, nhưng điều đáng nói là một lợi thế của việc lưu trữ dưới dạng số cho mục đích định dạng, cụ thể là trong .NET framework.

I E

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string

Thay vào đó, hãy sử dụng kiểu dữ liệu dài .. không sử dụng int vì nó chỉ cho phép các số nguyên từ -32,768 đến 32,767 nhưng nếu bạn sử dụng kiểu dữ liệu dài, bạn có thể chèn các số từ -2,147,483,648 đến 2,147,483,647.