2008-11-14 88 views
18

Trong 3 công ty gần đây nhất mà tôi đã làm việc, các cột số điện thoại có dạng varchar (n). Lý do là họ có thể muốn lưu trữ các phần mở rộng (ext. 333). Nhưng trong mọi trường hợp, các ký tự "-" bị loại bỏ khi chèn và cập nhật. Tôi không hiểu lý do tại sao các ký tự ".ext" được phép lưu trữ nhưng không được lưu giữ ký tự "-". Có ai khác nhìn thấy điều này và giải thích những gì bạn có thể nghĩ đến để làm điều đó theo cách này? Nếu tất cả các bạn muốn lưu trữ là những con số, sau đó không phải là bạn tốt hơn bằng cách sử dụng một lĩnh vực int? Ngược lại, nếu bạn muốn lưu trữ số như một chuỗi/varchar, thì tại sao không giữ tất cả các ký tự và không bận tâm với định dạng trên màn hình và làm sạch khi viết?Cột số điện thoại trong cơ sở dữ liệu

Tôi cũng quan tâm đến việc nghe về các cách khác trong đó lưu trữ số điện thoại được triển khai ở những nơi khác.

+4

@Onorio: Đó không phải là cách nó hoạt động ở đây. Bỏ phiếu để đóng nó như là một bản sao chính xác, không downvote. – mpen

+0

Vào thời điểm đó tôi dường như nhớ lại không có khả năng bỏ phiếu để đóng. Nhưng tôi sẽ ghi nhớ điều đó cho những trường hợp trong tương lai. –

Trả lời

12

một thời điểm với việc lưu trữ số điện thoại là một lãnh đạo 0.

ví dụ: 01202 8765432

trong một cột int, 0 sẽ bị tước, mà làm cho số điện thoại không hợp lệ.

tôi sẽ đánh bạo đoán tại - được hoán đổi cho các không gian được vì họ không thực sự có ý nghĩa gì

ví dụ: 123-456-789 = 123 456 789 = 123456789

+2

Dẫn đầu 0 là một điểm tuyệt vời để gắn bó với chuỗi cho số điện thoại ... – Codewerks

29

kiểm tra nhanh: thì bạn sẽ thế nào để cộng/trừ/nhân/chia số điện thoại? Không. Tương tự như SSN, Số điện thoại là những phần dữ liệu rời rạc có thể chứa số thực, do đó, một loại chuỗi có lẽ là thích hợp nhất.

+2

Logic tuyệt vời. Thật dễ dàng để bị mắc kẹt trong tâm lý suy nghĩ về chữ số như số. Bạn nói rất đúng. Ở đây, các chữ số không thực sự là số nhưng chuỗi/văn bản/varchar loại. Tôi yêu khi có ai đó chỉ ra những giả định mà tôi tạo ra mà không nhận ra tôi tạo ra chúng. – Dinah

+0

Có, một loại chuỗi là thích hợp nhất - miễn là nó có các ràng buộc kiểm tra. –

+0

Đồng ý. Mã zip, số hiệu đường phố là các ví dụ hay về các trường mà bạn không muốn tạo số. – dpurrington

0

Tước một số ký tự và cho phép những người khác có thể có tác động nếu bảng cơ sở dữ liệu sẽ thúc đẩy một hệ thống khác, ví dụ: IP Telephony của một số loại. Tùy thuộc vào các hệ thống liên quan, có thể hợp pháp để có etc.333 như một hậu tố, trong khi các nhà phát triển có thể không chiếm "-" trong chuỗi (và có, tôi đoán ở đây ...)

để lưu trữ dưới dạng một varchar chứ không phải là int, đây chỉ là cảm giác thông thường đối với tôi. Như đã đề cập trước đó, số 0 đứng đầu có thể bị tước trong trường int, truy vấn trên một trường int có thể thực hiện các hàm toán học ngầm định (cũng có thể giải thích tước "-" khỏi văn bản, bạn không muốn nhập 555-1234 và có nó được lưu trữ như -679 làm bạn?)

Tóm lại, tôi không biết lý do chính xác, nhưng có thể suy ra một số khả năng.

+0

Nó sẽ không thông minh hơn để lưu trữ dữ liệu dưới dạng dễ đọc hơn, và phân tích các ký tự cần thiết ngay lập tức trước khi gửi đi với hệ thống điện thoại. – Kibbee

+0

Nó có thể là, có. Tôi không thiết kế một hệ thống, chỉ cung cấp các giải thích có thể. :) – ZombieSheep

3

Cá nhân, tôi sẽ không loại bỏ bất kỳ ký tự nào, tùy thuộc vào nơi số điện thoại đến từ đâu, nó có thể có nghĩa là những thứ khác nhau. Để lại số điện thoại ở định dạng chính xác mà nó đã được nhập, vì rõ ràng đó là cách người gõ vào được sử dụng để xem nó.

0

Tôi muốn chọn lưu trữ các chữ số dưới dạng chuỗi và thêm "()" và "-" khác nhau vào mã hiển thị của tôi. Nó trở nên khó khăn hơn với các số quốc tế. Chúng tôi xử lý nó bằng cách có các định dạng hiển thị "quốc tế hóa" khác nhau tùy theo quốc gia.

1

Không quan trọng bạn lưu trữ nó như thế nào, miễn là nó phù hợp. Định mức là loại bỏ các ký tự định dạng, nhưng bạn cũng có thể lưu trữ mã quốc gia, mã vùng, trao đổi và tiện ích riêng biệt nếu bạn có nhu cầu truy vấn các giá trị đó. Một lần nữa, yêu cầu là nó nhất quán - nếu không truy vấn nó là một PITA.

0

Điều tôi muốn làm nếu tôi biết số điện thoại sẽ chỉ nằm trong một khu vực cụ thể, chẳng hạn như Bắc Mỹ, là thay đổi mục nhập thành 4 trường. 3 cho mã vùng, 3 cho tiền tố, 3 cho dòng, và có thể 5 cho phần mở rộng.Sau đó tôi chèn các trường này dưới dạng 1 với '-' và có thể là 'e' để chỉ định phần mở rộng. Bất kỳ tìm kiếm tất nhiên cũng cần phải làm theo cùng một quá trình. Điều này đảm bảo tôi nhận được dữ liệu thường xuyên hơn và thậm chí cho phép số được sử dụng để thực sự thực hiện cuộc gọi điện thoại, sau khi - và tiện ích được xóa. Tôi cũng có thể quay lại 4 trường gốc một cách dễ dàng.

0

Tốt! Dường như điểm chính là định dạng của số điện thoại không thực sự là một phần của dữ liệu mà thay vào đó là một khía cạnh của quốc gia nguồn. Tuy nhiên, bằng cách giữ phần mở rộng của số như, người ta có thể phá vỡ mô hình tách định dạng khỏi dữ liệu. Tôi nghi ngờ rằng tất cả các quốc gia sử dụng cùng một cú pháp/định dạng để mô tả một phần mở rộng. Ngoài ra, nếu tích hợp với hệ thống điện thoại là một yêu cầu (có thể), thì có thể tốt hơn để lưu trữ tiện ích mở rộng riêng biệt và tạo thông báo như mong đợi. Nhưng Mark cũng làm cho một điểm tốt rằng nếu bạn nhất quán, thì có lẽ nó sẽ không quan trọng làm thế nào bạn lưu trữ nó kể từ khi bạn có thể truy vấn và xử lý nó một cách nhất quán là tốt.

Cảm ơn bạn đã gửi liên kết đến câu hỏi khác cho Eric.

1

Một lý do khác khiến tôi không thể lưu trữ số điện thoại là 'số' mà là chuỗi ký tự, là phần đủ thường xuyên của ngăn xếp phần mềm bạn sử dụng để truy cập cơ sở dữ liệu (PHP, tôi nhìn bạn) sẽ không hỗ trợ số nguyên đủ lớn (nguyên bản) để có thể lưu trữ một số số điện thoại dài hơn và/hoặc kỳ lạ.

lớn nhất con số đó 32-bit có thể mang theo, không dấu, là 4294967295. Điều đó sẽ không làm việc cho bất kỳ chỉ số điện thoại di động của Nga, đưa, ví dụ, số 4959261234.

Vì vậy, bạn có cho mình một thêm sự bất tiện khi tìm cách mang dữ liệu số hơn 32 bit. Mặc dù các cơ sở dữ liệu từ lâu đã hỗ trợ các số nguyên rất lớn, nhưng bạn chỉ cần một liên kết xấu trong chuỗi cho một showstopper. Giống như PHP, một lần nữa.

0

Khi hệ thống điện thoại tự động sử dụng một trường để thực hiện cuộc gọi điện thoại, nó có thể không thể cho biết những ký tự nào cần sử dụng và nó nên bỏ qua khi quay số. Một con người có thể nhìn thấy một ký tự "(" hoặc ")" hoặc "-" và biết chúng được coi là dấu phân cách tách mã vùng, npa và nxx của số điện thoại. Hãy nhớ rằng mặc dù mỗi ký tự đại diện cho một mẫu nhị phân, trừ khi được lập trình trước để bỏ qua, sẽ được trình quay số tự động nhập vào. Để giải thích điều này, tốt hơn là chỉ lưu trữ các ký tự mà người dùng sẽ nhấn trên điện thoại và thậm chí tốt hơn là các giá trị riêng lẻ được lưu trữ trong các cột riêng biệt sao cho trình quay số có thể sử dụng các trường riêng lẻ mà không phải phân tích chuỗi.

Thậm chí nếu không sử dụng tính năng tự động quay số, bạn nên lưu trữ những thứ bạn không cần phải cập nhật trong tương lai. Việc thêm các ký tự giữa các trường dễ dàng hơn nhiều so với các chuỗi ký tự.

Nhận xét về việc sử dụng kiểu dữ liệu chuỗi so với số nguyên như đã lưu ý ở trên là cách thích hợp để lưu số điện thoại dựa trên các biến thể giữa các quốc gia. Có một thông báo quan trọng cho rằng mặc dù trong đó, trong khi tổng hợp thống kê để báo cáo (tức là SUM của bao nhiêu số hoặc cuộc gọi) chuỗi ký tự được MUCH chậm hơn để đếm hơn số nguyên. Để giải thích cho điều quan trọng này là thêm một số nguyên làm cột nhận dạng mà bạn có thể sử dụng để đếm thay vì varchar hoặc kiểu dữ liệu trường char.

Các vấn đề liên quan