Sử dụng unique constraint
. Cố gắng chèn / cập nhật bản ghi và bắt ngoại lệ được ném ra khi giới hạn duy nhất bị vi phạm. Đây là cách duy nhất để đảm bảo một địa chỉ e-mail duy nhất; việc kiểm tra đầu tiên và sau đó cập nhật dễ xảy ra các vấn đề đồng thời vì có thể ai đó cập nhật bản ghi của họ về cùng một giá trị mà bạn đang cố gắng đặt ngay sau khi bạn kiểm tra và trước khi cập nhật bản ghi.
Ngoài ra:hãy tìm hiểu cách sử dụng where
-điều khoản. Bây giờ bạn đang truy xuất TẤT CẢ các bản ghi, lặp lại chúng, v.v., việc này tốn nhiều tài nguyên không ngừng, mất quá nhiều thời gian và chỉ là một sự lãng phí đơn giản. Nếu bạn muốn kiểm tra một bản ghi phù hợp với tiêu chí bạn viết:
Select foo, bar from table where baz = 123
Trong đó baz = 123 là tiêu chí của bạn. Hãy tưởng tượng điều gì sẽ xảy ra khi bạn có 500 hoặc thậm chí 500.000 bản ghi trong thiết lập hiện tại của mình. Cơ sở dữ liệu sẽ thực thi truy vấn của bạn, thu thập TẤT CẢ các hàng từ cơ sở dữ liệu đó, chuyển chúng đến ứng dụng của bạn, nơi ứng dụng của bạn sẽ lặp lại tất cả 500.000 kết quả. Hoặc bạn yêu cầu DB làm những gì nó giỏi (và tại sao bạn lại sử dụng nó ngay từ đầu):Đưa ra (các) bản ghi phù hợp với tiêu chí X. Bạn sẽ nhận được 1 hoặc không có bản ghi nào (nếu là duy nhất ràng buộc):1 =một số bản ghi phù hợp với tiêu chí của bạn, none =không có bản ghi nào tồn tại. Tiết kiệm việc chuyển và "phải xem thủ công" 499.999 bản ghi;-)
