Cột định danh hoặc UDF rõ ràng tạo ra một id duy nhất?

Tôi đang ở giữa một cuộc tranh luận về việc liệu có tốt hơn để tạo PRIMARY KEYra một Cột Danh tính hay không , từ UDF của chúng tôi tạo ra một id duy nhất.

• Tôi đang tranh luận cho cột danh tính.
• Đối tác của tôi đang tranh cãi về việc tạo ra các giá trị bằng tay, ông tuyên bố
  • bằng cách đặt UDF trên một bảng khác nơi chúng ta có thể có UDF
    • khóa tài nguyên
    • tăng một bảng ID với một trường được gọi ID_Valuebởi1
    • sử dụng này như một định danh duy nhất toàn cầu
  • Hoặc có bảng làm một id+1khi chèn
  • Việc di chuyển dữ liệu giữa các máy chủ và / hoặc môi trường không có ràng buộc xác định sẽ đơn giản hơn; di chuyển từ một DB nơi có dữ liệu sang một DB tương tự khác với giả sử dữ liệu dàn hoặc giả. Để thử nghiệm trong sản xuất không, chúng tôi có thể muốn kéo tất cả các hồ sơ từ ngày hôm qua xuống để dàn dựng để thử nghiệm.

Việc thực hiện nào có ý nghĩa hơn?

Đồng nghiệp của bạn là một thằng ngốc.

Giải pháp sẽ không thể mở rộng, UDF không đồng thời ( lý do tương tự như thế này ). Và làm thế nào để bạn đối phó với các chèn nhiều hàng: điều này sẽ yêu cầu một cuộc gọi UDF trên mỗi hàng

Và việc di chuyển sang RDBMS khác không xảy ra thường xuyên trong cuộc sống thực ... bạn cũng có thể không sử dụng SQL Server ngay bây giờ và sử dụng các trình tự trên Oracle và hy vọng bạn không di chuyển đi.

Biên tập:

Cập nhật của bạn nói rằng việc di chuyển dữ liệu là để làm mới cơ sở dữ liệu phi sản xuất.

Trong trường hợp đó, bạn bỏ qua các cột danh tính khi làm mới. Bạn không thỏa hiệp việc triển khai của mình để làm cho việc tải không dễ dàng hơn. Hoặc sử dụng bảng tạm thời để theo dõi các thay đổi giá trị danh tính.

Hoặc sử dụng các quy trình: chúng tôi làm mới hệ thống kiểm tra của mình mỗi đêm từ sản xuất để tránh vấn đề hoàn toàn. (Và đảm bảo sao lưu prod của chúng tôi cũng có thể được khôi phục)

Sử dụng một giá trị nhận dạng. Việc tạo bảng tuần tự và các giá trị trình tự của riêng bạn sẽ tốn rất nhiều chi phí và gây ra nhiều khóa và chặn trong khi cố gắng tạo số.

Danh tính tồn tại vì một lý do, sử dụng nó.

Khi SQL Denali xuất hiện, nó sẽ hỗ trợ các chuỗi sẽ hiệu quả hơn danh tính, nhưng bạn không thể tự tạo ra thứ gì đó hiệu quả hơn.

Đối với việc di chuyển các bản ghi từ môi trường này sang môi trường khác, hãy bật IDENTITY_INSERT ON khi thực hiện thao tác chèn hoặc chọn hộp trong SSIS.

Cột nhận dạng âm thanh tốt với tôi. Tôi không chắc chắn tôi tuân theo logic về lý do tại sao khó di chuyển dữ liệu giữa các máy chủ.

Nếu bạn muốn mỗi hàng có một danh tính duy nhất trên toàn cầu, bạn có thể sử dụng UUID nhưng tôi sẽ không làm điều đó trừ khi bạn chắc chắn rằng tính duy nhất toàn cầu là cần thiết - thường thì không. Sử dụng UUID làm id sẽ làm giảm hiệu suất, tăng yêu cầu dung lượng ổ đĩa và khiến việc gỡ lỗi khó khăn hơn - vì độ dài khó nhớ UUID, nói với ai đó qua điện thoại hoặc viết ra giấy mà không gặp lỗi.

Đối với ID số đơn giản, chỉ cần đi với danh tính và quên tất cả các vấn đề về việc tạo chúng theo cách thủ công.

Bạn luôn có thể tạo một "siêu bảng" sử dụng danh tính làm PK và có một cột loại và bất kỳ thông tin nào khác. Khi bạn cần một ID mới (giả sử bạn có nghĩa là ID duy nhất trên các bảng khác nhau), chỉ cần chèn vào bảng này và lấy SCOPE_IDENTITY()và sau đó chèn vào bảng thực tế bạn cần.

Về cơ bản, bạn tạo một bảng: MasterID với PK nhận dạng, khi bạn cần chèn một hàng vào Bảng 1 INSERT INTO MasterIDsvà lấy danh tính được tạo bởi hàng đó bằng cách sử dụng SCOPE_IDENTITY()và sau đó chèn vào Bảng 1 bằng cách sử dụng giá trị đó làm PK.

Bảng 1 sẽ có một PK không nhận dạng. Bạn sẽ thực hiện quy trình tương tự để chèn vào Bảng2, v.v. Hãy để SQL Server quản lý các giá trị nhận dạng trong bảng MasterID , sau đó bạn có thể sử dụng trong các bảng khác của mình. MasterID có thể chứa các bảng khác, như kiểu (vì vậy bạn có thể biết bảng nào, Bảng1 hoặc Bảng2, v.v., sử dụng giá trị nhận dạng đó.

Miễn là bạn đang sử dụng các ràng buộc khóa ngoại đúng cách (xếp tầng, cập nhật, v.v.) thì bạn sẽ ổn khi sử dụng trường nhận dạng. Tôi thực sự không thấy lợi thế cho giải pháp khác trong trường hợp này.

Danh tính đã được thực hiện để phù hợp với kịch bản của bạn. Bạn có các công cụ như sao chép để trao đổi dữ liệu máy chủ / môi trường giữ cho tất cả cùng nhau.

Tôi vừa hoàn thành một phần công việc mà tôi đã thay thế một identitycột Máy chủ SQL bằng một inttrường bình thường và tự phân bổ Id được kiểm soát.

Tôi đã thấy hiệu suất tăng khá ấn tượng. Không giống như OP, tôi không có UDF để tạo id. Nhưng nguyên tắc khá giống nhau: Có một phần của phần mềm duy trì một nhóm id. Khi họ hết, nó nhận được một đợt khác bằng cách truy vấn cơ sở dữ liệu cho giá trị Thấp tiếp theo và tăng giá trị này lên mức cao tiếp theo .

Điều này cho phép chúng tôi tạo id và liên kết tất cả các thực thể bên ngoài giao dịch trong ORM của chúng tôi trước khi chúng tôi gửi các lô vào cơ sở dữ liệu và cũng gửi các lô lớn hơn mà không cần thêm vòng để nhận dạng vừa được chèn (theo yêu cầu của các cột định danh).

Trong bảng id, chúng tôi có nhiều hơn một hàng, cho phép chúng tôi sử dụng các phạm vi cụ thể nếu muốn. tức là để sử dụng lại các khối bị xóa và id âm.

Tôi đã sử dụng danh tính trong nhiều năm và nghiêm túc xem xét việc thay thế số định danh bằng UNIQUEIDENTIFIER. Đó là một cơn ác mộng khi bạn cần thay đổi loại dữ liệu nếu ai đó đã thiết kế nó thành một db nhỏ gọn và ác mộng nếu bạn cần thêm danh tính vào một cột, ngoài ra, bạn không thể cập nhật cột nhận dạng. Hãy tưởng tượng bạn đặt một int và cơ sở dữ liệu của bạn phát triển vượt quá 2 tỷ bản ghi, một lần nữa là cơn ác mộng để thay đổi (xem xét FK)! Thay đổi bất cứ điều gì với danh tính là một cơn ác mộng và không thân thiện với quy mô trừ khi bạn đặt bigint! UNIQUEIDENTIFIER vs Danh tính = tiện lợi và mạnh mẽ so với cải thiện hiệu suất có thể đáng chú ý (không làm điểm chuẩn).

Cập nhật: Sau khi tôi thấy điều này, tôi chắc chắn nghiêng về UNIQUEIDENTIFIER. Điều này cho thấy không có lợi ích thực sự của bản sắc bigint và một loạt các lợi ích cho UNIQUEIDENTIFIER! Các phiên bản khác nhau của SQL Server có thể có kết quả khác nhau. Có vẻ đẹp khi có một id duy nhất trên tất cả các cơ sở dữ liệu và hệ thống (độ mạnh)! Di chuyển, sao chép, chuyển đổi dữ liệu như bạn muốn! https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/