PK là ROWGUIDCOL hoặc sử dụng cột rowguid riêng?

9

Có một cuộc tranh luận kéo dài đang diễn ra ở đây vì vậy tôi muốn nghe ý kiến khác.

Tôi có nhiều bảng với PK nhận dạng duy nhất. Cho dù đây là một ý tưởng tốt nằm ngoài phạm vi ở đây (và nó sẽ không thay đổi bất cứ lúc nào sớm).

Bây giờ, cơ sở dữ liệu phải được hợp nhất được xuất bản và các DEV đang ủng hộ việc sử dụng một cột hàng riêng biệt thay vì đánh dấu PK hiện tại là ROWGUIDCOL.

Về cơ bản, họ nói rằng ứng dụng không bao giờ nên mang vào miền của nó thứ gì đó chỉ được sử dụng bởi bản sao (chỉ là "công cụ DBA" cho chúng).

Từ quan điểm hiệu suất, tôi thấy không có lý do tại sao tôi nên thêm một cột mới để làm điều gì đó tôi có thể làm với một cột hiện có. Hơn nữa, vì đó chỉ là "công cụ DBA", tại sao không để DBA chọn?

Tôi hiểu quan điểm của DEV, nhưng tôi vẫn không đồng ý.

Suy nghĩ?

EDIT: Tôi chỉ muốn nói thêm rằng tôi thuộc thiểu số trong cuộc tranh luận này và các DEV đặt câu hỏi về vị trí của tôi là những người tôi tôn trọng và tin tưởng. Đây là lý do tại sao tôi dùng đến để hỏi ý kiến.
Tôi cũng có thể đang thiếu một cái gì đó và có thể đã hiểu sai quan điểm của họ.

sql-server database-design merge-replication

— spaghettidba
nguồn

Có bất kỳ cơ hội nào mà giá trị PK có thể cần thay đổi trong tương lai không?

— Robert L Davis

Không thật sự lắm. Đó là một khóa thay thế, vì vậy ứng dụng không thực sự làm được gì nhiều với cột đó. Nó không bao giờ thay đổi và nó không bao giờ hiển thị cho người dùng.

— spaghettidba

Tại sao họ muốn một rowguidcol riêng biệt? Và họ sẽ chọn sơ đồ nào, nếu có thể, cho PK, và tại sao?

— JustinC

@spaghettidba Nói về việc vượt qua các miền, bạn có thường xuyên nói với họ những mẫu thiết kế nào họ nên hoặc không nên sử dụng trong mã ứng dụng của họ không? Có lẽ họ nên bám vào "miền" của họ? ;-). Ngoài ra, việc thêm một cột 16 byte vào tất cả các bảng sẽ rất tệ cho hiệu năng và không mang lại lợi ích gì.

— Solomon Rutzky

7

Về cơ bản, họ nói rằng ứng dụng không bao giờ nên mang vào miền của nó thứ gì đó chỉ được sử dụng bởi bản sao (chỉ là "công cụ DBA" cho chúng).

Tôi hoàn toàn đồng ý. Nhưng ... khóa chính không chỉ được sử dụng để sao chép (có lẽ ứng dụng sử dụng nó theo một cách nào đó). Đối số không có ý nghĩa trong bối cảnh này.

Trong mọi trường hợp, theo như tôi biết, chỉ có 2 cách để "công cụ DBA" này vượt qua ranh giới miền:

Nếu ứng dụng đang sử dụng các truy vấn tham chiếu ROWGUIDCOLcột như thế này:
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;
```
Tôi cho rằng chưa có cột nào của bạn có thuộc tính này, vì vậy ứng dụng sẽ không làm điều này. (Nhân tiện, đây ROWGUIDCOLlà một khái niệm hoàn toàn tách biệt với sao chép. Nó chỉ xảy ra khi sao chép hợp nhất sử dụng nó.)
Cột khóa chính sẽ không còn có thể cập nhật. Nếu ứng dụng đang thực hiện điều này và những thay đổi sẽ không được thực hiện để sử dụng thuật toán khác, không có lựa chọn nào khác ngoài việc thêm một cột mới vào bảng và do đó không cần thảo luận.

Khác với những hành vi đó, ROWGUIDCOLtài sản là hoàn toàn minh bạch. Bạn có thể thêm nó, và ứng dụng sẽ không bao giờ biết. Bất kỳ loại kịch bản sao chép dữ liệu nào cũng phải minh bạch nhất có thể đối với các ứng dụng.

— Jon Seigel
nguồn

Cảm ơn đã trả lời. Không, ứng dụng không hoạt động 1. hoặc 2. Để hoàn thiện, một số bảng đã được trang trí bằng thuộc tính ROWGUIDCOL trong PK.

— spaghettidba

Mặc dù tôi đồng ý rằng việc sao chép phải minh bạch đối với các ứng dụng, tôi cũng tin rằng các cơ sở dữ liệu phải được công bố phải được nghĩ đến để nhân rộng từ đầu. Quản lý danh tính trong sao chép hợp nhất hoàn toàn là PITA, ví dụ: nếu bạn biết ngay từ đầu, bạn sẽ phải hợp nhất xuất bản, đó là một điều cần tránh xa.

— spaghettidba

@spaghettidba: Vâng, tôi hoàn toàn đồng ý rằng nếu sao chép trong thẻ, cơ sở dữ liệu chắc chắn phải được thiết kế cho nó. Thường chỉ cần làm theo các thực hành tốt nhất sẽ có được hầu hết các cách đó; đó là cơ sở dữ liệu kế thừa xấu xí, nhiều lông có xu hướng gặp nhiều vấn đề về thiết kế nhất. Từ kinh nghiệm của tôi, việc nhân rộng hợp nhất nói riêng khó khăn hơn bất kỳ cơ chế sao chép nào khác.

— Jon Seigel

@spaghettidba và Jon: Chỉ cần FYI, việc sử dụng ROWGUIDCOLtrong bối cảnh đó (tức là không phải trong câu lệnh CREATE TABLE/ ALTER TABLE) đã không được chấp nhận vì ít nhất SQL Server 2008 R2 (tìm kiếm FeatureID 182) có lợi cho $ROWGUID.

— Solomon Rutzky

6

Tôi đồng ý. Miễn là không cần giá trị PK để có thể thay đổi, thì tốt hơn là sử dụng cột định danh duy nhất hiện có làm rowguidcol.

— Robert L Davis
nguồn

5

"Về cơ bản, họ nói rằng ứng dụng không bao giờ nên đưa vào miền của nó thứ gì đó chỉ được sử dụng bởi bản sao (chỉ là" công cụ DBA "cho chúng)."

Nhưng nó không chỉ được sử dụng để nhân rộng. Đó cũng là (và đã) PK của bạn.

— Robert Zeurunkl
nguồn