Sử dụng địa chỉ email làm khóa chính?

Địa chỉ email có phải là ứng cử viên tồi cho chính khi so sánh với số tự động tăng không?

Ứng dụng web của chúng tôi cần địa chỉ email là duy nhất trong hệ thống. Vì vậy, tôi nghĩ đến việc sử dụng địa chỉ email làm khóa chính. Tuy nhiên, đồng nghiệp của tôi cho rằng so sánh chuỗi sẽ chậm hơn so với so sánh số nguyên.

Đây có phải là một lý do hợp lệ để không sử dụng email làm khóa chính?

Chúng tôi đang sử dụng PostgreSQL.

So sánh chuỗi chậm hơn so với so sánh int. Tuy nhiên, điều này không quan trọng nếu bạn chỉ cần truy xuất người dùng từ cơ sở dữ liệu bằng địa chỉ email. Không thành vấn đề nếu bạn có các truy vấn phức tạp với nhiều phép nối.

Nếu bạn lưu trữ thông tin về người dùng trong nhiều bảng, các khóa ngoại đối với bảng người dùng sẽ là địa chỉ email. Điều đó có nghĩa là bạn lưu trữ địa chỉ e-mail nhiều lần.

Tôi cũng sẽ chỉ ra rằng email là một lựa chọn tồi để tạo ra một lĩnh vực độc đáo, có những người và thậm chí các doanh nghiệp nhỏ chia sẻ một địa chỉ email. Và giống như số điện thoại, email có thể được sử dụng lại. Jsmith@somecompany.com có ​​thể dễ dàng thuộc về John Smith một năm và Julia Smith hai năm sau đó.

Một vấn đề khác với email là chúng thay đổi thường xuyên. Nếu bạn đang tham gia vào các bảng khác với khóa đó, thì bạn sẽ phải cập nhật các bảng khác cũng có thể là một hiệu suất khá cao khi toàn bộ công ty khách hàng thay đổi email của họ (điều mà tôi đã thấy xảy ra.)

khóa chính phải là duy nhất và không đổi

địa chỉ email thay đổi như các mùa. Hữu ích như một khóa phụ để tra cứu, nhưng là một lựa chọn kém cho khóa chính.

Nhược điểm của việc sử dụng địa chỉ email làm khóa chính:

1. Chậm hơn khi làm tham gia.

2. Bất kỳ bản ghi nào khác có khóa ngoại được đăng bây giờ đều có giá trị lớn hơn, chiếm nhiều dung lượng đĩa hơn. (Với chi phí không gian đĩa ngày nay, đây có lẽ là một vấn đề nhỏ, ngoại trừ mức độ mà bản ghi bây giờ mất nhiều thời gian hơn để đọc. Xem # 1.)

3. Một địa chỉ email có thể thay đổi, buộc tất cả các bản ghi sử dụng khóa này làm khóa ngoại được cập nhật. Vì địa chỉ email không thay đổi thường xuyên, vấn đề về hiệu suất có thể là nhỏ. Vấn đề lớn hơn là bạn phải đảm bảo cung cấp cho nó. Nếu bạn phải viết mã, đây là công việc nhiều hơn và giới thiệu khả năng lỗi. Nếu công cụ cơ sở dữ liệu của bạn hỗ trợ "trên tầng cập nhật", thì đó là một vấn đề nhỏ.

Ưu điểm của việc sử dụng địa chỉ email làm khóa chính:

1. Bạn có thể loại bỏ hoàn toàn một số tham gia. Nếu tất cả những gì bạn cần từ "bản ghi chính" là địa chỉ email, thì với một khóa số nguyên trừu tượng, bạn sẽ phải thực hiện một phép nối để lấy nó. Nếu khóa là địa chỉ email, thì bạn đã có nó và việc tham gia là không cần thiết. Điều này có giúp gì cho bạn hay không phụ thuộc vào mức độ thường xuyên xảy ra tình huống này.

2. Khi bạn đang thực hiện các truy vấn đặc biệt, con người sẽ dễ dàng nhận thấy bản ghi chính nào đang được tham chiếu. Điều này có thể là một trợ giúp lớn khi cố gắng theo dõi các vấn đề dữ liệu.

3. Bạn gần như chắc chắn sẽ cần một chỉ mục trên địa chỉ email, vì vậy, làm cho nó trở thành khóa chính loại bỏ một chỉ mục, do đó cải thiện hiệu suất của các phần chèn vì giờ đây chúng chỉ có một chỉ mục để cập nhật thay vì hai.

Theo ý kiến ​​khiêm tốn của tôi, đó cũng không phải là một cú hích. Tôi có xu hướng thích sử dụng các phím tự nhiên khi có sẵn một phím thực tế vì chúng chỉ dễ làm việc hơn và các nhược điểm có xu hướng không thực sự quan trọng trong hầu hết các trường hợp.

Nó là khá xấu. Giả sử một số nhà cung cấp e-mail đi ra khỏi kinh doanh. Người dùng sau đó sẽ muốn thay đổi e-mail của họ. Nếu bạn đã sử dụng e-mail làm khóa chính, tất cả các khóa ngoại cho người dùng sẽ sao chép e-mail đó, khiến việc thay đổi khá khó khăn ...

... và tôi thậm chí chưa bắt đầu nói về những cân nhắc về hiệu suất.

Tôi không biết đó có phải là một vấn đề trong thiết lập của bạn không, nhưng tùy thuộc vào RDBMS của bạn, các giá trị của các cột có thể phân biệt chữ hoa chữ thường . Các tài liệu của PostgreSQL nói: „Nếu bạn khai báo một cột là UNIQUE hoặc PRIMARY KEY, chỉ mục được tạo ngầm định là phân biệt chữ hoa chữ thường. Nói cách khác, nếu bạn chấp nhận đầu vào của người dùng cho tìm kiếm trong một bảng có email là khóa chính và người dùng cung cấp "John@Doe.com", bạn sẽ không tìm thấy ra john@doe.com ".

Không ai có vẻ đã đề cập đến một vấn đề có thể xảy ra là địa chỉ email có thể được coi là riêng tư. Nếu địa chỉ email là khóa chính, rất có thể URL của trang hồ sơ sẽ trông giống như vậy ..../Users/my@email.com. Nếu bạn không muốn tiết lộ địa chỉ email của người dùng thì sao? Bạn sẽ phải tìm một số cách khác để xác định người dùng, có thể bằng một giá trị số nguyên duy nhất để tạo URL như thế nào ..../Users/1. Sau đó, cuối cùng bạn sẽ có một giá trị số nguyên duy nhất.

Ở cấp độ logic , email là chìa khóa tự nhiên. Ở cấp độ vật lý , do bạn đang sử dụng cơ sở dữ liệu quan hệ, khóa tự nhiên không phù hợp với khóa chính. Lý do chủ yếu là các vấn đề hiệu suất được đề cập bởi những người khác.

Vì lý do đó, thiết kế có thể được điều chỉnh. Khóa tự nhiên trở thành khóa thay thế (UNIQUE, KHÔNG NULL) và bạn sử dụng khóa thay thế / nhân tạo / kỹ thuật làm khóa chính, có thể là tự động tăng trong trường hợp của bạn.

hệ thống hỏi,

Nếu ai đó muốn thay đổi địa chỉ email của mình thì sao? Bạn sẽ thay đổi tất cả các khóa ngoại?

Đó là những gì tầng dành cho.

Một lý do khác để sử dụng khóa thay thế số làm khóa chính có liên quan đến cách lập chỉ mục hoạt động trong nền tảng của bạn. Ví dụ, trong InnoDB của MySQL, tất cả các chỉ mục trong bảng đều có khóa chính được cấp trước cho chúng, vì vậy bạn muốn PK càng nhỏ càng tốt (đối với các tốc độ và kích thước). Cũng liên quan đến điều này, InnoDB nhanh hơn khi khóa chính được lưu theo trình tự và một chuỗi sẽ không giúp ích gì ở đó.

Một điều khác cần xem xét khi sử dụng một chuỗi làm khóa thay thế, đó là sử dụng hàm băm của chuỗi thực tế mà bạn muốn có thể nhanh hơn, bỏ qua những thứ như chữ hoa và chữ thường của một số chữ cái. (Tôi thực sự đã hạ cánh ở đây trong khi tìm kiếm một tài liệu tham khảo để xác nhận những gì tôi vừa nói; vẫn đang tìm kiếm ...)

vâng, tốt hơn nếu bạn sử dụng một số nguyên thay thế. bạn cũng có thể đặt cột email của mình dưới dạng ràng buộc duy nhất.

như thế này:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

Có, đó là một khóa chính xấu vì người dùng của bạn sẽ muốn cập nhật địa chỉ email của họ.

Một lý do khác tại sao khóa chính số nguyên tốt hơn là khi bạn tham khảo địa chỉ email trong bảng khác nhau. Nếu địa chỉ là một khóa chính thì trong một bảng khác, bạn phải sử dụng nó làm khóa. Vì vậy, bạn lưu trữ địa chỉ email nhiều lần.

Tôi không quá quen thuộc với postgres. Khóa chính là một chủ đề lớn. Tôi đã thấy một số câu hỏi và câu trả lời tuyệt vời trên trang web này (stackoverflow.com).

Tôi nghĩ rằng bạn có thể có hiệu suất tốt hơn bằng cách có khóa chính số và sử dụng INDI ĐỘC ĐÁO trên cột email. Email có xu hướng thay đổi về chiều dài và có thể không phù hợp với chỉ số khóa chính.

một số đọc ở đây và ở đây.

Cá nhân, tôi không sử dụng bất kỳ thông tin nào cho khóa chính khi thiết kế cơ sở dữ liệu, vì rất có thể tôi cần phải thay đổi bất kỳ thông tin nào sau này. Lý do duy nhất mà tôi cung cấp khóa chính là, đó là sự thuận tiện để thực hiện hầu hết các hoạt động SQL từ phía máy khách và sự lựa chọn của tôi luôn luôn là kiểu số nguyên tăng tự động.

Đồng nghiệp của bạn là đúng: Sử dụng số nguyên tự động tăng cho khóa chính của bạn.

Bạn có thể triển khai tính duy nhất của email ở cấp ứng dụng hoặc bạn đánh dấu cột địa chỉ email của bạn là duy nhất và thêm một chỉ mục trên cột đó.

Việc thêm trường là duy nhất sẽ khiến bạn chỉ phải so sánh chuỗi khi chèn vào bảng đó chứ không phải khi thực hiện các phép nối và kiểm tra ràng buộc khóa ngoài.

Tất nhiên, bạn phải lưu ý rằng việc thêm bất kỳ ràng buộc nào vào ứng dụng của bạn ở cấp cơ sở dữ liệu có thể khiến ứng dụng của bạn trở nên không linh hoạt. Luôn luôn cân nhắc trước khi bạn thực hiện bất kỳ trường nào "duy nhất" hoặc "không null" chỉ vì ứng dụng của bạn cần nó là duy nhất hoặc không trống.

Sử dụng GUID làm khóa chính ... theo cách đó bạn có thể tạo nó từ chương trình của mình khi bạn thực hiện INSERT và bạn không cần phải nhận phản hồi từ máy chủ để tìm hiểu khóa chính là gì. Nó cũng sẽ là các bảng và cơ sở dữ liệu duy nhất và bạn không phải lo lắng về những gì sẽ xảy ra nếu bạn cắt bớt bảng một ngày nào đó và việc tăng tự động được đặt lại thành 1.

Tôi biết đây là một mục nhập muộn nhưng tôi muốn thêm rằng mọi người từ bỏ tài khoản email và nhà cung cấp dịch vụ khôi phục địa chỉ cho phép người khác sử dụng nó.

Như @HLGEM đã chỉ ra "Jsmith@somecompany.com có ​​thể dễ dàng thuộc về John Smith một năm và Julia Smith hai năm sau đó." trong trường hợp này John Smith muốn dịch vụ của bạn, bạn phải từ chối sử dụng địa chỉ email của anh ấy hoặc xóa tất cả các hồ sơ liên quan đến Julia Smith.

Nếu bạn phải xóa hồ sơ và chúng liên quan đến lịch sử tài chính của doanh nghiệp tùy thuộc vào luật địa phương, bạn có thể thấy mình trong nước nóng.

Vì vậy, tôi sẽ không bao giờ sử dụng dữ liệu như địa chỉ email, biển số, v.v. làm khóa chính bởi vì dù chúng có vẻ độc đáo đến mức nào ngoài tầm kiểm soát của bạn và có thể cung cấp một số thách thức thú vị mà bạn có thể không có thời gian để giải quyết.

Bạn có thể cần phải xem xét bất kỳ pháp luật quy định dữ liệu áp dụng. Email là thông tin cá nhân và nếu người dùng của bạn là công dân EU chẳng hạn thì theo GDPR, họ có thể hướng dẫn bạn xóa thông tin của họ khỏi hồ sơ của bạn (hãy nhớ điều này áp dụng cho dù bạn ở quốc gia nào).

Nếu bạn cần giữ bản ghi trong cơ sở dữ liệu vì tính toàn vẹn tham chiếu hoặc lý do lịch sử như kiểm toán, sử dụng khóa thay thế sẽ cho phép bạn chỉ NULL tất cả trường dữ liệu cá nhân. Điều này rõ ràng là không dễ dàng nếu dữ liệu cá nhân của họ là khóa chính

bạn có thể tăng hiệu suất bằng cách sử dụng khóa chính số nguyên.

bạn nên sử dụng khóa chính số nguyên. nếu bạn cần cột email là duy nhất, tại sao bạn không chỉ cần đặt một chỉ mục duy nhất trên cột đó?

Nếu bạn có một giá trị không phải là khóa chính thì việc chèn và truy xuất sẽ rất chậm trên dữ liệu lớn.

khóa chính nên được chọn một thuộc tính tĩnh. Vì địa chỉ email không tĩnh và có thể được chia sẻ bởi nhiều ứng viên nên không nên sử dụng chúng làm khóa chính. Ngoài ra, địa chỉ email là các chuỗi thường có độ dài nhất định có thể lớn hơn id duy nhất mà chúng tôi muốn sử dụng [len (email_address)> len (unique_id)] ​​vì vậy sẽ cần nhiều không gian hơn và thậm chí tệ nhất là chúng được lưu trữ nhiều lần dưới dạng khóa ngoại . Và do đó nó sẽ dẫn đến giảm hiệu suất.

Nó phụ thuộc vào bảng. Nếu các hàng trong bảng của bạn đại diện cho địa chỉ email, thì email là ID tốt nhất. Nếu không, thì email không phải là một ID tốt.

Nếu đó đơn giản chỉ là vấn đề yêu cầu email là duy nhất thì bạn có thể tạo một chỉ mục duy nhất với cột đó.

Email là một ứng cử viên chỉ mục duy nhất tốt, nhưng không phải cho khóa chính, nếu đó là khóa chính, bạn sẽ không thể thay đổi địa chỉ email của liên hệ chẳng hạn. Tôi nghĩ rằng các truy vấn tham gia của bạn cũng sẽ chậm hơn.

không sử dụng địa chỉ email làm khóa chính, giữ email là duy nhất nhưng không sử dụng nó làm khóa chính, sử dụng id người dùng hoặc tên người dùng làm khóa chính