Qual é a diferença entre um "registro" e uma "linha" no SQL Server?

Para citar Joe Celko (não apenas você pode encontrar essa referência em toda a web e em sua entrada na Wikipedia , mas você também a verá em camisetas em algumas conferências):

As linhas não são registros.

Muitas pessoas o apontam como um idiota pedante que só gosta de humilhar e abusar verbalmente de novatos, e eu admito que é assim que ele se vê. Mas também o conheci pessoalmente - até mesmo compartilhei uma refeição com ele - e não posso dizer o quão diferente sua personalidade na vida real é de sua frente online. Eu até o peguei uma vez ligando para registros de linhas, e ele ficou muito envergonhado ( história completa aqui ).

De qualquer forma, diga o que quiser sobre o personagem online do cara, mas ele escreveu o padrão , e o fato de tal autoridade ditar que há uma distinção deve lhe dizer algo. E por mais que ele se envergonhe quando alguém chama uma linha de registro, muitos de meus colegas também se encolhem - que também são especialistas no mundo do SQL Server. E aqueles de nós nesse campo acreditam que ele está certo.

Por exemplo, Itzik Ben-Gan, um guru óbvio do SQL Server. Aqui está uma citação da primeira lição em seu Kit de Treinamento (Exame 70-461): Consultando o Microsoft SQL Server 2012 :

Como exemplo de termos incorretos no T-SQL, as pessoas costumam usar os termos “campo” e “registro” para se referir ao que o T-SQL chama de “coluna” e “linha”, respectivamente. Campos e registros são físicos. Campos são o que você tem em interfaces de usuário em aplicativos cliente e registros são o que você tem em arquivos e cursores. As tabelas são lógicas e possuem linhas e colunas lógicas.

E, conhecendo Itzik, se você lhe enviar um e-mail ou encurralá-lo em uma conferência, ele lhe dirá o mesmo com prazer. Se você chamar uma linha de registro, na opinião dele, você não está usando a terminologia corretamente.

Agora, sendo uma indústria cheia de pessoas de todos os tipos, é provável que você encontre material (como os artigos de alvo de tecnologia postados em outra resposta) que parecem fazer distinções muito sutis entre os dois, e você encontrará muitas pessoas na indústria considerá-los iguais (eu conheço várias pessoas da Microsoft e outras pessoas como Brent Ozar, que sempre chama isso de recorde). Isso não os torna certos, é apenas a maneira deles de ver as coisas - eles veem o lógico e o físico como a mesma coisa (pelo menos neste contexto) e muitos deles provavelmente pensam que o resto de nós é apenas retentores anais gastando muito tempo na semântica.

Como nenhum fornecedor pode dizer "você deve chamá-los de {registros|linhas}", estaremos sempre lidando com esse argumento, porque sempre haverá alguém que não entende o lógico versus o físico, ou foi ensinado de forma diferente, ou veio do Access ou de programação, etc. Assim como algumas pessoas dizem tomah-to e outras pessoas dizem tomah-to, sempre haverá uma variedade de pessoas que variam de "eles são iguais" a "eles são completamente diferentes " - e muitos tons no meio. Novamente, isso não torna nenhum deles certo, porque ninguém pode ser a autoridade máxima sobre isso. Mas no espaço do SQL Server, definitivamente há uma maioria.

Dito isso, IMHO, quando você está falando sobre dados que estão em uma tabela, você os chama de linha. Quando você está executando uma inserção, está inserindo uma linha em uma tabela. Ao executar uma atualização, você está atualizando uma linha que está em uma tabela. E quando você executa um SELECT, você está recuperando linhas de uma tabela.

Sinta-se à vontade para chamá-lo de registro assim que seu aplicativo o possuir. Mas não fique bravo se você disser "Eu inseri um registro" e alguém o corrigir.

A Microsoft tem em vários lugares em sua organização desde que o nome oficial para armazenamento de dados tabulares por entrada de tabela (para cunhar uma definição taxonômica que serve ao meu próprio propósito) é chamado de "ROW". Eu submeto como evidência ROW_NUMBER, ROWCOUNTe ROWVERSIONa DataTable.Rowspropriedade, onde a DataTableé uma representação C# de um objeto "tabela" TSQL. Nesse caso, as propriedades do MSDN como um todo incentivam o uso de rowpara se referir a uma coleção de dados que é uma entrada em uma tabela. (note que estou tentando evitar o uso de "record" ou "row" para definir isso, sendo esse o ponto da questão)

No entanto, a linguagem é que um aplicativo lida com "registros" do usuário. Algo único sobre um registro que pode não ser representado diretamente por uma única linha de armazenamento é o fato de que um registro pode ter subregistros. É verdade que uma tabela pode ter tabelas muitos-para-um relacionadas, mas elas não são armazenadas de forma contígua, mas são armazenadas logicamente relacionadas.

Assim, uma linha é a coisa em uma tabela, e um registro é a coisa com a qual o desenvolvedor trabalha na prática.

Acabei de pesquisar no documento "Tecnologia da informação — Linguagens de banco de dados — SQL Parte 2: Fundação (SQL/Fundação)", que define o padrão ANSI para SQL conforme implementado por todos os principais RDBMSes.

A palavra rowé usada principalmente em todo o documento várias centenas de vezes, como esperado.

A palavra recordfoi usada apenas para descrever um registro semelhante a um registro usado no Oracle PL/SQL (descrevendo especificamente os tipos de dados de registro ADA). 6 menções no documento.

Acho que isso esclarece essa questão e responde aos vários argumentos de ambos os lados.

informação adicional

De uma cópia de um padrão SQL (versão de rascunho do mais recente disponível gratuitamente), que pode ser encontrado em wiscorp.com (a página Padrões SQL tem várias outras versões e revisões mais antigas).

Pesquisando o 7IWD2-02-Foundation-2011-12.pdf , com data de 2011-12-21 revela que a palavra linha aparece 2277 vezes no documento enquanto a palavra registro aparece apenas 21 vezes, seja como o verbo "registrar" ou em alguns apêndices no final, em especificações das correspondências de tipos de dados para tipos de dados SQL e tipos de linguagem host (Ada, Pascal).

Além disso, o mesmo documento tem na página 57 (grifo meu):

4.15.1 Introdução às tabelas

Esta Subcláusula é modificada pela Subcláusula 4.10.1, “Introdução às tabelas”, na ISO/IEC 9075-9.

Uma tabela é uma coleção de zero ou mais linhas em que cada linha é uma sequência de um ou mais valores de coluna. O tipo mais específico de uma linha é um tipo de linha. Cada linha de uma determinada tabela tem o mesmo tipo de linha, chamado de tipo de linha dessa tabela. O valor do i-ésimo campo de cada linha em uma tabela é o valor da i-ésima coluna dessa linha na tabela. A linha é a menor unidade de dados que pode ser inserida em uma tabela e excluída de uma tabela.

O grau de uma tabela e o grau de cada uma de suas linhas é o número de colunas dessa tabela. O número de linhas em uma tabela é sua cardinalidade. Uma tabela cuja cardinalidade é 0 (zero) é dita vazia.

Uma tabela é uma tabela base , uma tabela derivada ou uma tabela temporária .

Então, no que diz respeito aos SGBDs que usam SQL:

Linhas não são registros , campos não são colunas, tabelas não são arquivos!

Como os bancos de dados relacionais raramente são usados ​​isoladamente, para evitar confusão entre outras partes dos sistemas, sempre me refiro a tabelas, linhas e colunas. Em um aplicativo cliente, normalmente temos outras construções, incluindo leitores de dados, conjuntos de dados, linhas de dados, tabelas de dados, etc - por exemplo, "campo" é frequentemente usado para entrada de dados na tela e Pascal tem um tipo de dados Record que é semelhante a uma estrutura em C .

Às vezes, em um projeto de sistema, a ideia de um "Registro" pode ser usada para significar algo mais amplo do que uma única linha. Pode ser uma briga e é história. Assim como quando falamos de uma linha excluída podemos significar uma linha que é simplesmente marcada como excluída com uma coluna ou "movida" para uma tabela excluída (e não simplesmente a ausência de uma linha que, por não existir, é bastante difícil de pino para baixo). Há apenas um uso mais variado do termo Record.

Tabelas, linhas e colunas são terminologias geralmente aceitas para se referir a essas entidades em bancos de dados relacionais, incluindo artigos e trabalhos de Codd e Date, e a maioria dos profissionais de banco de dados prefere essa terminologia por ser mais inequívoca.

Geralmente não há ambiguidade quando se fala sobre linhas e colunas - outras pessoas entendem que você está falando sobre o design físico do banco de dados subjacente e não qualquer outro tipo de artefato de um design lógico antes do design físico ou qualquer entidade de sistema emergente posterior, como campos em um tela.

Embora sua pergunta já tenha sido respondida muito bem. Gostaria de adicionar meus pontos também. Pode ser que você ache útil até certo ponto. Além disso, minha resposta não é específica para o SQL Server

Essas palavras são usadas de forma intercambiável.

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

Column =  Field   =  Attribute    =  Attribute

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

• 4 terminologia boa para usar quando aprendemos ER-Modules
• 3 use quando Modelo Relacional
• 2 em geral, DataBase books start with these terminologyporque estes são muito usados ​​por pessoas na vida real, também em sistema de arquivos.

Registro é a unidade básica no sistema de armazenamento que tem significado implícito. Em DBMS, a palavra recorduse no capítulo descreve como as tabelas de banco de dados são armazenadas em blocos de disco. No DBMS a record-oriented file-systemé um sistema de arquivos onde os arquivos são armazenados como coleções de registros.

A linguagem continua evoluindo. Algumas décadas atrás, as pessoas alfabetizadas usavam "índices" em vez de "índices" mais simples. Ao mudarmos para "índices", eliminamos uma complicação desnecessária e tornamos a linguagem mais útil. A necessidade de memorizar um plural para "índice" era pura sobrecarga - não nos ajudava de forma alguma a nos comunicar. Não se engane, costumava haver nazistas gramaticais que gostavam de corrigir aqueles que mudavam para "índices". Claro, os nazistas da gramática perderam. É assim que a navalha de Occam elimina detalhes inúteis se a coisa toda permanecer relevante por tempo suficiente.

Então vamos com calma - saber a diferença entre linhas e registros não adiciona absolutamente nada à nossa capacidade de desenvolver e manter bancos de dados. Muitos profissionais excelentes usam linhas e registros de forma intercambiável, mas desenvolvem sistemas incríveis. Como tal, a navalha de Occam deve eventualmente eliminar a distinção, e a próxima geração terá que aprender um fato menos inútil. Se, é claro, o SQL ainda for relevante naquele momento.

Resposta curta :

• Um registro é um pedaço de dados armazenados (ou coletados).
• Uma linha é um registro armazenado linearmente.
• Sempre que possível, use o termo mais específico.

Observação: as tabelas armazenam os registros linearmente e as consultas retornam os resultados linearmente

Suporte :

Definições adicionais de toda a web:

• SQL "linha" ( 1 , 2 )
• SQL "registro" ( 1 , 2 )
• "registro" ( 1 , 2 , 3 , 4 )
• "linha" ( 1 , veja também 2 , 3 , 4 )
• Row vs Record no StackOverflow ( 1 , 2 )

É notável que as definições SQL geralmente seguem a definição em inglês.

Se você tem uma definição que acha que deveria estar aqui, por favor, adicione-a aos comentários.
Estou especialmente interessado em definições do padrão SQL ou na documentação de uma implementação.

A citação foi levantada "Linhas não são registros." Tirado do contexto, isso parece contradizer minhas afirmações anteriores (e as de muitos profissionais de banco de dados). Mas, se você ler todo o post( 1 Procure a citação) por Joe Celko (aka --CELKO--) fica claro que Joe Celko está tentando corrigir um equívoco de um indivíduo que Joe Celko acredita surgir do " ... experiência em processamento de dados com sistemas de arquivos tradicionais ...". Resumindo, Joe Celko está dizendo que as linhas SQL não funcionam da mesma forma que os registros em outros sistemas. Joe Celko não está reivindicando o direito/privilégio de definir um termo, ele está tentando esclarecer uma falta de entendimento causada pela aplicação incorreta de princípios de um modelo de armazenamento para outro.

Para citar o livro de CJ Date "An Introduction to Database Systems" " As linhas de tal tabela podem ser pensadas como os registros do arquivo... "

Então, para bancos de dados, é Row.