SQL server işleyişinde önerilen, clustered index'in olabiliyorsa unique olmasıdır. Peki eğer biz unique olmayan bir clustered index tanımlamayı seçersek neler olur. Bu durumda SQL tabloya yeni bir kolon daha ekler, bu kolona uniquifier denir ve 4 byte yer kaplar. Bu kolon tablodaki her satırda vardır ve clustered index'in aynı olabildiği durumlar için belirleyici görevi görür. Satırın belirleyici olmasında rol aldığı için, diğer non-clustered indexlerde de bu kolon vardır. Bu sebeplerden non-unique clustered index kullanımlarında ek bir disk alanı kullanımı olacağı unutulmamalıdır. Bu ek kolonun performansa da az da olsa etkisi olacaktır.
Non-Unique Clustered Index'leri belirli durumlarda kullanmanız gerekebilir, örneğin veritabanına bakım yapmama konusunda inatçı bir müşteri ile çalışıyorsanız :)
Tablolar için fragmantation çok önemlidir, ve önerilen durum clustered index'in artan değerler alması ve dolayısıyla yeni kaydın her zaman tablonun en alt kısmında yer almasıdır. Genellikle sorun yaşanan veritabanları eski ve bir çok yeni geliştirme geçirmiş, ilk tasarlanırken akla gelmeyen bir çok işi de yapar hale gelmiş veritabanlarıdır. Bu tür durumlarda performans çalışmalarında tablolarda kritik değişiklikler yapmak sistemin işleyişini tümden etkileyebilir. Örneğin, tüm sistemde unique'lik bir GUID ile sağlanıyorsa ve bu GUID sizin işlem tablolarınızda bir clustered index ise, aynı zamanda önceki örnekteki gibi bakım yapmayan bir müşteri ile karşı karşıyasanız, kısaca durum şudur: tabloda artık düzgün çalışan bir clustered index kalmamış demektir.
Bu tür durumlarda, GUID'i clustered index olmaktan çıkartarak unique index olarak eklemek uygun olabilir, clustered index olarak bir artan ID veya işlem zamanı kullanılabilir. Ancak farklı kayıtlar için, işlem zamanı -zor da olsa- sistemde aynı olabilir, aynı olmasa bile SQL aynı olabilme ihtimaline karşı yukarıdaki uniquifier kolonunu tabloya eklemek zorunda kalacaktır.
Sonuç olarak her neredeyse tabloda bir clustered index olmalıdır ancak clustered index her zaman unique olmalıdır diye bir gereklilik yok, imkan varsa unique olması sisteme büyük performans sağlayacaktır. Bu bilgileri düşünerek non-unique clustered index kullanılabilir, veya kullanılmayabilir :)
Non-Unique Clustered Index'leri belirli durumlarda kullanmanız gerekebilir, örneğin veritabanına bakım yapmama konusunda inatçı bir müşteri ile çalışıyorsanız :)
Tablolar için fragmantation çok önemlidir, ve önerilen durum clustered index'in artan değerler alması ve dolayısıyla yeni kaydın her zaman tablonun en alt kısmında yer almasıdır. Genellikle sorun yaşanan veritabanları eski ve bir çok yeni geliştirme geçirmiş, ilk tasarlanırken akla gelmeyen bir çok işi de yapar hale gelmiş veritabanlarıdır. Bu tür durumlarda performans çalışmalarında tablolarda kritik değişiklikler yapmak sistemin işleyişini tümden etkileyebilir. Örneğin, tüm sistemde unique'lik bir GUID ile sağlanıyorsa ve bu GUID sizin işlem tablolarınızda bir clustered index ise, aynı zamanda önceki örnekteki gibi bakım yapmayan bir müşteri ile karşı karşıyasanız, kısaca durum şudur: tabloda artık düzgün çalışan bir clustered index kalmamış demektir.
Bu tür durumlarda, GUID'i clustered index olmaktan çıkartarak unique index olarak eklemek uygun olabilir, clustered index olarak bir artan ID veya işlem zamanı kullanılabilir. Ancak farklı kayıtlar için, işlem zamanı -zor da olsa- sistemde aynı olabilir, aynı olmasa bile SQL aynı olabilme ihtimaline karşı yukarıdaki uniquifier kolonunu tabloya eklemek zorunda kalacaktır.
Sonuç olarak her neredeyse tabloda bir clustered index olmalıdır ancak clustered index her zaman unique olmalıdır diye bir gereklilik yok, imkan varsa unique olması sisteme büyük performans sağlayacaktır. Bu bilgileri düşünerek non-unique clustered index kullanılabilir, veya kullanılmayabilir :)
Hiç yorum yok:
Yorum Gönder