Cột nhận dạng lại hạt giống: khi cần thiết?

Trong một trong những bài học cuối cùng tại trường đại học (Tôi là sinh viên), giảng viên đã yêu cầu chúng tôi phát triển cơ sở dữ liệu (Máy chủ MySQL nếu có vấn đề) và ứng dụng khách nhỏ sẽ sử dụng cơ sở dữ liệu làm nguồn dữ liệu.

Một trong những yêu cầu là cột nhận dạng (là PK trong mỗi bảng) phải tuần tự, bởi vì đó là một thông lệ tốt (theo từ của giảng viên). Đó là, khi hàng của bảng bị xóa, PK phải được sử dụng lại trong các lần chèn tiếp theo. Tôi có kiến ​​thức trung bình về RDBMS, PK và các cột định danh. Theo những gì tôi hiểu, cột nhận dạng đó chỉ là một cách để DB tự động tạo PK khi chèn hàng và không có gì nữa. Và giá trị cột danh tính sẽ không liên quan đến các thuộc tính hàng theo bất kỳ cách nào (miễn là nó không phải là khóa tự nhiên).

Yêu cầu này (cột nhận dạng tuần tự nghiêm ngặt) là đáng ngờ đối với tôi. Tôi đã cố gắng hỏi giảng viên điều gì sai nếu danh tính không tuần tự (với những khoảng trống gây ra bởi việc xóa), nhưng nhận được câu trả lời rất trừu tượng như "nó thuận tiện cho người dùng và hữu ích cho các quản trị viên DB duy trì cơ sở dữ liệu". Không có ví dụ cụ thể. Đối số "thuận tiện cho người dùng" nghe có vẻ ngớ ngẩn, bởi vì nó không có ý nghĩa gì trong lĩnh vực kinh doanh.

Vì vậy, tôi tò mò nếu những lý do này là có thật? Tôi chỉ có thể nghĩ về một trường hợp khi cột định danh được yêu cầu - khi không gian nhận dạng đã hết. Nhưng đây là vấn đề thiết kế nhiều hơn khi loại cột nhận dạng được chọn không chính xác, nói đơn giản intthay vì biginthoặc uniqueidentifierkhi bảng chứa hàng tỷ hàng. Giả sử, một cột danh tính là một chỉ mục được nhóm: các khoảng trống trong cột danh tính có thể ảnh hưởng đến hiệu suất của chỉ mục không? Có thể có những lý do trong thế giới thực khác để tái tạo cột nhận dạng tự động sau mỗi lần xóa mà tôi không biết?

Cảm ơn trước!

Đó là, khi hàng của bảng bị xóa, PK phải được sử dụng lại trong các lần chèn tiếp theo.

Giảng viên của bạn đến từ vũ trụ nào ??

Đó là không hiệu quả tổng thể. Nếu bạn cố gắng làm điều đó, bạn sẽ cắt giảm triển vọng hiệu suất của mình xuống 10 lần.

Nếu bạn cần số không có khoảng cách vì lý do kiểm toán, hãy xây dựng chúng một cách rõ ràng, không trực tiếp từ các công cụ cơ sở dữ liệu. Và không bao giờ xóa hàng, nhưng đánh dấu chúng là "đã xóa". Điều này sẽ thêm vào sự lộn xộn của các truy vấn, vì họ sẽ phải bỏ qua các hàng như vậy.

Trong MySQL, InnoDB yêu cầu sự tồn tại của một PRIMARY KEYbảng duy nhất . Nhưng đó là mức độ của yêu cầu. Khóa thậm chí có thể là một chuỗi.

Khoảng trống là một thuận tiện cho người dùng và DBA, không phải là một sự bất tiện.

Tôi có thể nghĩ về một trường hợp trong đó gapless sẽ thuận tiện - chia thành các nhóm 100 hàng cùng một lúc. Nhưng có một cách giải quyết đơn giản LIMIT 100,1.

Khoảng cách không ảnh hưởng đến hiệu suất. Điều đó bao gồm các chỉ mục không số. Và chỉ số không độc đáo. Và chỉ số tổng hợp.

Chắc chắn, bạn có thể hết ids. Tôi nghĩ rằng tôi đã thấy nó xảy ra hai lần trong gần 2 thập kỷ sử dụng MySQL. Tôi cũng có thể lo lắng về việc bị một tiểu hành tinh tấn công. Đó là thấp trong danh sách những thứ mà tôi giữ cho tôi thức vào ban đêm.

Lỗ hổng xảy ra từ (ít nhất): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(rõ ràng, hoặc do tai nạn), sao chép Multi-master (bao gồm Galera Tập đoàn Replication). Bạn có thực sự muốn đưa ra cách giải quyết cho những người?!

Vui lòng để chúng tôi tỉnh táo - kiểm tra bất cứ điều gì khác mà giảng viên nói là đáng ngờ.

Việc sử dụng lại một giá trị danh tính, nói chung nên được khuyến khích. Giá trị được sử dụng hoàn toàn trong nội bộ, trong trường hợp đó giá trị thực của nó là không quan trọng hoặc nó cũng được sử dụng bên ngoài trong trường hợp sử dụng lại giá trị rất có thể sẽ dẫn đến xác định sai.

Lấy trường hợp rõ ràng của hóa đơn hoặc số đơn đặt hàng, những thứ này có thể dễ dàng đến từ một cột nhận dạng và được đưa ra bên ngoài, nhưng bạn sẽ không bao giờ muốn sử dụng lại chúng cho chính xác lý do đó. Cả hai đều đề cập đến các giao dịch cụ thể mà bạn không muốn bị nhầm lẫn.

Giải quyết các vấn đề như vậy có thể là một rắc rối lớn khi các công ty hợp nhất hoặc được mua lại. Tạo ra những vấn đề như vậy về mục đích? Không khôn ngoan.

Việc sử dụng lại các giá trị PK id có vấn đề và thường nên tránh.

Đầu tiên, việc triển khai các cột auto_increment không đảm bảo không có khoảng trống. Thật vậy, khoảng cách sẽ xảy ra nếu bạn khôi phục lại một chèn trên cột tăng tự động.

Thứ hai, ID khoảng cách có thể đề cập đến dữ liệu hiện tại chưa bị xóa (do thiếu các ràng buộc FK). Nếu họ dịch sang số thành viên được truyền đạt bên ngoài hệ thống thì điều đó có thể gây ra rủi ro nhận dạng doanh nghiệp tiềm năng.

Thứ ba, bigint unsignedsẽ không hết ID trong một thời gian đáng kể thậm chí với tỷ lệ chèn cực lớn.

Nỗi đau lớn nhất với những khoảng trống đang xảy ra với các kiểm toán viên, những người khăng khăng cho rằng đó là một lỗ hổng kiểm toán. Đối với các DBA họ biết khoảng trống tồn tại và tại sao.

Tôi sẽ không nhắc lại ý kiến ​​của mọi người rằng việc tái sử dụng PK là một ý tưởng tồi nhưng tôi đã tình cờ thấy một cột nhận dạng cần phải được gieo lại.

Tham nhũng của chính chỉ số PK.

Cấp điều này đã sử dụng MS-SQL và nhiều, nhiều năm trước nhưng nó vẫn có liên quan. Cách đây nhiều năm đối với công ty mà tôi làm việc, có người nghĩ rằng nên sử dụng lại PC làm máy chủ ở hơn 150 địa điểm từ xa của chúng tôi sau khi chúng quá cũ để được khách hàng sử dụng và sau đó dán chúng vào tủ quần áo không có thông gió. Khi không Bởi vì tất cả chúng ta đều biết rằng một đống rác máy tính 10 năm tuổi trong một căn phòng nhỏ với hơn 120 cơ sở dữ liệu quan trọng đang chạy chỉ có thể mang lại kết quả tốt. Giống như tỷ lệ thất bại 40% và tôi suy nghĩ lại về lựa chọn nghề nghiệp của mình. Chúng tôi sẽ sao chép dữ liệu trở lại trụ sở công ty nhưng thường xuyên hơn không, những thất bại này sẽ dẫn đến những điều tồi tệ xảy ra với cơ sở dữ liệu. Một trong những điều đó là cơ sở dữ liệu có các chỉ mục bị hỏng sẽ chiếm lấy cơ sở dữ liệu và quá trình sao chép. Hai lần trong môi trường tuyệt vời này, giải pháp duy nhất để khắc phục sự sao chép là lấy lại các chỉ mục và sau đó thiết lập lại nhân rộng. Chúng tôi đã thay thế các máy chủ sau đó trước khi bỏ chúng hoàn toàn.