it-swarm-vi.tech

Kiểu 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. Xin đề nghị tôi nên sử dụng kiểu dữ liệu nào? Đợ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 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à chuẩn. Muốn giữ phân tích xml ở mức tối thiểu. Khi đã vào cơ sở dữ liệu, việc truy xuất sẽ nhanh chóng. xung 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 những cái phù hợp ngay lập tức). OMG !!

70
John

Đ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 đâu là 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.

50
Kearns

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ụ

36
Brad Osterloo

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

4
Joseph Bui

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 am thiếu thứ gì đó rõ ràng, tôi sẽ thích nó nếu ai đó chỉ ra ...

3
cori

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

3
Alex Fort

sử dụng varchar khá kém hiệu quả. sử dụng loại tiền và tạo loại người dùng khai báo "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.

2
fjleon

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

2
Joseph Daigle

Việc sử dụng "x" hoặc "ext" để chỉ 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 (cho 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.

1
Rob G

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

1
John Sheehan

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.

1
Iain Holder

Sử dụng trường varchar với giới hạn độ dài.

1
user13270

Vì bạn cần điều chỉnh 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ẽ bật lê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.

1
unicorn.ninja

Sử dụng SSIS để trích xuất và xử lý thông tin. Theo cách đó, bạn sẽ xử lý các tệp XML được tách ra khỏi SQL Server. Bạn cũng có thể thực hiện các phép biến đổi SSIS trên một máy chủ riêng nếu cần. Lưu trữ số điện thoại ở định dạng chuẩn bằ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à '-'.

1
Magnus Johansson

Tôi nhận ra chủ đề này đã cũ, nhưng đáng nói đế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.

IE

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

Luôn 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à truy xuất cả hai sẽ có hiệu quả.

Cảm ơn bạn.

0
Jayghosh Wankar