Sütun ve Alan: bu terimleri yanlış mı kullanıyorum?

Burada biraz utanıyorum, her zaman "sütun" ve "alan" terimlerini tamamen birbirinin yerine kullandım, bu da son zamanlarda teknik bir tartışmada karışıklığa neden oldu.

Bununla birlikte, bunun doğru olmadığı söylendi (her terimi elektronik tablo terminolojisine çevirerek, veri türlerini ve veritabanlarını kullanışlı hale getiren diğer tüm şeyleri yok sayarak) olması gerektiği söylendi:

• Veritabanı Sütunu: bir elektronik tablo sütunu gibi
• Veritabanı Kaydı: elektronik tablo satırı gibi
• Veritabanı Alanı: elektronik tablo "hücresi" gibi (belirli bir satırın belirli bir sütunu)

Bu doğru mu? Sütun ve alanın bundan daha birbirlerinin yerine kullanılabileceğine yemin edebilirdim. Kesinlikle öyleydim.

Biz Yani yok eklemek alanları bir tabloya biz eklemek sütunları bir tabloya ve bir kayıt içinde veri bahsederken alanlar sadece alakalı?

Sütun ve tarla hakkındaki diğer düşünceler?

Düzenleme: açıklığa kavuşturmak için, geçerli bağlam MS SQL Server'dır. SQL sunucusundan önceki geçmişim bu koşulları kullanmamı etkileyebilecek MS Access'ti.

İlişkisel veritabanı teorisi Alan kelimesinin kullanımını içermez. RDBMS'lerin teorik temellerini veren bir dizi makale yazan Dr. EF Codd, bu terimi hiçbir zaman kullanmadı. Kontrol etmek isterseniz 1970 tarihli büyük Paylaşılan Veri Bankaları için İlişkisel Bir Veri Modeli makalesini okuyabilirsiniz .

Domain, Table, Attribute, Key ve Tuple gibi terimler kullanılır. Bunun bir nedeni, makalelerinin büyük ölçüde ilişkisel cebirle ilgili olması ve belirli bir uygulamanın veritabanındaki bir tabloyu tanımlama biçiminin Codd tarafından önemli olmadığıdır. Satıcılar bunu daha sonra ortaya çıkarırdı. İnsanlar ayrıca tarihsel olarak, RDBMS'lerin kendilerinden önce var olan hiyerarşik ve ağ veritabanlarından evrimleştiklerini ve bir RDMBS'nin iç çalışmalarının hala veri organizasyonu ve depolama ile ilgili olması gerektiğini anlamalıdır.

Ortak kullanımda, ve kolayca basitçe googling biraz yaparak bu doğrulayabilir, Alanlar ve sütunlar bulunmaktadır aynı şey.

DBase, Access ve Filemaker gibi PC Veritabanları genellikle "sütun" yerine "alan" kullanır. "Özellik", birbirinin yerine kullanılabilen başka bir terimdir.

Örneğin, bir tabloya " alan " ekleme konusunda MS Access kılavuzunun bir bağlantısı . MS Access'te bir "alanın" bir "sütuna" eşdeğer olduğunu görmek açıktır.

Aynı şey Dbase ve Filemaker Pro için de geçerlidir.

Bazen insanlar belirli bir satırdaki belirli bir değeri "alan" veya daha düzgün bir şekilde "alan değeri" olarak adlandırırlar, ancak bu, bir sütun veya sütun eşdeğeri kavramına atıfta bulunurken "alan" kullanımını kullanmaz. Bu, insanların kafa karışıklığını uzun yıllar boyunca farklı şeyler ifade etmek için kullandıkları için bir düzeyde karışıklığa neden olma eğilimindedir. İlişkisel teoride - tek bir atomik değere "Datum" denir.

Birisi bir "alanın" ilişkisel bir veritabanında bir sütunla aynı değil, bir değer olduğunu belirttiyse, "alan" ilişkisel veritabanının yerel bir parçası olmadığı için onların görüşü budur. Ne doğru ne de yanlıştır, ancak veritabanı dünyasında, alan daha çok sütun anlamına gelir.

Bununla birlikte, projeler ve ekipler genellikle karışıklığı önlemek için proje içinde belirli terminolojiyi nasıl kullanmak istediklerini anlamak zorundadırlar.

Yanlış değilsiniz, ancak kullanılan kuralla birlikte devam etmeye veya "sütun" lehine sözcük alanını tamamen kullanmaktan kaçınmaya da karar verebilirsiniz. İlişkisel veritabanlarında, "Tablo" ve "Sütun" DDL'de bulunan yapı taşlarıdır ve yalnızca bu terimleri kullanmak ve kullanılmayan veya açıkça tanımlanmamış "alan" dan kaçınmak en iyisidir.

Eski SQL: 92 atıfta fieldstarih saat öğelerin bileşenleri olarak:

"Tarih / saat öğelerindeki alanlar", tarih-saat değeri oluşturabilen alanları belirtir; datetime değeri bu alanların bir alt kümesinden oluşur

Buradaki alanlar yıl, ay vb. ... ve terimin fieldbelgenin geri kalanında başka bir anlamı yok gibi görünüyor.

Daha yeni SQL: 2003 standardı şöyledir:

Sütunlar, alanlar ve özellikler

Sütun, alan ve öznitelik terimleri, sırasıyla tabloların, satır türlerinin ve yapısal türlerin yapısal bileşenlerini, benzer şekilde ifade eder. Bir tablonun yapısı bir veya daha fazla sütundan oluştuğu için, bir satır türünün yapısı bir veya daha fazla alandan ve yapılandırılmış türde bir veya daha fazla nitelikten oluşur. Bir sütun, bir alan veya bir nitelik olsun, her yapısal öğe, öncelikle bildirilen bir türle eşleştirilmiş bir addır.

ve sonra:

Bir F alanı , bir alan tanımlayıcı tarafından tanımlanır. Alan tanımlayıcı şunları içerir:
- Alanın adı.
- Bildirilen F türünün veri türü tanımlayıcısı
- F'yi yalnızca onu içeren satır türü içindeki sıralı konumu.

Şu şekilde tanımlanan sütunla bu kontrast:

C sütunu , bir sütun tanımlayıcı ile açıklanmaktadır. Bir sütun tanımlayıcı şunları içerir:
- Sütunun adı.
- Sütun adının uygulamaya bağlı bir ad olup olmadığı.
- Sütun bir etki alanına dayanıyorsa, o etki alanının adı; Aksi takdirde, beyan edilen C tipi tipinin veri türü tanımlayıcısı.
- Varsa, C'nin değeri.
- C'nin nullabilite özelliği
.
... (ve dahası)

Sonra daha sonra, tabloları tanıtırken:

Tablo, bir veya daha fazla sütuna sahip satırlardan oluşan bir koleksiyondur. Satır, satır türünün bir değeridir. Aynı tablonun her satırı aynı satır türüne sahiptir. Bir tablodaki her satırın i-th alanının değeri, tablodaki o satırın i-th sütununun değeridir . Satır, bir tabloya eklenebilen ve tablodan silinebilen en küçük veri birimidir.

(benimkini vurgulayın). Bu, soruya yazdıklarınızı destekliyor gibi görünüyor: belirli bir satırın belirli bir sütunu .

Pim başının etrafında kaç melek dans edebilir?

Sizi düzelten kişi düzeltilebilir.

• Tablo = İlişki

• Satır = Demet

• Sütun = Özellik

• Domain = Veri Türü

İlişkisel veritabanlarıyla ilgili Wikipedia girişine buradan bakın .

Bir havayolu şirketi için çalıştım ve "uçuş" kelimesi, pilotlarla / uçuş görevlileriyle, mühendislerle veya pazarlamayla konuşup konuşmamanıza bağlı olarak üç farklı şekilde kullanılabilir.

• pilotlar / görevliler: bir "uçuş" üssünden dışarı ve geri gidiyordu (yani iki kalkış ve iki iniş),

• mühendisler: bir kalkış ve bir iniş, test, onarım, eğitim (yani bir havaalanına aynı havaalanına) veya bir "bacak", yani bir havaalanına diğerine - "sivillerin" normalde uçuş dediği şey olabilir. "Yarın eve uçuşumu yapıyorum"),

• pazarlama: belirli bir havaalanından sözleşme kapsamında altı aylık (genellikle sezonda veya sezon dışında) bir dizi "uçuş" dizisi.

Elektronik tablo analojisi, makul teknik konuşmada bile (ilişkisel cebir profesörü değilse), vakaların% 99.99'u için yeterince iyidir. Sizi düzelten kişi "kime" kelimesini doğru kullanıyor mu? İnsanların% 99,99'u önemli değil ve gerçekten önemli değil.

Genellikle "alan" ve "sütun" terimlerini birbirinin yerine kullanırım, daha yakın zamanda "sütun" a yönelirim. Ben sadece "alan" terimini "veri" belirtmek için duymadım. Ayrıca "alan" veya "sütun" belirtmek için "öznitelik" terimini duymadım. Bir Sütun / Alan , örneğin FieldInfo Sınıfı üzerinden erişilebilen niteliklere sahiptir .

"Sütun" un sadece terminolojinin bir evrimi olduğuna inanıyorum. Masaüstü DB'ler (xBASE, MSAccess) genellikle "alan" kullanır. M204 "alan" kullanır. Bu "alan" terminolojisi MSOffice xml ve diğerlerine taşınmıştır. Oracle için dokümanlar (daha fazla bağlantı göndermeme izin vermem, özür dilerim) ve MSSQL, "field" ve "column" sözcüklerini birbirinin yerine kullanabilir. Sybase (şimdi bir SAP şirketi) ağırlıklı olarak belgelerinde "sütun" ama bazen "alan" kullanıyor.

Çalışma grubunuz bir terimi kabul ettiği sürece hangisinin önemli olduğu önemli değildir. "Başka herhangi bir isimle yükselen" bir sendromdur.

Bu yüzden bunun eski bir soru olduğunun farkındayım ama sık duyduğum bir soru. Benim üstlenmem veri ekibimizin geliştirme ekibimizle olan ilgisinden kaynaklanıyor. Geliştiriciler kesinlikle kayıtlarda ekranlarda gösterilen alanlara sahiptir ve bu alanlar sıklıkla belirli satırlara sahip sütunlarla eşleştirilebilen veriler içerir. Bununla birlikte, çoğu durumda verilere erişmek için kullanılan ilişkisel yöntem, belirli bir alanda belirli bir ekranda ortaya çıkanları değiştirebilir.

Kayıt, verinin sağladığı mevcut değerin bir temsilidir. Zaman geçtikçe bu değerler değişebilir ve değişebilir, böylece kayıt da değişir. Şu anda ne olduğunu ve belirli bir zamanda ne olduğunu destekleyen veriler kolayca bir dizi tabloya kaydedilebilir. Veriler arasındaki ilişkiler, herhangi bir zamanda kaydı oluşturan anlamları belirler.

Alanları türeyen mantık, zaman içinde değişebilen bir şeydir. Örneğin, bir çalışan Susan Jones olarak işe alınır ve 12/01/2010 tarihinde 101 numaralı mağazadaki satış memuru olarak Bill Anderson'a mağaza müdürü olarak rapor verir. Bu, ilerici bir şirket olmakla birlikte, her bir çalışana atanmış bir akıl hocası da vardır. Susan'ın akıl hocası Mary Phillips. Mary Phillips bir mağaza müdürü ama aynı zamanda Susan'ın çalıştığı mağaza için bölge müdürü. 11/10/2011 tarihinde Susan mağaza müdürlüğüne terfi etti. Bill'e ne olduğunu bilmiyoruz ama Susan şimdi mağaza müdürü.

İsim, numara, işe alım tarihi, pozisyonu ve yeri olan bir çalışan tablonuz var.

Mentorlar için çalışan numaralarına ve mentorluk yaptıkları çalışana artı mentor ilişkisinin başlangıcını ve sonunu açıklayan tarihleri ​​içeren bir mentor tablonuz var.

Bölge adı ve atanmış bir yönetici numarasına sahip bölgeler tablosu var.

Adres, açıklama, bölge ve yönetici numarası içeren başka bir konum tablonuz var.

Mağaza bilgilerinin görüntülendiği ekranın mağaza yöneticisi için bir alanı olabilir. Mağaza yöneticisinin değeri bir veritabanı alanı değil, zaman içinde değişebilen hesaplanabilir bir değerdir. Ayrıca bir kişinin yöneticisi de değişebilir. Onu destekleyen veriler hala sütunlarda saklanır, ancak sütunlar arasındaki ilişkiler değişmiştir ve belirli bir amaç için birleştirildiğinde alan haline gelir.