Son derece kısaltılmış tablo adlarını kullanmak için bir neden var mı?

Veritabanı tablo adlarını okumak için çok zor olan ve nerede depolandığına dair hiçbir belge bulunmayan bir satıcının uygulamasından bir veritabanı kurulumu kullanıyoruz. Özel bir uygulamada neden masa yapılarını gizlemek istediğini anlayabiliyorum, ancak bu uygulamanın satış noktalarından biri (Kurumsal Kaynak Planlaması) özelleştirilebilirdi.

Tablo isimleri aptrx (Satıcılar Muhasebesi İşlemleri) ve apmaster_all gibidir (meraklı bir şekilde, satıcılar tablosu budur). Bu oldukça karmaşık bir veri tabanıdır, bu yüzden sözleşmede herhangi bir mantık olup olmadığını ya da sadece kasıtlı olarak mı yoksa başka şekilde mi karıştırıldığını merak ediyordum.

Bildiğim kadarıyla, tablonun adının uzunluğu dikkat çekici bir şekilde performansı etkilemeyecek, değil mi? Veritabanı çok karmaşık (yüzlerce tablo) bu yüzden sıralama anlamlı, ancak neden AccountsPayableTransactions'ın aptrx tercih edildiğini bilmiyorum.

Oracle, 30 karakterlik masa isimlerinde uzun süredir devam eden bir sınırlama getirdi. Bunun 16 bitlik orijinal bir ortama dayanan eski bir mesele olduğunu düşünüyorum.
Bir tablo adının uzunluğu, tüm adların bir veri sözlüğünde saklanması ve sorgular için ayrıştırılması gerektiğinden performans üzerinde bir miktar minus etkisi olabilir, ancak isabeti ölçebileceğinizi düşünmüyorum.

Kısa tablo adlarının daha önemli bir etkisi de çalışmanın zor olmasıdır. Benim de kısa isimlerle kurumsal veritabanı şemasını sürdürmem gerekiyor. Kısa tablo isimlerinin olması için iyi bir sebep yoktur. Bakım kolaylığı her zaman şaşırtmaya ya da eski DOS alışkanlıklarına neden olmaz.

Söylenmesi ya da detaylandırılması gereken iki şey olduğunu hissediyorum:

1. Bir şeyleri adlandırmak , göründüğü kadar önemsiz değildir

   Bilgisayar Bilimi'nde sadece iki zor problem var: önbellek geçersiz hale getirme ve adlandırma Phil Karlton

2. Kısa anlamsız isimler her zaman kötü olsa da, uzun isimler her zaman iyi değildir - beyinlerimizin şaşırtıcı bir şekilde düşük olan içsel bir dr eşiği vardır. 30 karakter genellikle yeterlidir ancak olmasa da istisnai durumlar için daha fazla izin vermek için RDBMS'yi tercih ederim (ve tıpkı dilde olduğu gibi, daha uzun isimler, çok sık konuşmadığımız şeyler için daha faydalıdır - kısıtlama isimleri ve daha kısa isimler her zaman sorguladığımız tablolar için daha kullanışlıdır)

Her zaman isimleri seçmek için çok az zaman harcamak isterim ve bunu yaparsam pişman olurum - isimleri değiştirmek sadece nadiren olur

Tembellik. IntelliSense ve 3. parti seçenekleri yazarken haklı çıkarmak için gerçekten zor bir bahane. İsimlerin anlamlı ve okunabilir kelimelere sahip olmasını tercih ederim.

Tablo isimleri aptrx (Satıcılar Muhasebesi İşlemleri) ve apmaster_all gibidir (meraklı bir şekilde, satıcılar tablosu budur). Bu oldukça karmaşık bir veri tabanıdır, bu yüzden sözleşmede herhangi bir mantık olup olmadığını ya da sadece kasıtlı olarak mı yoksa başka şekilde mi karıştırıldığını merak ediyordum.

İyi bilinen kısaltmalar, genellikle sözcükleri hecelemede tercih edilir. Bir kısaltma bazı insanlar tarafından iyi bilinir, ancak yeterince insan olmazsa, onu kısaltma olarak adlandırırız ve kod olarak adlandırmaya başlarız.

Kısaltmalar, sınırlı limitleri olan platformlarda alanı korur, ancak bu 30 yıl öncekinden daha az önemlidir. (1980'lerde sizi bir tablo adı için 6 ya da 8 karakterle sınırlayan bir sistem üzerinde çalıştığımı hatırlıyorum.)

Kısaltmalar, kısaltmanın iyi yapılması koşuluyla genellikle tablo adlarını ve sütun adlarını okumayı kolaylaştırır. Bütün gün AP kodunda çalışmış olsaydım, "ap_trx.inv_num" gibi sütun adlarını "account_payable_transactions.invoice_number" yerine okumak yerine tercih ederim. (Alt çizgi seviyorum.) Uzun isimler yazmak iyi bir metin editörüyle ilgili bir sorun değil.

Muhasebe sistemlerinde, hem "ap" hem de "trx" iyi bilinen kısaltmalardır. Diğerleri, alacak, genel muhasebe defteri ve genel dergi hesapları için "ar", "gl" ve "gj" değerlerini içerir.

İyi tasarlanmış bir sistemde, "aptrx" adlı bir tabloda ödenecek işlemler bulursam, artrx’de alacak hesapları, gltrx’de genel muhasebe işlemleri ve benzerlerini bulmayı umuyorum. Ben "apmaster_all" 'ı biraz kafa karıştırıcı buluyorum, fakat "armaster_all"' ı da bulursam, ilk önce tüm satıcıları (aktif veya inaktif satıcıların aksine) elinde tuttuğunu ve ikincisinin de benzer şekilde tüm müşterileri elinde tuttuğunu varsayardım.

Diğer sorun alanlarında, diğer iyi bilinen kısaltmaları bulabilirsiniz. Adreslemede, adres için "adres", sokak için "st", ABD Posta Hizmeti için "usps", Birleşik Parsel Hizmeti için "ups", ilçe için "cty", Bölge İyileştirme için "zip" gibi kısaltmalar bulacaksınız. Kod vb.

Bu şaşırtmaca demezdim. Borç hesapları, "cdrs21" adlı bir tabloda saklanmış olsaydı, bu şaşırtmaca derdim . (Bir keresinde, tüm ana bilgisayar birleştirici modüllerini bu şekilde adlandıran bir şirket için çalışmış olmama rağmen. Karakter sınırları, şaşırtma değil.)

Ancak yararlı veritabanları büyür ve veritabanları büyüdüğünde bir sorunla karşılaşırsınız. Veritabanınıza sorun alanları ekledikçe, iyi bilinen kısaltmaların çarpıştığı durumlarla karşılaşırsınız. Medya ile ilgilenirseniz, "ap" "Associated Press", "alternatif pres" veya "önceden yerleştirme" yi de kısaltabilir. Bu olduğunda, kısaltmalardan vazgeçme veya kodlara geçme zamanı. Kuruluş ne kadar büyükse (ve veritabanı ne kadar büyükse) kodları o kadar sık ​​bulurum.

Sadece "Tanrım, gözlükleri bu korkunç adlandırma kongresi için hiçbir şey yapmıyorlar" hikayesi ile şaka yapıyorum. Son ortamımdaki veri yönetimi ekibi, tablo ve sütunlar için 18 karakterden oluşan kısaltılmış tablo adlarını kullanmanın nedeninin DB2 sınırlaması olduğunu (z / os ve SQL Server'da DB2 bulunduğunu) belirtti. Derhal bunun IBM sitesinden gelen belgelerle yanlış olduğunu belirttim. Daha sonra, MF jokeyleri tarafından onaylanan veri tabanı ile konuşması gerektiğinden, bir COBOL sorunu olduğunu (evet, aktif olarak COBOL geliştirildiğini) belirttiler. Sonunda onların yanıtı bizim yayıncılık standartımızdı.

Standartlar komitesine uzunluğu 18'den 32 karaktere çıkarmak için dilekçe verdik ve 30 karakter sınırlaması aldık. Bu, 'SR_M_DLY_ADV_PRD_S' için işe yaramaz isimlerden 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML'ye giden tablolarla sonuçlandı.

Bu yüzden, onlarca yıllık deneyimimde, kısaltılmış tablo isimleri somut bir fayda sağlamaz ve çöpleri ekranda anlamlı bir tanımlayıcıya çevirmek için her zaman veri sözlüklerine başvurmam gerektiği için geliştirme ve bakım masrafları artar. Çalıştığım ve çoğunlukla hafızadan yeniden oluşturabildiğim mantıksal olarak adlandırılmış varlıklar ile karşılaştırılabilir çünkü sezgisel olarak adlandırıldılar.

Bu bir alışkanlıktır (Kevinsky ile aynı fikirdeyim). Bazı eski (belki de var olan) sorunlara, işletim sisteminin (DOS, Windows, örneğin) işletim sistemi kısıtlaması (isim uzunluğu, karmaşık isimlerin sözcükleri arasındaki boşluk, çok dilli vb.) Ve bu isimleri kullanmayan bazı yazılımlara tepkisi oldu. Deneyimli insanlar şöyle dedi: "Bunu yapın (kısa kullanın ve altı çizili isimlerle ayrılmış) ve hepsi tamam olur."

Posterlerin yukarıda belirtilen nedenlerle tanımlayıcı isimlerini kullanmayı seviyorum.

Ancak başka bir faydası var. Örneğin, açıklayıcı adlandırmada, yuvalanmış adları kullanmanızı sağlar. Çalışan adında bir masanız olduğunu söyleyin. Başka bir tabloyla ilişkiniz varsa, ÇalışanAdresi olarak adlandırılabilir. Veya ÇalışanAktar. Kriptik ile, kısaltılmış adlandırma, bu neredeyse imkansızdır.

Her sütunun altındaki tanımların ne kadar karmaşık olduğuna bağlı olarak değişir. İnsanların bu tür çok açıklayıcı sütun adları gördüklerinde meta veri yönetimi ile tembel olduklarını ve hatta aslında eksik açıklamaların olduğunu düşünüyorum. Neden bir şeyi kısaltdığını sorabilirsin.