Kiểu dữ liệu nào sẽ đượ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. Xin đề nghị tôi nên sử dụng kiểu dữ liệu nào? Chờ đợi. Vui lòng đọc trước khi bạn trả lời ..

Trường này cần được lập chỉ mục rất 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 tìm kiếm ký tự hoang dã).

Đến bây giờ, chúng tôi hy vọng số điện thoại sẽ có một số định dạng (từ tệp XML). Tôi có phải viết mộ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 liên kết tài nguyên máy chủ (trong các hoạt động như tiền xử lý quá nhiều) mỗi khi một số dữ liệu nguồn đi qua ..

Mọi góp ý đều được chào đón ..

Cập nhật: Tôi không 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 xml ở mức tối thiểu. Một khi nó đã ở 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 quanh đây là nó thậm chí sẽ hoạt động với tính năng Ajax AutoComplete (vì vậy Sales Reps có thể thấy các kết quả khớ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 số thực tế (như “yêu cầu bợm”)?

Nếu tất cả những thứ này là không, tôi sẽ sử dụng trường 10 char và loại bỏ tất cả dữ liệu không phải là số. Nếu đầu tiên là có và hai trường kia là không, tôi sẽ sử dụng hai trường varchar (50), một cho đầu vào ban đầu và một với tất cả các dữ liệu không phải là số và được sử dụng để lập chỉ mục. Nếu 2 hoặc 3 là có, tôi nghĩ rằng tôi sẽ thực hiện hai trường và một số trình phân tích cú pháp điên để xác định phần 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 một cái gì đó với chỉ mục nơi nó loại bỏ các ký tự phụ khi tạo chỉ mục, nhưng tôi chỉ tạo một cột thứ hai và có thể thực hiện tước các ký tự bằng một 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 đây thực tế là cách chính mà mọi thứ được thực hiện cho bảng, chỉ lưu trữ các chữ số trong một cột phụ như tôi đã nói, và sau đó làm cho chỉ mục cho cột đó thành cụm.

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

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 hỗ trợ các số quốc tế, tôi khuyên bạn nên lưu trữ riêng Mã 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â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 bạn để giới hạn các cuộc gọi được trả về Hoa Kỳ thí dụ

Có lẽ tôi đang thiếu điều hiển nhiên ở đây, nhưng liệu một varchar chỉ đủ dài để số điện thoại mong đợi lâu 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 để giữ một số điện thoại Bắc Mỹ với phần mở rộng. Bạn sẽ muốn loại bỏ tất cả các ký tự ‘(‘, ‘)’, ‘-‘ khó chịu hoặc chỉ phân tích tất cả chúng thành một định dạng thống nhất.

Alex

sử dụng varchar khá kém hiệu quả. sử dụng loại tiền và tạo một loại người dùng khai báo loại “số điện thoại” từ đó và tạo quy tắc chỉ cho phép số dương.

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

Bình thường hóa dữ liệu sau đó lưu trữ dưới dạng varchar. Bình thường hóa có thể là khó khăn.

Đó nên là một lần nhấ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 được chuẩn hóa. Nên rất nhanh.

Vì bạn cần phải chứa 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ể có ý nghĩa nhất khi chỉ 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 trở nên hữu ích hơn, nhưng nó không có vẻ như vậy.

Khi bạn quyết định chỉ coi nó là bất kỳ chuỗi nào khác, bạn có thể tập trung khắc phục các vấn đề không thể tránh khỏi liên quan đến dữ liệu xấu, hình thành số điện thoại bí ẩn và bất cứ điều gì khác sẽ xuất hiện. Thách thức sẽ là trong 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ữ nó theo ý kiến ​​của tôi. Luôn luôn là một nhiệm vụ khó khăn khi phải đối phó với một đống dữ liệu lớn mà bạn không kiểm soát được việc thu thập.

Việc sử dụng “x” hoặc “ext” để biểu thị các tiện ích mở rộng là khá phổ biến, vì vậy, cho phép 15 ký tự (để hỗ trợ quốc tế đầy đủ) cộng với 3 (cho “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 để bất kỳ “ext” nào được dịch thành “x”, cho tối đa 20.

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

I E

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

Luôn luôn tốt hơn khi 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, do đó, bạn có thể phân tích dữ liệu từ tệp XML và chuyển đổi nó thành định dạng phù hợp để không có bất kỳ vấn đề nào 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 biệt để lập chỉ mục và thu hồi cả hai sẽ có hiệu quả .

Cảm ơn bạn.