Chúng tôi đang làm việc trên một ứng dụng web, người dùng chưa truy cập được. Sếp của tôi nhận thấy rằng các bản ghi mới được tạo có ID hơn 10 000, mặc dù chúng tôi chỉ có dưới 100 bản ghi trong bảng. Cô cho rằng giao diện web vì một số lý do tạo ra một bản ghi tạm thời gấp 100 lần so với bản ghi thực tế (và xóa chúng) và điều này có thể khiến chúng tôi chạy ra khỏi phạm vi trong vòng vài tháng phát hành.
Tôi không nghĩ cô ấy đúng về nguyên nhân của lạm phát ID (đồng nghiệp có thể trả lời đây là kỳ nghỉ, vì vậy chúng tôi không biết chắc chắn), nhưng hãy giả sử rằng cô ấy là như vậy. Cô ấy nói rằng cô ấy ghét sử dụng cột bigint và cô ấy muốn chúng tôi dừng tự động hóa cột ID và viết mã phía máy chủ chọn số nguyên "không sử dụng" đầu tiên và sử dụng nó làm ID.
Tôi là một sinh viên tốt nghiệp khoa học máy tính với ít kinh nghiệm thực tế, làm đầy vai trò nhà phát triển cơ sở. Cô ấy có nhiều năm kinh nghiệm quản lý tất cả các cơ sở dữ liệu của tổ chức chúng tôi và thiết kế hầu hết chúng. Tôi nghĩ rằng cô ấy không chính xác trong trường hợp này, rằng một bigint ID không có gì phải sợ, và việc bắt chước chức năng DBMS có mùi của một antipotype. Nhưng tôi không tin tưởng vào phán đoán của mình.
Các đối số cho và chống lại từng vị trí là gì? Điều gì xấu có thể xảy ra nếu chúng ta sử dụng một bigint, và những nguy hiểm của việc phát minh lại chức năng tự động bánh xe là gì? Có một giải pháp thứ ba tốt hơn một trong hai? Lý do nào khiến cô ấy muốn tránh lạm phát giá trị ID? Tôi cũng muốn nghe về những lý do thực tế - có thể ID bigint hoạt động trên lý thuyết, nhưng gây đau đầu trong thực tế?
Ứng dụng này dự kiến sẽ không xử lý lượng dữ liệu rất lớn. Tôi nghi ngờ rằng nó sẽ đạt 10 000 hồ sơ thực tế trong vòng vài năm tới.
Nếu nó làm cho bất kỳ sự khác biệt, chúng tôi đang sử dụng máy chủ Microsoft SQL. Ứng dụng này được viết bằng C # và sử dụng Linq cho SQL.
Cập nhật
Cảm ơn bạn, tôi tìm thấy câu trả lời hiện tại và ý kiến thú vị. Nhưng tôi sợ bạn hiểu nhầm câu hỏi của tôi, vì vậy chúng chứa những gì tôi muốn biết.
Tôi không thực sự quan tâm đến lý do thực sự của các ID cao. Nếu chúng ta không thể tự tìm thấy nó, tôi có thể hỏi một câu hỏi khác. Điều tôi quan tâm là hiểu quá trình quyết định trong trường hợp này. Đối với điều này, xin vui lòng giả sử rằng ứng dụng sẽ viết 1000 hồ sơ mỗi ngày, sau đó xóa 9999 trong số chúng . Tôi gần như chắc chắn đây không phải là trường hợp, nhưng đây là những gì ông chủ của tôi tin tưởng khi cô ấy đưa ra yêu cầu của mình. Vì vậy, trong các trường hợp giả định này, những ưu và nhược điểm của việc sử dụng bigint hoặc viết mã riêng của chúng tôi sẽ gán ID (theo cách sử dụng lại ID của các bản ghi đã bị xóa, để đảm bảo không có lỗ hổng)?
Về lý do thực tế, tôi hoàn toàn nghi ngờ rằng điều này là do chúng ta đã từng viết mã để nhập dữ liệu từ cơ sở dữ liệu khác, như một bằng chứng về khái niệm rằng việc di chuyển sau này có thể được thực hiện ở một mức độ nhất định. Tôi nghĩ rằng đồng nghiệp của tôi thực sự đã tạo ra hàng ngàn hồ sơ trong quá trình nhập và sau đó xóa chúng. Tôi phải xác nhận nếu đây thực sự là trường hợp, nhưng nếu có, thậm chí không cần phải hành động.