Relacionamento muitos-para-muitos: use tabela associativa ou valores delimitados em uma colun
Update 2009.04.24
O ponto principal da minha pergunta não é confusão do desenvolvedor e o que fazer sobre iss
objetivo é entender quando os valores delimitados são a solução cert
Vi dados delimitados usados em bancos de dados de produtos comerciais (Ektron lol
@SQL Server ainda possui um tipo de dados XML, de modo que pode ser usado para a mesma finalidade que os campos delimitado
/ end Atualização
A aplicação que estou desenvolvendo possui alguns relacionamentos muitos-para-muitos. No passado, eu costumava usar tabelas associativas para representá-las no banco de dados. Isso causou certa confusão para os desenvolvedore
Aqui está um exemplo de estrutura de banco de dados:
Document
---------------
ID (PK)
Title
CategoryIDs (varchar(4000))
Category
------------
ID (PK)
Title
Existe uma relação muitos-para-muitos entre Documento e Categori
Nesta implementação, Document.CategoryIDs é uma grande lista delimitada por canal de CategoryID
Para mim, isso é ruim porque requer o uso de correspondência de substring nas consultas - que não podem fazer uso de índices. Acho que isso será lento e não será escalável.
Com esse modelo, para obter todos os documentos de uma categoria, seria necessário algo como o seguinte:
select * from documents where categoryids like '%|' + @targetCategoryId + '|%'
minha solução é criar uma tabela associativa da seguinte form
Document_Category
-------------------------------
DocumentID (PK)
CategoryID (PK)
Isso é confuso para os desenvolvedores. Há alguma solução alternativa elegante que estou faltando?
Estou assumindo que haverá milhares de linhas no documento. A categoria pode ter cerca de 40 linhas. A principal preocupação é o desempenho da consulta. Estou projetando demais isso?
Existe um caso em que é preferível armazenar listas de IDs nas colunas do banco de dados, em vez de enviar os dados para uma tabela associativ
Considere também que talvez seja necessário criar relacionamentos muitos para muitos entre os documentos. Isso sugeriria uma tabela associativa Document_Document. Esse é o design preferido ou é melhor armazenar os IDs de documentos associados em uma única coluna?
Obrigado