Tekil Tablo Adı

Yeni bir veritabanı oluştururken Tablolarımı nasıl adlandırmalıyım?

Tekil: Clientya Çoğul: Clients?

Sana bağlı. Sadece olsa tutarlı ol.

Şahsen ben, her bir "sıranın" depoladıklarına göre tekil tercih ederim: Sipariş, Ürün, Kullanıcı, Ürün, vb.

Bu, tekil varlıkları / türleri kullandığım modellememle (Nesne Rolü Modellemesiyle) eşleşiyor.

Düzenle:

Bunun bir nedeni link tabloları olduğunda çoğul başarısız olmasıdır:
Orders, Productsverecekti OrderProductsya OrdersProducts. Hiçbir ses doğru değil

Veya tarih tabloları (elbette bunun için şemaları kullanabilirsiniz):
Orders-> OrdersHistoryveya (hayır!) OrdersHistories? Olmaz Order> - OrderHistorydaha iyi?

Tekil ve çoğul tablo adlarıyla ilgili olarak, konu tartışmalı görünmektedir, ancak olmamalıdır.

Bir tablo birden fazla kaydın koleksiyonudur, bir tablo içerdiği bir kayıt türünün tanımından sonra adlandırılır. Bir tablonun içerdiği kayıt türünden farklı bir ada sahip olmasına izin verilirse, tabloya çoğul bir ad verebilirsiniz, böylece örneğin birden fazla Çalışan kaydı içeren bir Çalışan tablosu olabilir. Ancak, SQL tasarımcısı tablolar ve kayıt türleri için ayrı adlar sağlamadı.

Bir kayıt türünün adı (ve tablonun uzantısına göre) tekil olarak tutulursa, bir kaydı tanımlamak için kullanacağınız sınıfın adıyla aynı olacağı için, verileri kullanan nesne yönelimli programlar için işler daha mantıklı bir şekilde çalışır .

Daha sonra programdaki bir koleksiyonu tanımlamak istiyorsanız, çoğul veya daha iyisini, EmployeeList veya EmployeeArray gibi uygun bir değiştirici kullanabilirsiniz.

Otomatik kod üretimi için düzensiz çoğullar ve programda çoğulların oluşumu hakkında farklı dil geçmişleri veya fikirleri olan programcılar ile ilgili bir sorun var.

İngilizce dili iyi ve düzgün bir programlama dili değildir ve veritabanı ve program ifadelerinin İngilizceye uymasını sağlamaya çalışmak çünkü bu ifadelerden birini okumak daha iyi bir hatadır.

@ Gbn'in cevabı gibi bence bu en çok tercih meselesidir ve onun gibi ben de sizin yaptığınız herhangi bir seçimin her yere uygulanmasını tavsiye ederim (en azından DB'de ). Tutarlılık buna değer.

Ancak benim tercihim, SELECTifadelerde çoğul seslerin daha iyi olması :

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

Yani bu durumda, en azından, masada birkaç kişi var ve bunların bir kısmı müşteriye iade ediliyor.

"sipariş" ayrılmış bir kelimedir. "emir" değil

"kullanıcı" ayrılmış bir kelimedir. "kullanıcılar" değil

"session" ayrılmış bir kelimedir. "oturumlar" değil

"sonuç" ayrılmış bir kelimedir. "sonuç" değil

"göreceli", ayrılmış bir kelimedir. "akrabalar" değil

...

Bunlar iş alanı veritabanına girebilecek ortak kelimeler gibi görünüyor. Çoğul kelimeler tekil kelimelerden daha az anahtar kelimeler olarak görülüyor. Bu nedenle, SQL anahtar kelimelerle çakışmamak için birden fazla tablo adı kullanmak faydalı olabilir.

SQL tablosunun çoğul isimleri olması gerektiğine inanıyorum. Sadece çok daha iyi okur.

Bir kitap kayıtları tablosu kitap olarak adlandırılmalıdır. ORM aynı sözleşmeyi kullanmalıdır. Books nesnesi bir koleksiyondur ve ayrıca Books Table'daki tüm kayıtların üzerindedir. Tek bir kaydın yerine bir Book nesnesi.

Bu kodlamayı daha doğal hale getirir.

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

Birkaç yıl programlama ile çalıştıktan sonra çoğulculuğun gereksiz bir komplikasyon olduğu sonucuna vardım. Bence, KISS felsefesine göre, bir programcının zaman ve verimlilik nedeniyle tüm sorunlara en tembel ve kolay çözüm için çaba göstermesi gerektiğidir. Böylece tekil, tüm senaryolarda ihtiyaç duyulan daha az çalışmayı sağlar.

Bu çok kişisel bir şey. 30 yıldır tekil form kullanıyorum. Fakat insanların neden çoğulları sevdiğini anlayabiliyorum. Kitaplar - yazarlar kitapçıların yanlış olmadığını düşünüyorum. Bir kitapta bir veya daha fazla yazar olabilir. Ve yazarlar bir veya daha fazla kitap yazmış olabilir (örneğin birlikte yazılmış). Aynı zamanda birden fazla yazarın yazdığı kitapları nasıl idare ettiğinize de bağlı. Diğer cevaplara katılıyorum; birini seç ve tutarlı ol. Rezerve edilmiş kelimeler ile ilgili konular. Geçici çözüm adları bulmanın zor olmadığını düşünüyorum. kullanıcı -> app_user, oturum -> app_session, sipariş -> customer_order

Olayları farklı açılardan görüyoruz ve bence iki kamp şu şekilde tanımlanmaktadır:

Tekil ("kullanıcı")
Tablo adı ile birden fazla satır içerebilen bir kabı temsil ettiği arasında bir ilişki kuran kişi.

Bu yüzden "kullanıcı kabı" birden fazla satır içerebilir.

Çoğul ("users")
Tablo adı ile bu gerçeği arasındaki ilişkiyi yapmayan kişi bir kabı temsil eder. Elbette bir konteyner olduğunu biliyorlar, ama isimde yok.

Örneğin,
bir "yumurta kartonu" içinde birden fazla yumurta olabilir, ancak kap referansının adında olduğu açıktır, bu da birden fazla yumurta için potansiyel sağlar. Bununla birlikte, tekil tablo ismi "user" ile, konteyner referansı isimde yoktur. örneğin, "user_container", çoğul isimleri tercih eden insanlar için büyük olasılıkla kabul edilebilir olacaktır.

Bunun, yıllarca çoğul ortak uygulamalardan ve çoğu çevrimiçi öğretim materyalinden kaynaklandığını düşünüyorum.

Bütün bunlar, teknik olarak tek bir kabı adlandırdığımızdan dolayı tekil konuşmanın daha doğru olduğunu ve kabın birden fazla (veya tek) satır içerebileceğini düşünüyorum.
Adlandırılmış adı verilen kabı içeriğe zihinsel olarak bağlamaktan ziyade, tablonun adını içeriğe (birden çok satır birden fazla ada ihtiyaç duyar) zihinsel olarak bağladıklarında insanlar için yanlış görünüyor (bir kap çoğul için izin verir).

Her zaman olduğu gibi, çoğu zaman doğru ya da yanlış değildir ve bu, senaryoya neyin uygun olduğu ve daha önemlisi ne seçtiğinizle tutarlı olmakla ilgilidir.

Eğer projeyi yalnızca yapıyorsanız ve herhangi bir yöne gitmek için gerçek bir neden yoksa en iyi olduğunu düşündüğünüz şeyi yapın ya da sadece tercih edin. Aynısını dev bir ekipte uygulayın ve sadece oybirliği ile karar verin.