[bglug] Mysql query

[Giuseppe Capizzi]

> - user: id, name
> - spec: id, label
> - spec_values: id, id_user,id_spec, value.
>
> Nella tabella spec ho alcune specifiche che possono essere assegnate agli
utenti, tipo "email", "telefono",... e posso aggiungerle man mano a seconda
della necessità. In spec_value ho il valore di queste specifiche, quindi il
valore di email, di telefono,...

Questo modello si chiama Entity-Attribute-Value (EAV) [1]. È utile quando:

1 - I possibili attributi sono tanti, ma ciascuna entità ne valorizza solo
pochi (matrice sparsa), per risparmiare spazio.
2 - Gli attributi variano a runtime.

Negli altri casi è generalmente considerato un antipattern [2], visti i
problemi che si porta dietro (tra i quali appunto la difficoltà di
interrogazione).

Ti consiglierei, se puoi, di passare ad un design più tradizionale, in cui
i vari attributi sono colonne della tabella 'user'. Gli attributi non mi
sembrano tantissimi, e se non cambiano così rapidamente aggiungere /
togliere / modificare qualche colonna di tanto in tanto è molto più
conveniente di portarsi dietro EAV.
Questo ti consente anche di specificare il tipo più giusto per ogni
attributo, invece di usare stringhe ovunque. Le query su un modello
"tradizionale" saranno efficienti (soprattutto se applichi gli indici dove
servono) e facili da produrre, anche via codice (magari usando una libreria
apposita invece di scrivere SQL manualmente, che linguaggio stai usando?).

Nel caso questo passaggio non ti fosse possibile, proverei a esplorare
altri database, non relazionali e quindi più adatti a questi casi, come
MongoDB [3]. Su MongoDB la soluzione al tuo problema diventa triviale.

[1]
https://en.m.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
[2]
https://mikesmithers.wordpress.com/2013/12/22/the-anti-pattern-eavil-database-design/
[3] https://en.m.wikipedia.org/wiki/MongoDB

Ciao,
-- 
Giuseppe Capizzi
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/bglug/attachments/20161105/6a29cf33/attachment.html>