Resmi PostgreSQL Kapitalizasyon sözleşmeleri [kapalı]


14

DB, Tablo ve alan adlarında büyük harf kullanımı ile ilgili resmi bir PostreSQL sözleşmesi var mı?

Resmi sitesinde örnekler bir küçük harf ve önermek _kelime ayrılmasını ve bu politika resmî olup olmadığını merak ediyorum.

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);

Yanıtlar:


21

Temel olarak Verace'nin yorumlarını yansıtacağım ve bunu yarı resmi hale getireceğim:

Her durumu kapsayacak en iyi uygulama yoktur . Aşağıdakiler, aşağıdaki varsayımları yapar (ve bunu yapmadıysanız ne yapmalısınız):

  • Bunu zaten ekibinizle tartıştınız (kendi başlarına çalışan insanlar genellikle sadece karar vermeliler)
  • Zaten ekibinizde SQL için resmi bir stil tanımı yoktur (Aksi halde bize sormazsınız)
  • Herhangi bir kod için resmileştirilmiş stil tanımı yoktur (Diğer diller için önceden belirlenmiş olan aynı temel kuralları izleyin ve bir stili resmileştirin)

Bu yüzden geri kalanı biraz düşünülmüş ama deneyime dayanıyor

  1. Tablo isimleri söz konusu olduğunda
    1. Tekil varlık adları için gitmelisiniz (bu, dokümantasyonu kolaylaştırır)
    2. Pascal Kasasını burada kullanmalısınız
  2. Alan isimleri söz konusu olduğunda
    1. Alan adlarınızda camelCase kullanın
    2. Tanım kesinlikle çoğul olarak anlamlı olmadığı sürece kısa tekil isimler kullanın (neredeyse hiç yapmaz)
  3. Kendi işleviniz veya saklı yordam adlarınız söz konusu olduğunda
    1. Underscore_separation kullanın
    2. Parametreleme için alan adlandırma kullanın
  4. Yerleşik veritabanı işlevleri veya dil adları söz konusu olduğunda (örn. SELECT)
    1. Belli bir şekilde büyük harf kullanımı gerekmiyorsa, TÜM CAPS'ı kullanın
    2. Neyin makul veya gerekli olduğunu öğrenmek için dilinizin API'larını öğrenin
  5. Boşluk söz konusu olduğunda
    1. Birçok kişi anahtar kelimeler için sütun hizalaması ve anahtar kelime olmayan şeyler için girinti kullanır
    2. Alanlar her satıra ayrıldığında birçok kişi satırın başında virgül kullanır (Bu, seçim listesinden belirli bir alanı yorumlamayı kolaylaştırır)
    3. Boşlukları hiçbir zaman adların bir parçası olarak kullanmayın; dönüş değeri başlıkları için bile.
  6. Noktalama söz konusu olduğunda
    1. Parantezler - KULLANIN. ÜCRETSİZ. Söz veriyorum.
    2. Noktalı virgüller - KULLANIN. Seni kırmayacaklar. Kodunuzu düşünmeye zorlarlar. Ve onlar iyi hijyen.
    3. Satır Başı - Bir kez daha ücretsiz ;-) Ve kodunuzu okunabilir hale getirin.

Ayrıca, genel bir stil kılavuzu uygulamanıza yardımcı olmaya çalışırken, Postgres topluluğunun genellikle camelCase veya PascalCase kullanmadığını, bunun yerine underscore_separation kullandığını da bilmelisiniz. Asıl önemli olan, tutarlı olmak için her yerde belirli bir stil oluşturmanızı ve kullanmanızı sağlamaktır .


3
+1 için "Gerçekten önemli olan, tutarlı olmak için her yerde belirli bir stil oluşturmanızı ve kullanmanızı sağlamaktır." Tutarlılık anahtardır. Onsuz, asla düşünmemeniz gereken şeyleri düşünmelisiniz.
Max Vernon

4
PostgreSQL'deki camelCase ve PascalCase biraz acı veriyor. Eğer gerçekten böyle isimlere sahip olmak istiyorsanız bunları alıntılamak zorundasınız, aksi takdirde sistem onları sessizce küçük harflerle yazacaktır (uyandırdığı dernekler ne olursa olsun neredeyse başını kesmek.
dezso

Veritabanı adları ne olacak? Ben kullanmalı mıyım database_name, database-name, DatabaseName, databaseName, vb?
ma11hew28

1
Bu cevap aslında PostgreSQL için mi? PG'ye özgü bir cevapta tablo adları için PascalCase kullanma önerisi verirseniz, (a) çoğu örnekte küçük harfli anahtar kelimeler kullanması ve (b) tablo adlarını alıntılamak veya PG onları küçük harfe katlayın.
AndreKR

@AndreKR işte: Yazılım geliştiricilerinin yetişkin olmasını, belgelerin nasıl okunacağını bilmelerini ve takımlarıyla kodun nasıl tutarlı bir şekilde yazılacağını tartışmasını bekliyorum. Bu cevap topluluk wiki'sidir, yani herkes bunu düzenleyebilir ve geliştirebilir. Tam olarak "bu tek yoldur" diyemiyorum ve sadece bazı insanların küçük harflerle örnek vermesi, hayattaki tek yoldur demek değildir. Bu cevabın ruhu olan kendi yolunu bulmalısın. Geliştirmek için lütfen bu topluluk yanıtını düzenlemekten çekinmeyin. Teşekkürler!
jcolebrand

4

Hızlı bir Google, en iyi uygulamaları gösteren birçok siteyi ortaya çıkaracaktır. Ben sadece iki şey söyleyebilirim - EVER boşluk kullanmayın "Tablo Adı" (farklı kaçış mekanizmaları nedeniyle taşıma imkansız hale gelir; aynı alfanümerik olmayan karakter için de geçerlidir). Bu tür mekanizmalarla, normalde davaya da saygı göstermelisiniz. İngilizce (veya kendi dil) dilinde yeterince harf ve kelime var ve tanımlayıcı uzunlukları yeterince uzun (tanımlayıcı_uzunluğu <32 olan herhangi bir sistem bilmiyorum, PostgreSQL 64'tür). Ve asla aynı şeyi yapacak SQL anahtar kelimeleri (RDBMS'ye göre değişir) kullanmayın.

Gibi ifadeler

SELECT "Field" FROM "Table";

geçerli olabilir! Kesinlikle kritik olan şey, açık ve nispeten basit bir sözleşmeye sahip olmak ve daha sonra ona bağlı kalmaktır. Sizin de öğreneceğiniz gibi, insanların farklı görüşleri vardır - konuyu okuyun ve size “doğru olanı” seçin. Bu sitelere bakınız 1 , 2 , 3 , 4 , 5 , ... (daha fazlası var).


Teşekkürler, kendi aramalarımda çok fazla tökezledim. Resmi bir stil rehberi olup olmadığını bilmek istedim.
Adam Matan

(Singular_table_name / plural_table_name) tartışmasının her iki tarafında da diğer alanlardaki görüşlerine saygı duyduğum birçok uygulayıcı var. Ben "bekar" bir adamım - eğer bir nükleer santral işletiyorsanız, herhangi bir kayıt görmek istemeyeceğiniz catastrophic_meltdown adlı bir masanız olabilir! Birincil anahtarlarınıza _id soneki verin ve alt tablolarda Parent_Table_Name_FK olarak adlandırın - yaptığım bu. Bundan sonra, kolay-bezelye! Caps / no-caps'e gelince, SQL betiklerimde deve-case (tırnaksız) var, ifadelerim olabilir veya olmayabilir.
Vérace
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.