PK ROWGUIDCOL olarak mı yoksa ayrı bir satır kılavuzu sütunu mu kullanıyorsunuz?

9

Burada uzun soluklu bir tartışma var, bu yüzden başka görüşler duymak istiyorum.

Uniqueidentifier kümelenmiş PK ile birçok tablo var. Bunun iyi bir fikir olup olmadığı kapsam dışındadır (ve yakında değişmeyecektir).

Şimdi, veritabanının birleştirilmesi gerekiyor ve DEV'ler, mevcut PK'yi ROWGUIDCOL olarak işaretlemek yerine ayrı bir satır kılavuzu sütununun kullanımını savunuyor.

Temel olarak, uygulamanın asla etki alanına yalnızca çoğaltma tarafından kullanılan bir şey getirmemesi gerektiğini söylüyorlar (bu yalnızca onlar için "DBA şeyleridir").

Performans açısından bakıldığında, mevcut bir sütunla yapabileceğim bir şey yapmak için yeni bir sütun eklemem için hiçbir neden göremiyorum. Dahası, sadece "DBA şeyler" olduğundan, neden DBA'nın seçmesine izin vermiyorsunuz?

DEV'lerin amacını anlıyorum, ama yine de katılmıyorum.

Düşünceler?

EDIT: Ben sadece bu tartışmada azınlık olduğumu ve konumumu sorgulayan DEVs saygı ve güvendiğim insanlar olduğunu eklemek istiyorum. Bu yüzden fikir istemeye başvurdum.
Ayrıca bir şeyleri kaçırıyor olabilirim ve onların amacını yanlış anlayabilirdim.

sql-server database-design merge-replication

— spaghettidba
kaynak

Gelecekte bir PK değerinin değişmesi gerekebilir mi?

— Robert L Davis

Hayır gerçek değil. Bu bir yedek anahtardır, bu nedenle uygulama bu sütunla gerçekten fazla bir şey yapmaz. Asla değişmez ve kullanıcılara asla gösterilmez.

— spaghettidba

Neden ayrı bir rowguidcol istiyorlar? Genel olarak PK için hangi planı seçerlerdi ve neden?

— JustinC

@spaghettidba Geçiş alanlarından bahsetmişken, uygulama kodlarında hangi tasarım modellerini kullanmaları veya kullanmamaları gerektiğini ne sıklıkla söylersiniz? Belki de "alanlarına" yapışmalılar? ;-). Ayrıca, tüm tablolara 16 baytlık bir sütun eklemek performans açısından korkunç olur ve fayda sağlamaz.

— Solomon Rutzky

7

Temel olarak, uygulamanın asla etki alanına yalnızca çoğaltma tarafından kullanılan bir şey getirmemesi gerektiğini söylüyorlar (bu yalnızca onlar için "DBA şeyleridir").

Tamamen katılıyorum. Ama ... birincil anahtar değil , sadece (tahminen uygulama olarak kullanır çoğaltması için kullanılan bazı yol). Argüman bu bağlamda bir anlam ifade etmiyor.

Her halükarda, bildiğim kadarıyla, bu "DBA şeylerinin" etki alanı sınırını geçmesinin sadece 2 yolu vardır:

Uygulama, ROWGUIDCOLsütuna aşağıdaki gibi başvuran sorgular kullanıyorsa :
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;
```
Sütunlarınızın henüz bu özelliğe sahip olmadığını varsayıyorum, bu yüzden uygulama bunu yapmazdı. (Bu arada, ROWGUIDCOLçoğaltmadan tamamen ayrı bir kavramdır. Birleşme çoğaltması bunu kullanır.)
Birincil anahtar sütunu artık güncellenemez. Uygulama bunu yapıyorsa ve başka bir algoritma kullanmak için değişiklik yapılmayacaksa , tabloya yeni bir sütun eklemekten başka seçenek yoktur ve bu nedenle tartışma gerekmez.

Bu davranışlar dışında, ROWGUIDCOLözellik tamamen şeffaftır. Ekleyebilir ve uygulama asla bilemez. Her tür veri çoğaltma senaryosu, uygulamalar için mümkün olduğunca şeffaf olmalıdır.

— Jon Seigel
kaynak

Cevabın için teşekkür ederim. Hayır, uygulama 1. veya 2. yapmıyor. Tamlık olması açısından, bazı tablolar PK'daki ROWGUIDCOL özelliğiyle zaten dekore edilmiştir.

— spaghettidba

Çoğaltmanın uygulamalar için şeffaf olması gerektiğini kabul etsem de, yayınlanması gereken veritabanlarının sıfırdan çoğaltma için düşünülmesi gerektiğine inanıyorum. Örneğin, birleştirme çoğaltmasında kimlik yönetimi tamamen PITA'dır: en başından beri yayınlamayı birleştirmeniz gerekiyorsa, bu uzak durmanız gereken bir şeydir.

— spaghettidba

@spaghettidba: Evet, çoğaltma kartlarda bulunuyorsa, veritabanının kesinlikle bunun için tasarlanması gerektiğine tamamen katılıyorum. Genellikle sadece en iyi uygulamaları takip etmek o yolun çoğunu alacaktır; en fazla tasarım problemine sahip olan çirkin, kıllı eski veritabanları. Deneyimlerime göre, özellikle birleştirme çoğaltması diğer çoğaltma mekanizmalarından daha zorlayıcıdır.

— Jon Seigel

@spaghettidba ve Jon: Sadece FYI, ROWGUIDCOLbu bağlamda (yani CREATE TABLE/ ALTER TABLEdeyiminde değil) kullanımı en azından SQL Server 2008 R2'den (FeatureID 182 için arama) yana kullanımdan kaldırılmıştır $ROWGUID.

— Solomon Rutzky

6

Katılıyorum. PK değerinin değişebilmesine gerek olmadığı sürece, mevcut benzersiz tanımlayıcı sütununu rowguidcol olarak kullanmak daha iyi olacaktır.

— Robert L Davis
kaynak

5

"Temel olarak, uygulamanın etki alanına asla yalnızca çoğaltma tarafından kullanılan bir şey getirmemesi gerektiğini söylüyorlar (bu yalnızca onlar için" DBA şeyleridir ")."

Ancak yalnızca çoğaltma için kullanılmaz. Aynı zamanda (ve zaten) PK'nız.

— Robert Zeurunkl
kaynak