Início / dba / Perguntas / 72542
Accepted
reox
Asked: 2014-07-29 00:48:35 +0800 CST

Armazena dados n:m com a maioria das tuplas n:1

  • 772

Eu tenho essas tabelas:

create table data (
    id int identity not null,
    ref int not null
);

create table reference (
    refid int not null
);

com aproximadamente 2 milhões de linhas em dados e aproximadamente 200 mil linhas em referência. Eu adiciono cerca de 5.000 linhas aos dados todos os dias, resultando em 500-5.000 linhas adicionais em referência por dia.

Na maioria dos casos, preciso salvar apenas uma referência para uma coluna de dados (várias entradas de dados podem ter a mesma referência), mas em alguns casos (atualmente cerca de 0,1%) preciso salvar mais de uma referência.

Eu provavelmente poderia usar uma terceira tabela como:

create table data_reference (
     dataid int not null,
     refid int not null
);

criar um mapeamento an:m mas para a maioria dos valores não vai ter nenhum ganho aqui, vai apenas criar outro join...

Eu também poderia criar uma segunda coluna em cada linha de dados, porque na maioria dos casos eu tenho apenas uma referência adicional (mas em teoria poderia haver mais) e salvar null se nenhuma outra referência estiver lá - o que me parece muito ruim porque pode haver tuplas com 3 ou mais referências.

Existe uma maneira eficiente e fácil de manter para salvar esses dados?

sql-server database-design

2 respostas

  1. Best Answer

    Usar uma tabela intermediária é a maneira correta de fazer isso. Com índices adequados e boa manutenção não vai prejudicar muito o desempenho.

    Evite a solução de várias colunas ( refid1, refid2etc.) - isso está repetindo grupos e não está devidamente normalizado. Além disso, suas consultas degenerarão em um café da manhã canino de cláusulas OR e instruções CASE, o que prejudicará o desempenho.

    Você pode obter algum benefício ao subdigitar suas datalinhas, então a maioria usa seu arranjo atual, mas aqueles com vários referenceusam um diferente. Suas consultas serão UNION ALLos dois conjuntos para obter o total. Eu realmente duvido que a sobrecarga disso compense a junção redundante para arquivos data_reference.

    O esquema subtipado ficaria assim:

    create table data (
    id int identity not null,
    ref int not null,       -- set to a standard value for rows with >1 reference.
    is_single_reference bit not null
);

create table reference (
    refid int not null
);

create table data_reference (
     dataid int not null,
     refid int not null
);

    A consulta seria algo como:

    select
    <whatever>
from data as d
inner join reference as r
    on d.ref = r.refid
where d.is_single_reference = 1

union all

select
    <whatever>
from data as d
inner join data_reference as dr
    on dr.dataid= d.id
inner join reference as r
    on r.refid = dr.refid
where d.is_single_reference = 0;

    Isso é bastante feio. Você teria sorte se evitasse duas varreduras de arquivos data. Idealmente, você desejaria índices filtrados, mas o IIRC não está disponível até o SQL Server 2008. O aplicativo teria que saber quantas referencelinhas havia por data, definir sinalizadores de acordo e mantê-los se o número fosse alterado. Basta usar a abordagem n:m.

    • 1

  2. Uma maneira de fazer isso - tenha uma coluna varchar com uma lista delimitada de referências adicionais, se existirem (123.458.658.587 etc). Em seguida, crie uma UDF para dividir esses dados, se existirem, que você pode usar em consultas SELECT. Deve ser fácil projetar o UDF para extrair os dados. Como é raro, não deve prejudicar muito os recursos. Uma coluna varchar também deve significar requisitos mínimos de espaço extra.

    • -1

relate perguntas