Come andresti a creare un algoritmo di ricerca per un CRM?

Potresti dare un'occhiata a Lucene . È scritto in Java ma puoi usarlo da PHP attraverso il suo porto di Zend o Solr , anche se penso che Solr potrebbe non essere una soluzione poiché probabilmente vorrai qualcosa di incorporato nel tuo CMS.

L'idea è che puoi creare un indice da tutti i dati ricercabili e quindi cercare quell'indice. Ha il vantaggio che può essere molto più veloce delle query di database. Puoi anche implementare un sistema di punteggio, in modo che alcuni record vengano visualizzati più in alto nell'elenco dei risultati se sono più pertinenti per l'utente. Un possibile svantaggio è che devi aggiornare l'indice ogni volta che i dati vengono aggiornati.

Se l'approccio Lucene non si adatta al tuo scenario, potresti optare per un mix di codice PHP e database. Una vista o una procedura memorizzata potrebbe agire come un indice surrogato, aggregando i dati ricercabili. Dovresti dividere le stringhe con degli spazi bianchi e questo potrebbe renderlo piuttosto lento, ma ti porterà lì. Il codice PHP sarà responsabile della costruzione della clausola WHERE (puoi dare un'occhiata a come Solr implementa le strategie di query per i suggerimenti come fonte di ispirazione). Supponendo che tu abbia Id , Name e Score come campi indice e due record contatto con Id=1, FirstName="Ric", LastName="Flair" e Id=2, FirstName="Ric", LastName="Flare" i record indice dovrebbero avere un aspetto simile al seguente:

+--------------+-------+
| Id | Name    | Score |
+----+---------+-------+
| 1  | Ric     |   1   |
+----+---------+-------+
| 1  | Flair   |   1   |
+----+---------+-------+
| 2  | Ric     |   1   |
+----+---------+-------+
| 2  | Flare   |   1   |
+----+---------+-------+

Un esempio potrebbe essere simile a questo (SQL Server):

DECLARE @index TABLE (
    Id INT NOT NULL,
    Name NVARCHAR(50) NOT NULL,
    Score INT NOT NULL
)

INSERT INTO @index (Id, Name, Score) VALUES (1, 'Ric', 1)
INSERT INTO @index (Id, Name, Score) VALUES (1, 'Flair', 1)
INSERT INTO @index (Id, Name, Score) VALUES (2, 'Ric', 1)
INSERT INTO @index (Id, Name, Score) VALUES (2, 'Flare', 1)

SELECT
    Id,
    SUM(Score) AS Score
FROM
    @index
WHERE
    Name = 'Ric'
    OR Name = 'Flair'
GROUP BY
    Id
ORDER BY
    Score DESC

Ric Flair avrebbe un punteggio più alto dal momento che coincide con entrambi i valori, quindi scoppiettando prima nei risultati di ricerca.

L'indice potrebbe contenere anche campi titolo e sommario da utilizzare come valori da visualizzare nella pagina dei risultati di ricerca. Oppure puoi unire i risultati con una vista che preseleziona quei valori.

Puoi giocare con le condizioni nella clausola WHERE o con il campo Score (potresti assegnare punteggi diversi a tipi diversi di record o proprietà) per ottenere un'esperienza di ricerca più raffinata.

Vorrei esaminare Elasticsearch .

Elasticsearch è una specie di database di documenti. È un po 'come MongoDB, ma è progettato per ricerche di testo molto sofisticate. Credo che Stack Exchange stessa utilizzi Elasticsearch per la casella di ricerca nella parte superiore della pagina. Fa parte anche di ELK (che sta per Elasticsearch, Logstash e Kibana). È basato su Lucene, ma ha molte funzionalità extra per la ricerca che non vorresti costruirti da solo.

Ho trovato questo pacchetto per l'utilizzo di Elasticsearch da Laravel. Dovrai integrarlo in qualche modo nella tua infrastruttura, ma in cambio otterrai funzionalità di ricerca molto potenti senza molto lavoro extra.

Solr è simile; è anche basato su Lucene e offre potenti funzionalità di ricerca. Ognuna di queste è una buona scelta che è molto più potente di SQL LIKE e più facile da usare rispetto a Lucene direttamente.

Puoi normalizzare i dati per cercare Ric Flair come entità di una persona e poi visualizzare i contatti di questa persona. Questo è un modo di Big CRM ed è adatto se Ric è importante per te, un cliente. Dovresti aspettarti un sofisticato controllo di ricerca per le entità persona tramite molti attributi di dati.

Spesso non vuoi creare una persona ogni volta, ad esempio come contatto alternativo per un ordine. In questo caso non puoi fare molto ma fornire agli operatori schemi chiari e / o istruzioni su come riempire il campo del nome durante l'acquisizione dei dati.

La suddivisione del pattern di ricerca in base agli spazi vuoti naturalmente produrrebbe più risultati, tuttavia suppongo che gli utenti non vorrebbero che non fosse uno schema standard.