implicações de desempenho de ORDER BY COALESCE em MySQL

Question

implicações de desempenho de ORDER BY COALESCE em MySQL

votos

2

Meu problema geral é que eu quero que os usuários sejam capazes de, com efeito, adicione um número arbitrário de campos de diferentes tipos para associar com itens. Então, uma solução que eu estou considerando é o seguinte:

table `items`
item_id  |  name  

table `parameters`  
parameter_id  |  name  |  type

table `values`  
item_id  |  parameter_id  |  datetimevalue  |  datevalue  |  integervalue  |  etc...

Se um usuário quiser adicionar um Data de nascimento parâmetro para alguns de seus itens, que gostaria de acrescentar um parâmetro para a tabela de parâmetros e, em seguida, uma entrada na tabela de valores para cada item que ele quer ter esse parâmetro, com o data indo na coluna datevalue e todos os outros campos 'valor' deixado nulo.

Para encomendar os seus itens por Data de nascimento, supondo que este parâmetro tem parameter_id = 1, eu faria

SELECT * from 
items
join values on items.item_id = values.item_id
join parameters on parameters.parameter_id = values.parameter_id

where parameter_id = 1
order by coalesce(values.datetimevalue, values.datevalue, values.integervalue...)

A minha pergunta concreta é, este vai POR ORDEM ser performance? Será que vai fazer bom uso de índices? Será que vai fazer um trabalho desnecessário?

A minha pergunta geral é, é esta abordagem boas práticas? Existe uma maneira melhor de fazer isso?

mysql

Publicado 26/08/2009 em 22:20
fonte usuário Ben P

Em outras línguas...

2 respostas

astropanic · Answer 1 · 2009-08-26 22:28

votos

1

Você está falando de modelagem EAV.

Ter um olhar para a modelagem EAV

Respondeu 26/08/2009 em 22:28
fonte usuário astropanic

casey · Answer 2 · 2009-09-03 05:52

Este ORDER BY COALESCE ... não será capaz de fazer uso de um índice. É o COALESCE importante? Parece que se você está olhando para um único parâmetro, ordenando pelas colunas seria suficiente porque todos os valores serão do mesmo tipo.

Essa consulta seria capaz de fazer uso de um índice em (parameter_id, DateTimeValue, datevalue, integervalue) se você acabou de fazer "ORDER BY DateTimeValue, datevalue, integervalue".

As desvantagens: 1) parece um pouco confuso 2) se você tiver lotes de colunas de valor e se a sua mesa valores vai ser grande, que o índice vai perder espaço e lê / escreve.

Você pode ser melhor se você acabou de adicionar um "sort_order" (ou algo assim) coluna à tabela valores e índice de que, em vez. Além disso, se você realmente precisa do COALESCE porque você quer classificar valores de tipos diferentes, você pode escolher um cálculo sort_order que vai fazer a coisa certa.