Existe uma convenção / padrão para a ordenação de colunas em uma definição de tabela de banco de dados?

Question

Existe uma convenção / padrão de como as colunas devem ser ordenados na definição de uma tabela de banco de dados, e em caso afirmativo, qual é a motivação para esse padrão? (Vantagens / desvantagens)

Por exemplo, se a chave primária ser a primeira coluna? Caso as chaves estrangeiras siga diretamente a chave primária ou eles devem ser colocados na extremidade direita da mesa?

Se houver uma diferença entre convenções para diferentes SGBDs, o DBMS, neste caso, é o Microsoft SQL Server 2005.

Obrigado / Erik

Answer 1

Eu não tenho conhecimento de qualquer padrão, mas a nossa forma de estruturar nossas colums é

1. Chave primária (s)
2. As chaves estrangeiras
3. Os dados

O grande colunas de dados, como comentários, são colocados no final. Ela torna mais fácil para ver o máximo de dados possível no Query Analyzer, sem ter que se deslocar para a direita.

Answer 2

Eu sempre estruturar minhas tabelas como este:

1. Chave primária (s)
2. colunas 'rastreamento' (DateModified, ModifiedBy e tal)
3. As chaves estrangeiras
4. Os dados

Answer 3

Eu não tenho certeza sobre as convenções set, mas colocamos sempre a coluna de chave ID / Primário como a primeira coluna na tabela. Acho que é só porque ele torna mais claro para ver o pk. Eu diria também acompanhar que com campos fk mas depois disso não há um padrão real, você poderia talvez fazê-lo por tipo de dados?

Além disso, este não é um conjunto a melhor prática, apenas uma escolha pessoal.

Answer 4

Não que eu saiba. Você sempre pode re-ordenar as colunas durante uma escolha de qualquer maneira, por isso pouco importa a menos que haja alguma otimização verdadeiramente obscura você pode fazer em alguns bancos de dados, ordenando suas colunas de forma adequada.

Answer 5

Não há nenhuma norma oficial que eu estou ciente de, mas a prática normal é colocar a chave primária primeiro (que é geralmente um substituto) e depois agrupar os outros campos por funcionalidade. Assim, em uma "pessoa" uma mesa de grupo faria os campos que contêm dados de endereço da pessoa junto. A maioria das pessoas adicionar FKs, índices e outros constrangimentos fora do definion mesa adequada.

Answer 6

mm .. Como eu sei que não há limitações. É apenas uma questão de clareza.

Answer 7

Eu concordo com a maioria dos posts acima, chave primária primeiro (pelo menos). O resto é preferência pessoal. Se você tem um padrão, em seguida, manter esse padrão.

Eu prefiro manter colunas bastante logicamente juntos. Às vezes, uma estrutura de dados totalmente normalizado não é apropriado, de modo que você tem "entidades menores" armazenados na mesma tabela (ou seja, não remover valores nulos). Um exemplo seria os campos de endereço ou o telefone diferente, telefone celular, colunas de telefone de trabalho colocados juntos.

O exemplo mais marcante que posso dar é como não fazê-lo. Se um desenvolvedor autogenerates um esquema e as colunas são criados em ordem alfabética (e até mesmo o PK estava escondida no meio da estrutura da tabela), então, que é mais irritante.

Answer 8

De acordo com edoode: -

Primary key(s) 
'Tracking' columns (DateModified, ModifiedBy and such) 
Any foreign keys 
Data 

Além disso

Fixed width 'not null' columns
Fixed width 'nullable' columns
Variable Width columns VARCHAR NVARCHAR etc.
CLOBS
BLOBS 

Você ganha um pequenininho pequeno nunca aumento de desempenho tão leve se você ficar colunas que podem variar em comprimento na parte inferior da tabela.