Sistema di filtraggio inverso SQL

Question

Sistema di filtraggio inverso SQL

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Ci scusiamo per il titolo non descrittivo, non so come spiegare ciò che sto cercando di ottenere in modo sintetico.

Nella maggior parte dei casi di utilizzo di SQL, abbiamo nel database dei record che hanno proprietà e stiamo cercando di recuperare i record che soddisfano alcune condizioni. Ad esempio, potremmo avere ad esempio una tabella di prodotti, in cui ogni prodotto ha una data di rilascio, un prezzo e una categoria. Possiamo quindi facilmente richiedere prodotti rilasciati dopo una certa data, con un prezzo inferiore a un determinato valore e appartenente o non appartenente a una categoria specifica.

Ciò che sto cercando di ottenere è essenzialmente il contrario. Ho una tabella di servizi con condizioni e ogni utente ha varie proprietà. (pensa 'data di nascita', 'ha la patente di guida', ecc ...) Ho bisogno di visualizzare un elenco di tutti i servizi che un dato utente è idoneo.

Un altro dei miei requisiti è che questo deve essere possibile per gli utenti anonimi, quindi i valori delle proprietà per l'utente non verranno archiviati in una tabella, saranno semplicemente forniti come parte della richiesta dell'utente al mio server .

Sto facendo fatica a pensare a quale sarebbe il modo migliore per ottenere questo risultato. Al momento vedo due possibilità principali:

1. Costruisci un modello relazionale per le condizioni e crea lunghe query SQL basate sull'input dell'utente

Affinché un utente possa essere idoneo per un servizio, deve soddisfare almeno un Gruppo di condizioni. Affinché un utente soddisfi un Gruppo di condizioni, deve soddisfare tutte le Condizioni all'interno di quel gruppo.

Pro:

Funziona con un ERD ben definito e query SQL appropriate

Contro:

Devono generare query SQL molto complicate con più join, flessibilità ridotta per le condizioni di scrittura

2. Conserva le condizioni come una stringa. Costruisci un parser delle condizioni e passa attraverso tutti i servizi testando la loro condizione contro l'input dell'utente.

Pro

Condizioni flessibili e più facili da scrivere, più facili da sviluppare

Contro

Le query devono essere eseguite in livello applicazione anziché in livello database, possibilmente con prestazioni non buone

Mi chiedo se qualcuno abbia affrontato un problema simile in passato e come lo abbiano risolto. Forse c'è un'opzione che non sto considerando? Sono aperto a utilizzare una soluzione NoSQL se è più adatta al problema, ma la mia preferenza è quella di farlo su un database SQL se pratico.

design database database-design search filtering

posta Joshua Walsh 27.12.2016 - 16:27

fonte

3 risposte

Leggi altre domande sui tag design database database-design search filtering

Costruttore predefinito e ritorno per puntatore Gestione di bug e storie in JIRA

score 1 · Answer 1

Il mio suggerimento, (se devi farlo in sql) sarebbe dividere le condizioni tabella per campo.

Dato che il campo è strettamente accoppiato alle colonne sulla tabella utente, averlo come stringa ti darà problemi quando lo proverai e lo userai. Una volta in tabelle separate puoi vedere che il problema diventa più facile

select 
    u.id,
    c.id,
    (
    u.age > c.min
    and
    u.age <= c.max
    ) as result
from 
    conditionAge c
left join 
    users u

ripetere per ogni tabella delle condizioni e utilizzare come sottoselezioni per dire quali gruppi sono pienamente soddisfatti.

Tuttavia, questa è una logica aziendale, sarebbe meglio per me recuperare tutte le condizioni e valutarle nel codice piuttosto che tentare di farlo nel livello dati

score 1 · Answer 2

Penso che il livello di applicazione sia l'unico luogo pratico in cui effettuare la valutazione effettiva delle regole. Poiché queste regole diventano più complicate, la modellazione e l'interrogazione completa con SQL possono diventare molto difficili (se non addirittura impossibile).

Per quanto riguarda le prestazioni: non so quanti servizi e regole ci sono. Ma tenerli in una cache mi sembra una soluzione praticabile. In questo modo hai tutta la flessibilità offerta da un linguaggio di programmazione e una buona performance di runtime.

Inoltre, non riguarderei il DB con la reale modellazione delle regole, ma invece userei un buon modello OO e l'ereditarietà a tabella singola.

score 1 · Answer 3

Questa risposta può sembrare un po 'controintuitiva, ma in questo caso potrebbe essere utile una denormalizzazione.

Considerato che ci sarà solo un numero limitato di variabili usate per controllare le condizioni, quello che potresti fare è avere una tabella con tutte le possibili combinazioni di variabili (per data o anno di nascita potresti usare 2 variabili: tra X e Y) e quindi creare una tabella per collegare i servizi disponibili a ciascuna delle combinazioni. Sì, questo può creare un sacco di record nella tabella che contiene le combinazioni, ma non è un problema.

Scrivere l'SQL per questo non è troppo complicato ed è tutto ciò che è necessario.

Il compromesso è mantenere la tabella delle combinazioni. Questo può tuttavia essere meno lavoro di capire come ottenere tutte le condizioni per funzionare correttamente ed efficientemente. La domanda è: quante condizioni / gruppi di condizioni ci sono e quanto spesso cambieranno?