E-posta adresi birincil anahtar olarak kullanılsın mı?

Otomatik artan sayılarla karşılaştırıldığında e-posta adresi birincil için kötü bir aday mı?

Web uygulamamızın sistemde benzersiz olması için e-posta adresine ihtiyacı vardır. E-posta adresini birincil anahtar olarak kullanmayı düşündüm. Ancak meslektaşım dize karşılaştırmasının tamsayı karşılaştırmasından daha yavaş olacağını öne sürüyor.

Birincil anahtar olarak e-postayı kullanmamak geçerli bir neden midir?

Biz kullanıyoruz PostgreSQL.

Dize karşılaştırması int karşılaştırmasından daha yavaştır. Ancak, bir kullanıcıyı e-posta adresini kullanarak veritabanından almanız önemli değildir. Birden çok birleşime sahip karmaşık sorgularınız olması önemli.

Kullanıcılar hakkında bilgileri birden çok tabloda depolarsanız, kullanıcılar tablosunun yabancı anahtarları e-posta adresi olur. Bu, e-posta adresini birden çok kez sakladığınız anlamına gelir.

Ayrıca, e-postanın benzersiz bir alan oluşturmak için kötü bir seçim olduğunu, bir e-posta adresini paylaşan insanlar ve hatta küçük işletmeler olduğunu da belirteceğim. Telefon numaraları gibi, e-postalar da yeniden kullanılabilir. Jsmith@somecompany.com kolayca bir yıl John Smith ve iki yıl sonra Julia Smith'e ait olabilir.

E-postalarla ilgili bir başka sorun da sık sık değişmeleridir. Anahtar olarak bununla diğer tablolara katılıyorsanız, diğer tabloları da güncellemeniz gerekir; bu da, tüm müşteri şirketi e-postalarını değiştirdiğinde oldukça başarılı bir performans olabilir (gördüğüm.)

birincil anahtar benzersiz ve sabit olmalıdır

e-posta adresleri mevsimler gibi değişir. Arama için ikincil anahtar olarak kullanışlıdır, ancak birincil anahtar için zayıf bir seçimdir.

Bir e-posta adresini birincil anahtar olarak kullanmanın dezavantajları:

1. Birleşim yaparken daha yavaş.

2. Yabancı anahtar kaydedilmiş diğer kayıtların değeri daha büyüktür ve daha fazla disk alanı kaplar. (Bugün disk alanı maliyeti göz önüne alındığında, kaydın şimdi okunması daha uzun sürmesi dışında bu muhtemelen önemsiz bir konudur. Bkz. # 1.)

3. Bir yabancı anahtar olarak kullanan tüm kayıtları güncellenmeye zorlayan bir e-posta adresi değişebilir. E-posta adresi bu kadar sık ​​değişmediği için, performans sorunu büyük olasılıkla küçüktür. Daha büyük sorun, bunu sağladığınızdan emin olmanızdır. Kodu yazmak zorundaysanız, bu daha fazla iştir ve hata olasılığını ortaya çıkarır. Veritabanı motorunuz "güncelleme kademeli" yi destekliyorsa, bu küçük bir sorundur.

E-posta adresini birincil anahtar olarak kullanmanın avantajları:

1. Bazı birleşimleri tamamen ortadan kaldırabilirsiniz. Eğer "ana kayıt" dan ihtiyacınız olan tek şey e-posta adresiyse, o zaman soyut bir tamsayı anahtarıyla almak için bir birleştirme yapmanız gerekir. Anahtar e-posta adresiyse, o zaman zaten buna sahipsiniz ve katılma gereksizdir. Bunun size yardımcı olup olmayacağı, bu durumun ne sıklıkta ortaya çıktığına bağlıdır.

2. Geçici sorgular yaparken, bir insanın hangi ana kayda referansta bulunduğunu görmesi kolaydır. Bu, veri sorunlarını izlemeye çalışırken büyük bir yardımcı olabilir.

3. Neredeyse kesinlikle e-posta adresinde bir dizine ihtiyacınız olacak, bu yüzden birincil anahtar yapmak bir dizini ortadan kaldırır, böylece artık iki yerine güncellenecek tek bir dizine sahip oldukları için eklerin performansını iyileştirir.

Benim düşünceme göre, bu her iki şekilde de bir smaç değil. Pratik bir anahtar mevcut olduğunda doğal anahtarları kullanmayı tercih ediyorum, çünkü çalışmak daha kolay ve dezavantajları çoğu durumda gerçekten önemli değil.

Oldukça kötü. Bazı e-posta sağlayıcılarının işsiz kaldığını varsayın. Kullanıcılar daha sonra e-postalarını değiştirmek isteyeceklerdir. E-postayı birincil anahtar olarak kullandıysanız, kullanıcılar için tüm yabancı anahtarlar bu e-postayı çoğaltır ve değiştirilmesini oldukça zorlaştırır ...

... ve performansla ilgili konulardan bahsetmedim bile.

Bunun kurulumunuzda bir sorun olup olmadığını bilmiyorum, ancak RDBMS'nize bağlı olarak sütunların değerleri büyük / küçük harfe duyarlı olabilir . PostgreSQL belgeleri şunları söylüyor: “Bir sütunu BENZERSİZ veya PRIMARY KEY olarak bildirirseniz, dolaylı olarak oluşturulan dizin büyük / küçük harfe duyarlıdır”. Diğer bir deyişle, birincil anahtar olarak e-posta içeren bir tablodaki arama için kullanıcı girişini kabul ederseniz ve kullanıcı "John@Doe.com" sağlarsa, "john@doe.com" ifadesini bulamazsınız.

Hiç kimse, e-posta adreslerinin özel olarak değerlendirilebileceği olası bir sorundan bahsetmemiş gibi görünüyor. E-posta adresi birincil anahtarsa, büyük olasılıkla bir profil sayfası URL'si benzer görünür ..../Users/my@email.com. Kullanıcının e-posta adresini göstermek istemiyorsanız ne olur? URL'yi yapmak için kullanıcıyı benzersiz bir tamsayı değeriyle tanımlamanın başka bir yolunu bulmanız gerekir ..../Users/1. Sonuçta benzersiz bir tamsayı değeri elde edersiniz.

At mantıksal düzeyde , e-posta doğal anahtarıdır. at fizikselİlişkisel bir veritabanı kullandığınızda düzeyde, birincil anahtar birincil anahtarla iyi uyuşmaz. Bunun nedeni esas olarak başkaları tarafından belirtilen performans sorunlarıdır.

Bu nedenle tasarım uyarlanabilir. Doğal anahtar alternatif anahtar olur (EŞSİZ, BOŞ DEĞİL) ve birincil anahtar olarak sizin durumunuzda otomatik bir artış olabilecek bir yedek / yapay / teknik anahtar kullanırsınız .

systempuntoout sordu,

Birisi e-posta adresini değiştirmek isterse ne olur? Tüm yabancı anahtarları da değiştirecek misin?

Bunun için basamaklı .

Birincil anahtar olarak sayısal bir vekil anahtar kullanmanın başka bir nedeni, dizinlemenin platformunuzda nasıl çalıştığıyla ilgilidir. Örneğin, MySQL'in InnoDB'sinde, bir tablodaki tüm dizinler, kendilerine asılmış birincil anahtara sahiptir, bu nedenle PK'nın mümkün olduğunca küçük olmasını istersiniz (hız ve boyut değerleri için). Bununla ilgili olarak, birincil anahtar sırayla saklandığında InnoDB daha hızlıdır ve bir dize orada yardımcı olmaz.

Bir dizgiyi alternatif bir anahtar olarak kullanırken göz önünde bulundurulması gereken bir başka şey de, gerçek dizenin bir karmasını kullanarak, bazı harflerin büyük ve küçük harfleri gibi şeyleri atlayarak daha hızlı olabilmesidir. (Aslında söylediklerimi doğrulamak için referans ararken buraya indim; hala bakıyorum ...)

Evet, kötü bir birincil anahtar çünkü kullanıcılarınız e-posta adreslerini güncellemek isteyecek.

evet, bunun yerine bir tamsayı kullanmak daha iyidir. e-posta sütununuzu benzersiz kısıtlama olarak da ayarlayabilirsiniz.

bunun gibi:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

Tamsayı birincil anahtarının daha iyi olmasının bir başka nedeni, farklı tablodaki e-posta adresine başvurmanızdır. Adresin kendisi birincil anahtarsa, başka bir tabloda onu anahtar olarak kullanmanız gerekir. Böylece e-posta adreslerini birden çok kez saklarsınız.

Postgres hakkında fazla bilgim yok. Birincil Anahtarlar büyük bir konudur. Bu sitede bazı mükemmel sorular ve cevaplar gördüm (stackoverflow.com).

Sayısal bir birincil anahtara sahip olarak daha iyi bir performansa sahip olabileceğinizi ve e-posta sütununda BENZERSİZ BİR İNDEKS kullanabileceğinizi düşünüyorum. E-postaların uzunlukları değişme eğilimindedir ve birincil anahtar dizini için uygun olmayabilir.

bazıları burada ve burada okuyor .

Şahsen, veritabanı tasarlarken birincil anahtar için herhangi bir bilgi kullanmıyorum, çünkü daha sonra herhangi bir bilgiyi değiştirmeniz gerekebilir. Birincil anahtarı sağlamamın tek nedeni, çoğu SQL işlemini istemci tarafından yapmak kolaylıktır ve bunun için seçimim her zaman otomatik artışlı tamsayı tipi olmuştur.

İş arkadaşınız haklı: Birincil anahtarınız için otomatik artırıcı bir tam sayı kullanın.

E-posta benzersizliğini uygulama düzeyinde uygulayabilir veya e-posta adresi sütununuzu benzersiz olarak işaretleyebilir ve bu sütuna bir dizin ekleyebilirsiniz.

Alanı benzersiz olarak eklemek, birleştirmeleri ve yabancı anahtar kısıtlama denetimlerini gerçekleştirirken değil, yalnızca bu tabloya eklerken dize karşılaştırmasına mal olur.

Tabii ki, veritabanı düzeyinde uygulamanıza herhangi bir kısıtlama eklemenin, uygulamanızın esnek olmamasına neden olabileceğini unutmayın. Herhangi bir alanı "benzersiz" veya "boş değil" yapmadan önce, uygulamanızın benzersiz veya boş olmaması gerektiğinden daima dikkat edin.

Bir birincil anahtar olarak bir GUID kullanın ... bir INSERT yaptığınızda programınızdan oluşturabilirsiniz ve birincil anahtarın ne olduğunu bulmak için sunucudan yanıt almanız gerekmez. Ayrıca tablolar ve veritabanları arasında benzersiz olacak ve bir gün tabloyu keserseniz ve otomatik artış 1'e sıfırlanırsa ne olacağı konusunda endişelenmenize gerek yoktur.

Bu biraz geç bir giriş olduğunu biliyorum ama insanların e-posta hesaplarını terk ve servis sağlayıcıları başka bir kişinin kullanmak için izin adresi kurtarmak eklemek eklemek istiyorum.

@HLGEM'in işaret ettiği gibi "Jsmith@somecompany.com kolayca bir yıl John Smith ve iki yıl sonra Julia Smith'e ait olabilir." bu durumda John Smith hizmetinizi istiyorsa, onun e-posta adresini kullanmayı reddetmeniz veya Julia Smith ile ilgili tüm kayıtlarınızı silmeniz gerekir.

Kayıtları silmeniz gerekiyorsa ve bunlar yerel yasalara bağlı olarak işletmenin finansal geçmişiyle ilgili ise kendinizi sıcak suda bulabilirsiniz.

Bu nedenle, e-posta adresleri, plakalar vb.

Geçerli herhangi bir veri düzenleme mevzuatını dikkate almanız gerekebilir. E-posta kişisel bilgilerdir ve kullanıcılarınız örneğin AB vatandaşıysa, GDPR kapsamında bilgilerini kayıtlarınızdan silmenizi isteyebilir (hangi ülkeye bağlı olduğunuza bakılmaksızın bunun geçerli olduğunu unutmayın).

Referans bütünlüğü veya denetim gibi geçmişe dönük nedenlerden dolayı kaydın kendisini veritabanında tutmanız gerekirse, bir yedek anahtar kullanmak tüm kişisel veri alanını NULL yapmanıza izin verir. Kişisel verileri birincil anahtar ise bu kolay değildir.

tamsayı birincil anahtarını kullanarak performansı artırabilirsiniz.

bir tamsayı birincil anahtarı kullanmalısınız. e-posta sütununun benzersiz olması gerekiyorsa, neden bu sütunda benzersiz bir dizin ayarlamıyorsunuz?

Birincil anahtar olarak int olmayan bir değeriniz varsa, büyük verilerde ekleme ve alma işlemleri çok yavaş olacaktır.

birincil anahtar statik bir öznitelik seçilmelidir. E-posta adresleri statik olmadığından ve birden fazla aday tarafından paylaşılabildiğinden, bu adresleri birincil anahtar olarak kullanmak iyi bir fikir değildir. Ayrıca, e-posta adresleri genellikle [len (email_address)> len (unique_id)] ​​kullanmak istediğimiz benzersiz kimlikten daha büyük olabilecek belirli bir uzunluktaki dizelerdir, bu nedenle daha fazla alan gerektirir ve en kötüsü yabancı anahtar olarak birden çok kez saklanır . Ve sonuç olarak performansın düşmesine yol açacaktır.

Bu tabloya bağlıdır. Tablonuzdaki satırlar e-posta adreslerini temsil ediyorsa, e-posta en iyi kimliktir. Değilse, e-posta iyi bir kimlik değildir.

E-postanın benzersiz olmasını gerektirme meselesi varsa, o sütunla benzersiz bir dizin oluşturabilirsiniz.

E-posta iyi bir benzersiz dizin adayıdır, ancak birincil anahtar için değildir, birincil anahtarsa, örneğin kişinin e-posta adresini değiştiremezsiniz. Sanırım katılma sorgularınız da daha yavaş olacak.

e-posta adresini birincil anahtar olarak kullanmayın, e-postayı benzersiz tutun, ancak birincil anahtar olarak kullanmayın, kullanıcı kimliğini veya kullanıcı adını birincil anahtar olarak kullanmayın