Kayıtların tarihe göre tanımlanabilmesi için veritabanımda kimliklere ihtiyacım var mı?

Android için ilk uygulamamı yazıyorum ve SQLite veritabanını kullanacağım, bu yüzden boyutu olabildiğince sınırlamaya çalışacağım, ancak sorunun genel olarak veritabanı tasarımı için geçerli olduğunu düşünüyorum.

Metin ve oluşturulma tarihi olan kayıtları saklamayı planlıyorum. Uygulama tek başına bir uygulama, yani internet bağlantısı olmayacak ve sadece bir kullanıcı güncelleme olacak, bu nedenle belirli bir tarih ile birden fazla giriş olma şansı yoktur.

Masamın hala bir kimlik sütununa ihtiyacı var mı? Öyleyse, Kimliği Tarih yerine kayıt kimliği olarak kullanmanın avantajları nelerdir?

IMHO, birincil anahtar olarak bir tarih sütunu kullanmaktan kaçınılmalıdır.

Bir tarih alanının birincil anahtar olarak kullanıldığı sistemlerde çalıştım ve tarih alanlarıyla çalışıyorsanız verilerin alt kümelerini geri çekmek için sorgu yazma.

Dikkate almak isteyebileceğiniz diğer bazı noktalar:

Zamandaki bir noktanın benzersiz olduğunu düşünebilirsiniz, ancak bu tarih sütununun ayrıntı düzeyine bağlıdır. O dakika, saniye, milisaniye vb olabilir mi kesinlikle emin birincil anahtar ihlali olsun asla o?

Son olarak, veritabanını başka bir platforma taşımak isterseniz, tarih verilerinin ayrıntı düzeyinin platformlar arasında farklılık gösterdiği sorunlarla tekrar karşılaşabilirsiniz.

Tabii ki ideal ile çalışmak zorunda ne dengelemek zorunda. Alan gerçekten bir endişe kaynağıysa, tarih sütununu kullanmak iki kötülükten daha az olabilir. Bu, vermeniz gereken bir tasarım kararıdır.

Düzenle:

Şunu belirtmeliyim ki bu hiçbir şekilde bunun kötü bir tasarım kararı olduğunu göstermez. Sadece söz konusu RDBMS'nin pratikliği ile ilgili sorunlar olabilir.

Hayır, asla yinelenen bir tarih olmayacağını garanti ederseniz, şemanızda tanımlanmış bir kimlik sütununa kesinlikle ihtiyacınız yoktur.

ANCAK ...

... yine de kullanabilirsiniz. Buradaki küçük sır, SQLite'ın zaten ROWID adı verilen her tablo için benzersiz, otomatik artan bir kimliğe sahip olmasıdır. Tablonuzda otomatik olarak artan bir tamsayı sütunu PK olarak bildirirseniz, SQLite yeni bir sütun oluşturmaz - yalnızca önceden varolan ROWID sütununu diğer adı olarak kullanır.

SQLite'de, her tablonun her satırında 64 bit işaretli tamsayı ROWID bulunur. Her satır için ROWID, aynı tablodaki tüm satırlar arasında benzersizdir.

Bir SQLite tablosunun ROWID değerine ROWID, ROWID veya OID özel sütun adlarından birini kullanarak erişebilirsiniz . Bu özel adlardan birini kullanmak için normal bir tablo sütunu bildirmeniz dışında, bu adın kullanımı, dahili ROWID için değil, bildirilen sütuna başvurulacaktır.

Bir tablo INTEGER PRIMARY KEY türünde bir sütun içeriyorsa, bu sütun ROWID için bir diğer ad olur. Daha sonra dört farklı addan, yukarıda açıklanan orijinal üç addan veya INTEGER PRIMARY KEY sütununa verilen addan birini kullanarak ROWID öğesine erişebilirsiniz. Tüm bu isimler birbirlerinin takma adlarıdır ve her bağlamda eşit derecede iyi çalışırlar.

http://www.sqlite.org/autoinc.html

Bu nedenle, ister istemeseniz de istemeseniz de tablo başına bir tane aldığınız için bir ID sütunu kullanmadan herhangi bir yerden tasarruf etmeyeceksiniz!

Aşağıdakilerden herhangi biri doğruysa bir kimlik alanı kullanın:

1. Doğal anahtar yok (tarih benzersiz olmayacak)
2. Tarih alanı sık sık değişecek
3. Ekleme tarihinde tarih bilinmiyor olabilir.
4. Çok sütunlu bir tanımlayıcı, birleştirmeleri çok ayrıntılı yapan üç sütunu aşıyor.

Bu soruyu okuyun: “Tüm suretler” i destekleyen kanonik bir kaynak var mı?

Düzenle:

Bence, yukarıdakilerin hiçbiri doğru görünmediğinden, alan ve kimlik alanı kullanmanıza gerek yoktur , ancak isterseniz bir tane kullanabilirsiniz.

Ayrıca gelen "tarihi" sütununda değişimi anlam isteyebilirsiniz unutmayın created_atiçin updated_atçok sık karşılaşılan durum olarak görüyorum bu satırlar boyunca başka herhangi bir değişiklik veya.

Bazı durumlarda kimlik sütunu eklemek, tasarımınız değiştiğinde size daha fazla esneklik sağlar.