В чем разница между «записью» и «строкой» в SQL Server?

Был довольно безобидный вопрос о добавлении даты и времени в SQL Server, который вызвал довольно увлекательные таксономические дебаты.

Итак, как мы можем различать эти термины и как мы их правильно используем?

Ряд

запись

Цитируя Джо Селко (вы можете не только найти эту ссылку в Интернете и в его записи в Википедии , но вы даже увидите ее на футболках на некоторых конференциях):

Ряды не являются записями.

Многие люди указывают на него как на педантичного придурка, которому просто нравится унижать и оскорблять новичков, и я признаю, что именно так он и сталкивается. Но я также встретил его лично - даже поделился с ним едой - и я не могу сказать вам, насколько отличается его реальная личность от его онлайн-фронта. Я даже однажды поймал его на вызовах записей строк, и он был очень смущен ( полная предыстория здесь ).

В любом случае, что бы вы ни говорили о характере этого парня в Интернете, он написал стандарт , и тот факт, что такой авторитет диктует наличие различий, должен вам кое-что сказать. И как бы он ни напрягался, когда кто-то называет запись строкой, то же самое делают и мои коллеги, которые также являются экспертами в мире SQL Server. И те из нас в этом лагере считают, что он прав.

Например, Ицик Бен-Ган, очевидный гуру SQL Server. Вот цитата из самого первого урока из его Учебного комплекта (экзамен 70-461): Запросы к Microsoft SQL Server 2012 :

В качестве примера неверных терминов в T-SQL, люди часто используют термины «поле» и «запись», чтобы ссылаться на то, что T-SQL называет «столбец» и «строка» соответственно. Поля и записи являются физическими. Поля - это то, что есть в пользовательских интерфейсах клиентских приложений, а записи - в файлах и курсорах. Таблицы являются логическими, и у них есть логические строки и столбцы.

И, зная Ицик, если вы отправите ему электронное письмо или отправите его на конференцию, он с радостью скажет вам то же самое. Если вы называете строку записью, по его мнению, вы неправильно используете терминологию.

Теперь, будучи отраслью, наполненной людьми всех видов, вы, скорее всего, найдете материал (например, статьи о технических целях, опубликованные в другом ответе), который, кажется, делает очень тонкие различия между ними, и вы найдете много людей в отрасли. Рассматривайте их одинаково (я знаю нескольких людей в Microsoft и других людей, таких как Брент Озар, который всегда будет называть это записью). Это не делает их правильными, это просто их взгляд на это - они рассматривают логическое и физическое как одно и то же (по крайней мере, в этом контексте), и многие из них, вероятно, думают, что остальные из нас - просто анальные удерживающие устройства, проводящие слишком много времени по семантике.

Поскольку ни один продавец не может сказать «ты будешь называть их {records | row}» », мы всегда будем иметь дело с этим аргументом, потому что всегда найдется кто-то, кто не понимает логическое или физическое, или его учили по-другому, или пришли из Access или из среды программирования и т. д. Точно так же, как некоторые люди говорят tomay-to, а другие люди говорят tomah-to, всегда найдется множество людей, которые варьируются от «они одинаковы» до «они совершенно разные». "- и много оттенков между ними. Опять же, это не делает ни одного из них правильным, потому что никто не может быть окончательным авторитетом в этом. Но в пространстве SQL Server определенно есть большинство.

Тем не менее, ИМХО, когда вы говорите о данных, которые находятся в таблице, вы называете это строкой. Когда вы выполняете вставку, вы вставляете строку в таблицу. Когда вы запускаете обновление, вы обновляете строку в таблице. И когда вы выполняете SELECT, вы извлекаете строки из таблицы.

Не стесняйтесь называть это записью, как только ваше заявление удержит ее. Но не сердитесь, если вы скажете: «Я вставил запись», и кто-то исправит вас.

Microsoft в нескольких местах в своей организации предусматривала, что официальное название для хранения табличных данных на каждую запись в таблице (для обозначения таксономического определения, которое служит моим собственным целям) называется «ROW». Я представляю в качестве доказательства ROW_NUMBER, ROWCOUNT, ROWVERSIONи DataTable.Rowsимущество, где DataTableесть C # представление «таблицы» объект TSQL. В этом случае свойства MSDN в целом поощряют использование rowссылки на коллекцию данных, которая является одной записью в таблице. (обратите внимание, я пытаюсь избежать использования «записи» или «строки», чтобы определить это, что является предметом обсуждения)

Тем не менее, речь идет о том, что приложение имеет дело с «записями» пользователя. Что-то уникальное в записи, которая не может быть напрямую представлена ​​одной строкой хранения, - это тот факт, что запись может иметь подзаписи. Правда, таблица может иметь связанные таблицы «многие-к-одному», но они не сохраняются непрерывно, а хранятся логически связанными.

Итак, строка - это то, что находится в таблице, а запись - это то, с чем разработчик работает на практике.

Я только что просмотрел документ «Информационные технологии - языки баз данных - SQL, часть 2: основа (SQL / Foundation)», в котором определяется стандарт ANSI для SQL, применяемый всеми основными СУБД.

Слово rowиспользуется в основном в документе несколько сотен раз, как и ожидалось.

Это слово recordиспользовалось только для описания записи, схожей с записью, используемой в Oracle PL / SQL (в частности, для описания типов данных записей ADA). 6 упоминаний в документе.

Я думаю, что это проясняет этот вопрос и отвечает на различные аргументы с обеих сторон.

Дополнительная информация

Из копии (черновой версии последнего свободно доступного) стандарта SQL, которую можно найти на wiscorp.com (на странице Стандарты SQL есть несколько других более старых версий и редакций).

Поиск в файле 7IWD2-02-Foundation-2011-12.pdf с датой 2011-12-21 показывает, что строка слова встречается в документе 2277 раз, а запись слова - только 21 раз, либо как глагол «запись». или, в конце, в некоторых приложениях, в спецификациях соответствия типов данных для типов данных SQL и типов основного языка (Ada, Pascal).

Более того, тот же документ имеет на странице 57 (выделено мое):

4.15.1 Введение в таблицы

Этот подпункт изменен подпунктом 4.10.1 «Введение в таблицы» в ИСО / МЭК 9075-9.

Таблица представляет собой набор из нуля или более строк, где каждая строка представляет собой последовательность из одного или нескольких значений столбца. Наиболее конкретный тип строки - это тип строки. Каждая строка данной таблицы имеет один и тот же тип строки, называемый типом строки этой таблицы. Значением i-го поля каждой строки в таблице является значение i-го столбца этой строки в таблице. Строка - это наименьшая единица данных, которую можно вставить в таблицу и удалить из таблицы.

Степень таблицы и степень каждой из ее строк - это число столбцов этой таблицы. Количество строк в таблице - это ее мощность. Таблица, мощность которой равна 0 (нулю), называется пустой.

Таблица является либо базовой таблицей , A производной таблицы или переходной таблица .

Что касается СУБД, использующих SQL:

Строки не являются записями , поля не являются столбцами, таблицы не являются файлами!

Поскольку реляционные базы данных редко используются изолированно, чтобы избежать путаницы между другими частями систем, я всегда ссылаюсь на таблицы, строки и столбцы. В клиентских приложениях у нас обычно есть другие конструкции, в том числе устройства чтения данных, наборы данных, базы данных, таблицы данных и т. Д. Например, «field» часто используется для ввода данных на экране, а Pascal имеет тип данных Record, который похож на структуру в C ,

Иногда при проектировании системы идея «записи» может использоваться для обозначения чего-то более широкого, чем одна строка. Это может быть ряд, и это история. Точно так же, когда мы говорим об удаленной строке, мы можем иметь в виду строку, которая просто помечается как удаленная с помощью столбца или «перемещается» в удаленную таблицу (а не просто как отсутствие строки, которую, по причине отсутствия, довольно сложно придавить). Там просто более разнообразное использование термина Record.

Таблицы, строки и столбцы являются общепринятой терминологией для ссылки на эти объекты в реляционных базах данных, включая статьи и работы Codd и Date, и большинство специалистов по базам данных предпочитают эту терминологию, поскольку она более однозначна.

Обычно нет никакой двусмысленности, когда говорят о строках и столбцах - другие люди понимают, что вы говорите о физическом проекте базовой базы данных, а не о каких-либо других видах артефактов от логического проекта до физического проекта или любых последующих возникающих системных объектов, таких как поля в экран.

Хотя на ваш вопрос уже ответили очень хорошо. Я хотел бы добавить свои очки тоже. Может быть, вы найдете это полезным до некоторой степени. Также мой ответ не относится к SQL Server

Эти слова используются взаимозаменяемо.

 1          2         3              4 
--------------------------------------------------------------------
Row    =  Record  =  Tuple        =  Entity 

Column =  Field   =  Attribute    =  Attribute

table  =  File    =  Relation     =  Entity Types(or Entity Set)

• 4 терминологии, которые можно использовать, когда мы изучаем ER-модули
• 3 использовать при реляционной модели
• 2 общая сцена, DataBase books start with these terminologyпотому что они очень часто используются людьми в реальной жизни, а также в файловой системе.

Запись - это базовая единица в системе хранения, которая имеет неявное значение. В СУБД слово « recordиспользование» в главе описывает, как таблицы базы данных хранятся на дисковых блоках. В СУБД record-oriented file-systemесть файловая система, в которой файлы хранятся в виде наборов записей.

Язык продолжает развиваться. Несколько десятилетий назад грамотные люди использовали «индексы» вместо более простых «индексов». Когда мы переключились на «индексы», мы устранили ненужные сложности и сделали язык более полезным. Необходимость запоминания множественного числа для «индекса» была чисто накладной - это никак не помогало нам общаться. Не заблуждайтесь, раньше были нацисты по грамматике, которым нравилось исправлять тех, кто перешел на «указатели». Конечно, грамматику нацисты проиграли. Вот как бритва Оккама устраняет ненужные детали, если все это остается актуальным достаточно долго.

Так что давайте будем спокойны - знание различий между строками и записями абсолютно ничего не меняет в нашей способности разрабатывать и поддерживать базы данных. Многие отличные профессионалы используют строки и записи взаимозаменяемо, но при этом разрабатывают потрясающие системы. Таким образом, бритва Оккама должна в конечном итоге устранить это различие, и следующему поколению придется изучить один менее бесполезный факт. Если, конечно, SQL все еще актуален в то время.

Процитирую книгу С.Дж. Дейта "Введение в системы баз данных" " Строки такой таблицы можно рассматривать как записи файла ... "

Итак, для баз данных это Row.

Краткий ответ :

• Запись - это часть сохраненных (или собранных) данных.
• Строка - это запись, хранящаяся линейно.
• Там, где это возможно, используйте более конкретный термин.

Примечание: таблицы хранят записи линейно, а запросы возвращают результаты линейно

Поддержка :

Дополнительные определения по всей сети:

• SQL "строка" ( 1 , 2 )
• SQL "запись" ( 1 , 2 )
• «запись» ( 1 , 2 , 3 , 4 )
• «ряд» ( 1 , см. также 2 , 3 , 4 )
• Строка против записи в StackOverflow ( 1 , 2 )

Примечательно, что определения SQL в целом соответствуют английскому определению.

Если у вас есть определение, которое, по вашему мнению, должно быть здесь, добавьте его в комментарии.
Меня особенно интересуют определения из стандарта SQL или документация реализации.

Была выдвинута цитата «Строки не являются записями». Вне контекста это, казалось бы, противоречило моим предыдущим утверждениям (и утверждениям многих специалистов по базам данных). Но, если вы прочитаете весь пост ( 1 Поиск цитаты) Джо Селко (он же - CELKO--), станет ясно, что Джо Селко пытается исправить неправильное представление о человеке, которое, по мнению Джо Селко, происходит от этого человека " ... фон в обработке данных с традиционными файловыми системами ... ". Короче говоря, Джо Селко говорит, что строки SQL не работают так же, как записи в других системах. Джо Селко не претендует на право / привилегию определения термина, он пытается прояснить неправильное понимание, вызванное неправильным применением принципов одной модели хранения к другой.