Стовпець проти поля: чи неправильно я використовував ці терміни?

Мені тут соромно, я завжди використовував терміни "стовпчик" і "поле" абсолютно взаємозамінно, що останнім часом викликало певну плутанину в технічній дискусії.

Мені сказали, що це невірно, що це повинно бути (переклад кожного терміна в термінологію електронних таблиць, ігнорування типів даних та всі інші речі, які роблять бази даних корисними):

• Стовпець бази даних: як стовпець електронної таблиці
• Запис бази даних: як рядок електронних таблиць
• Поле бази даних: як "комірка" електронної таблиці (конкретний стовпець певного рядка)

Чи це правильно? Я міг би присягнути, що стовпчик і поле використовуються більш взаємозамінно, ніж це. Я, звичайно, був.

Отже, ми не додаємо поля до таблиці, додаємо стовпці до таблиці, а поля є актуальними лише тоді, коли йдеться про дані в записі?

Інші думки про колонку проти поля?

Редагувати: для уточнення, поточний контекст - це MS SQL Server. Моїм досвідом перед SQL-сервером був MS Access, що може вплинути на моє використання цих термінів.

Теорія реляційних баз даних не включає використання слова Field. Доктор Е. Ф. Кодд, який написав серію статей, які забезпечують теоретичну основу для RDBMS, ніколи не використовували цей термін. Якщо ви хочете перевірити, ви можете прочитати його семінарний документ 1970 р . Реляційна модель даних для великих спільних банків даних .

Використовуються такі терміни, як домен, таблиця, атрибут, ключ і кортеж. Однією з причин цього є те, що його роботи в значній мірі стосувалися реляційної алгебри, і те, як конкретна реалізація визначила б таблицю в базі даних, Кодд не вважав важливим. Постачальники випускають це пізніше. Люди також повинні розуміти, що історично RDBMS розвинулося з існуючих ієрархічних та мережевих баз даних, що передували їм, а внутрішня робота RDMBS все ще повинна стосуватися організації та зберігання даних.

У загальному користуванні, і ви можете легко перевірити це, просто зробивши трохи гуглінг, поля та стовпці - це одне і те ж.

Бази даних ПК, такі як DBase, Access та Filemaker, зазвичай використовують "поле" замість "стовпця". "Атрибут" - це ще один термін, який можна використовувати без змін.

Наприклад, ось посилання на посібник з MS Access щодо додавання " поля " до таблиці. Зрозуміло, що в MS Access "поле" еквівалентно "стовпцю".

Те саме стосується Dbase та Filemaker Pro.

Іноді люди позначають певне значення у певному рядку як "поле" або, більш правильно, "значення поля", але це не робить використання "поля", коли посилається на стовпець або еквівалент стовпця-поняття невірно. Це, як правило, викликає рівень плутанини, тому що люди використовували "поле", щоб означати різні речі протягом багатьох років. У реляційній теорії - єдине атомне значення називають "датою".

Якщо хтось заявив, що "поле" - це одне значення у реляційній базі даних, а не те саме, що стовпець, то це їхня думка, оскільки "поле" не є частиною просторічної реляційної бази даних. Вони не є ні правильними, ні неправильними, однак у всьому світі бази даних поле частіше використовується для позначення стовпця.

Зважаючи на це, проекти та команди часто мають виробити розуміння того, як вони хочуть використовувати певну термінологію в рамках проекту, щоб уникнути плутанини.

Ви не помиляєтесь, але ви також можете вирішити просто піти разом із умовою, що використовується, або уникати використання слова слова взагалі на користь "стовпця". З реляційними базами даних "Таблиця" та "Стовпець" - це будівельні блоки, що існують у DDL, і найкраще просто використовувати ці терміни та уникати "поля", яке не використовується та не чітко визначене.

Старіший SQL: 92 відноситься до fieldsкомпонентів елементів часу:

"Поля в елементах дати", вказує поля, які можуть складати значення часу дати; значення дати складається з підмножини цих полів

Поля тут - рік, місяць тощо - і цей термін field, схоже, не має іншого значення в решті документа.

Новіший стандарт SQL: 2003 має таке:

Стовпці, поля та атрибути

Терміни стовпчик, поле та атрибут відносяться до структурних компонентів таблиць, типів рядків та структурованих типів відповідно аналогічно. Оскільки структура таблиці складається з одного або більше стовпців, так і структура типу рядка складається з одного або декількох полів та структури структурованого типу одного або декількох атрибутів. Кожен структурний елемент, будь то стовпець, поле чи атрибут, - це перш за все ім'я, сполучене із заявленим типом.

і пізніше:

Поле F описується дескриптором поля. Дескриптор поля включає:
- Назва поля.
- Дескриптор типу даних оголошеного типу F.
- Порядкове положення F в межах типу рядка, який просто містить його.

Це контраст зі стовпцем, який визначається як:

Колонка З описується дескриптором стовпчика. Дескриптор стовпця включає:
- ім'я стовпця.
- чи ім'я стовпця є ім'ям, що залежить від реалізації.
- Якщо стовпець заснований на домені, то ім'я цього домену; в іншому випадку - дескриптор типу даних оголошеного типу C.
- Значення, якщо воно є, C.
- Характеристика зведеності для C.
- Порядкове положення С у таблиці, що містить його.
... (і більше)

Потім знову, вводячи таблиці:

Таблиця - це сукупність рядків, що мають один або кілька стовпців. Рядок - це значення типу рядка. Кожен рядок однієї таблиці має один і той же тип рядка. Значення i-го поля кожного рядка таблиці - це значення i-го стовпця цього рядка в таблиці . Рядок - це найменша одиниця даних, яку можна вставити в таблицю та видалити з таблиці.

(наголос мій). Це, мабуть, підтримує те, що ви написали у запитанні: конкретний стовпець конкретного рядка .

А скільки ангелів може танцювати навколо голови шпильки?

Людина, яка тебе виправила, може сама виправити.

• Таблиця = відношення

• Рядок = кортеж

• Стовпець = атрибут

• Домен = Тип даних

Дивіться запис Вікіпедії про реляційні бази даних тут .

Я працював у авіакомпанії, і слово "політ" можна вживати трьома різними способами залежно від того, чи говорили ви з пілотами / стюардесами, інженерами чи маркетингом.

• льотчики / супроводжуючі: "політ" був поза межами бази (тобто два зльоту і два посадки),

• інженери: один зліт і одна посадка, може бути випробуванням, ремонтом, навчанням (тобто один аеропорт назад до того ж аеропорту) або "нога", тобто один аеропорт в інший - те, що "цивільні особи" зазвичай називають рейсом, як у "Завтра я ловлюсь додому"),

• маркетинг: шестимісячна (як правило, міжсезоння або міжсезоння) серія "рейсів" з / в даний аеропорт у контексті контракту.

Аналогія електронних таблиць є більш ніж хорошою для 99,99% випадків, навіть у розумно технічній промові (якщо тільки не є професором реляційної алгебри). Чи правильно людина, яка вас виправила, використовує слово "кого"? 99,99% людей це не так, і це насправді не має значення.

Я, як правило, використовую взаємозамінно "поле" і "стовпець", останнім часом прагнучи до "стовпця". Я не чув лише термін "поле", щоб вказати "дані". Я також не чув термін "атрибут" для позначення "поля" або "стовпця". Стовпець / поле має атрибути, доступні, наприклад, через FieldInfo Class.

Я вважаю, що "стовпець" - це просто еволюція термінології. Настільні БД (xBASE, MSAccess) зазвичай використовують "поле". M204 використовує "поле". Ця "польова" термінологія була внесена в MSOffice xml та інші. Документи для Oracle (це не дозволить мені публікувати більше посилань, вибачте) і MSSQL використовують "поле" та "стовпчик" взаємозамінно протягом усього. Sybase (зараз компанія SAP) в своїй документації переважно використовує "стовпчик", але іноді "поле".

Поки ваша робоча група погоджується на термін, не має значення, яка саме. Це синдром "троянди будь-яким іншим ім'ям".

Тож я усвідомлюю, що це давнє питання, але саме таке я часто чую. Я сприймаю це за рахунок участі нашої групи даних з нашою командою розвитку. Розробники, безумовно, мають поля в записах, які відображаються на екранах, і ці поля містять дані, які часто можуть бути відображені в стовпці з певними рядками. Однак у багатьох випадках реляційний метод, що використовується для доступу до даних, може змінити те, що опиняється на певному екрані в певному полі.

Я записую - це представлення поточного значення, яке надають дані. З часом ці значення можуть і, ймовірно, змінюватись, тому і запис змінюється. Дані для підтримки того, що зараз є і яким він був у даний момент часу, можуть легко зберігатися у наборі таблиць. Взаємозв'язки між даними визначають значення, які складають запис у будь-який момент часу.

Логіка, яка виводить поля - це щось, що може змінюватися з часом. Наприклад, працівника приймають на роботу в якості Сьюзен Джонс, і вона була прийнята на роботу 12.01.2010 р. Як службова особа з продажу в магазині № 101, яка звітує перед Біллом Андерсоном як менеджером магазину. Будучи прогресивною компанією, вони також мають наставника, призначеного для кожного працівника. Наставник Сьюзен - Мері Філліпс. Мері Філліпс - менеджер магазину, але вона також є регіональним менеджером магазину, в якому працює Сьюзен. 11.10.2011 Сьюзен отримала посаду менеджера магазину. Ми не знаємо, що сталося з Біллом, але Сьюзен зараз є менеджером магазину.

У нас є таблиця працівників з прізвищем, номером, датою найму, посадою та місцезнаходженням.

У нас є таблиця наставника з номерами працівників для наставників та працівника, якого вони проводять, а також дати, що описують початок і кінець відносин з наставником.

У нас є таблиця регіонів з назвою для регіону та призначеним номером менеджера.

У нас є ще одна таблиця локацій з адресою, описом, регіоном та номером менеджера.

На екрані, який відображає інформацію про магазин, може бути поле для менеджера магазину. Значення менеджера магазину не є полем бази даних, але це обчислюване значення, яке може змінюватися з часом. Також менеджер людини може змінитися. Дані, що підтримують його, як і раніше зберігаються у стовпцях, але зв’язки між стовпцями змінилися, і коли збираються для певної мети, вони стають полем.