Nomenclatura de tabelas e normalização de banco de dados

Minha preferência seria nomear as colunas como final_flow_rate__value, etc, já que valuepor si só pode se tornar muito confuso se houver várias colunas com esse nome.

Tome por exemplo:

SELECT 
    measurement.value
    sampling_rate.value
    first_draft_flow_rate.value
    second_draft_flow_rate.value
    final_flow_rate.value
FROM 
    measurement
    INNER JOIN sampling_rate ON ...
    INNER JOIN first_draft_flow_rate ON ...
    INNER JOIN second_draft_flow_rate ON ...
    INNER JOIN final_flow_rate ON ...

Os resultados mostrarão os títulos das colunas, todos dizendo apenas value.

O seguinte retorna cabeçalhos de coluna que fazem mais sentido.:

SELECT 
    measurement.measurement_value
    sampling_rate.sampling_rate_value
    first_draft_flow_rate.first_draft_flow_rate_value
    second_draft_flow_rate.second_draft_flow_rate_value
    final_flow_rate.final_flow_rate_value
FROM 
    measurement
    INNER JOIN sampling_rate ON ...
    INNER JOIN first_draft_flow_rate ON ...
    INNER JOIN second_draft_flow_rate ON ...
    INNER JOIN final_flow_rate ON ...

Como um DBA encarregado de depurar o código de outras pessoas, eu odeio especialmente quando cada chave substituta em um banco de dados é nomeada IDna tabela referenciada e xxx_IDna tabela de referência. Por exemplo:

CREATE TABLE dbo.SomeTable
(
    ID INT NOT NULL
        CONSTRAINT PK_SomeTable
        PRIMARY KEY CLUSTERED
    , ...
);

CREATE TABLE dbo.SomeOtherTable
(
    ID INT NOT NULL
        CONSTRAINT PK_SomeOtherTable
        PRIMARY KEY CLUSTERED
    , SomeTable_ID INT NOT NULL
        CONSTRAINT FK_SomeOtherTable_SomeTable
        FOREIGN KEY REFERENCES dbo.SomeTable(ID)
    , ...
);

Esse padrão leva a padrões difíceis de depurar, como:

SELECT SomeTableID = st.ID
    , SomeOtherTableID = sot.ID
FROM dbo.SomeTable st
    INNER JOIN dbo.SomeOtherTable sot ON st.ID = sot.ID;

Que de fato deveria ser:

SELECT SomeTableID = st.ID
    , SomeOtherTableID = sot.ID
FROM dbo.SomeTable st
    INNER JOIN dbo.SomeOtherTable sot ON st.ID = sot.SomeTable_ID;

Se as tabelas forem definidas como:

CREATE TABLE dbo.SomeTable
(
    SomeTable_ID INT NOT NULL
        CONSTRAINT PK_SomeTable
        PRIMARY KEY CLUSTERED
    , ...
);

CREATE TABLE dbo.SomeOtherTable
(
    SomeOtherTable_ID INT NOT NULL
        CONSTRAINT PK_SomeOtherTable
        PRIMARY KEY CLUSTERED
    , SomeTable_ID INT NOT NULL
        CONSTRAINT FK_SomeOtherTable_SomeTable
        FOREIGN KEY REFERENCES dbo.SomeTable(SomeTable_ID)
    , ...
);

Com os mesmos nomes nas tabelas, esse bug quase NUNCA ocorrerá, já que a versão "errada" seria óbvia de detectar se implementada e provavelmente nunca seria implementada incorretamente em primeiro lugar:

SELECT st.SomeTable_ID
    , sot.SomeOtherTable_ID
FROM dbo.SomeTable st
    INNER JOIN dbo.SomeOtherTable sot ON st.SomeTable_ID = sot.SomeOtherTable_ID;

A versão correta, que é imensamente mais legível, é:

SELECT st.SomeTable_ID
    , sot.SomeOtherTable_ID
FROM dbo.SomeTable st
    INNER JOIN dbo.SomeOtherTable sot ON st.SomeTable_ID = sot.SomeTable_ID;

As colunas que contêm o mesmo conteúdo nas tabelas devem ser nomeadas exatamente da mesma forma em todas as tabelas em que são definidas, apenas para reduzir o legado negativo.

Isso não é administração de banco de dados, é modelagem de dados. Disciplinas muito diferentes.

Suponho que sua entidade principal seja Simulação e as tabelas que você lista a descrevem. Você não mostra a estrutura ou o conteúdo dessas tabelas, portanto, o seguinte é baseado em conjecturas.

A medição parece ser uma lista de tipos de medição: temperatura, fluxo, partículas por unidade de volume, etc. SamplingRates também se parece com uma lista de taxas válidas: 1/seg, 10/seg, 100/seg, etc.

Finalmente, há três tabelas que parecem ser uma, FlowRates, que também é uma tabela de pesquisa.

Isso significaria que uma Simulação é o resultado registrado de, digamos, uma leitura de temperatura a uma taxa de 10 vezes por segundo de um fluxo de 30 ml/s.

Isso é preciso? Se for, segue um exemplo:

Measurements
 ID  Name
  1  Temperature
  2  Particles per ml

SamplingRates
 ID  Name  Period
  1     1     sec
  2    10     sec

FlowRates
 ID  Rate  Unit Period
  1    10    ML    sec
  2    20    ML    sec
  2    30    ML    sec

Portanto, a entrada de Simulação de exemplo mostraria uma Medição de 1, SamplingRate de 2 e FlowRate de 3 -- juntamente com os resultados da medição, é claro, e provavelmente um registro de data e hora de quando a simulação foi realizada.

Ajudaria muito se você desse uma descrição em linguagem simples de um experimento: "Um experimento consiste em qualquer número de simulações. Uma simulação é composta de várias leituras de... feitas em uma certa frequência com base em ..." Não pense em termos de tabelas e colunas. Finja que está falando com um técnico de laboratório.

Atualização: ao projetar uma tabela (e isso se refere à nomenclatura dos campos), geralmente é uma boa ideia isolar a entidade de todas as outras entidades -- ou seja, a nomenclatura deve ser feita da forma mais livre de contexto possível. O que isso significa é que, se você tiver um campo que representa, digamos, o nome ou a descrição da entidade, chame esses campos de "Nome" e "Descrição". Não importa que você tenha dezenas de outros campos com nomes idênticos em tabelas espalhadas pelo banco de dados.

Uma tabela não tem contexto. É a consulta que estabelece um contexto.

select  s.Name as NewSite, u1.Name as Owner, u2.Name as Manager
from    Site s
join    Users u1
    on  u1.ID = s.OwnerID
join    Users u1
    on  u2.ID = s.MgrID
where   s.Created > '2015-01-01';

Aqui estão três tabelas, cada uma com o campo Name -- realmente não importa que uma tabela seja usada duas vezes. Dentro de cada tabela, Nome significa "este é o nome da entidade representada por esta linha".

O contexto estabelecido por esta consulta é facilmente identificado. Ele examina o proprietário e o gerente de todos os sites recém-criados e renomeia cada campo Nome para se adequar ao contexto. Consultas diferentes podem usar os campos em contextos completamente diferentes. Como é a consulta que define o contexto, deixe a consulta renomear os campos para o que melhor se adequar a esse contexto.

Não tente forçar um contexto com uma tabela nomeando os campos User_ID ou User_Name e assim por diante. Em uma consulta, os campos devem ser prefixados com o nome da tabela ou alias de qualquer maneira, para que nunca haja confusão.

where  User.Name = 'John Smith'

Compare com

where  User.User_Name = 'John Smith'

O extra "User_" não adiciona nenhuma informação útil. Além disso, você certamente encontrará algo assim:

where ExtremelyLongTableName.ExtremelyLongTableName_SomewhatLongFieldName = ...

Estou exausto apenas digitando uma vez. Além disso, alguns DBMSs limitam o tamanho dos nomes dos objetos. Oracle, iirc, considera apenas os primeiros 32 caracteres de um nome de objeto. Atingi esse limite mais de uma vez em lojas que usam a convenção tablename_fieldname . Nesse ponto, você deve usar abreviações, o que é realmente confuso.

De qualquer forma, "melhores práticas" é um conceito bastante subjetivo. As opiniões variam. Escolha o que for mais confortável para você.

Sempre tente pensar no futuro, use nomes de tabelas e campos que sejam autodocumentados (autoexplicativos) sempre que possível. Não basta juntar um monte de letras e assumir que a pessoa que vem atrás de você teria alguma ideia do que está olhando. Nomear coisas neste assunto também torna muito mais fácil ver quais resultados sua consulta está retornando.