On Nov 21, 1:46 am, Jan Burse <janbu...@fastmail.fm> wrote: > Graham Cooper schrieb: > > A lot of variable renaming conventions, trial and error, > > backtracking... very tricky and particular code covering > > dozens of potential matching scenerios! > > Already efficiently solved to some extend in the 70's. Have > a read about the early childhood of Prolog systems: > > La naissance de Prolog > Juillet 1992, A. Colmerauer, P. Rousselhttp://prolog.developpez.com/tutoriels/alain-colmerauer/histoire-prol... > > > Slight drawback is program order is lost using the fastest match > > method, but PROLOG is overused as a simple FETCH cycle for 3GL style > > coding. > > Add an additional sorting column, and you can preserve the input order. > Any Prolog system implementing multi-argument indexing has also to > solve this problem, in that the index lookup bust deliver a clause set > which is actually a clause list ordered by the input order. > > Bye
SQL-UNIFY SELECT * FROM TTAILS, TPRO WHERE TTAILS.REF = TPRO.REF AND TTAILS.FIELD = TPRO.FIELD GROUP BY COUNT(TPRO.ID) ORDER BY COUNT(TPRO.ID) DESC
Right, actually I think the GROUP BY would be inefficient and only do Breadth First, i.e. calculate the whole table then sort, although it would find the best rule (most terms matched 1st).
SQL-UNIFY SELECT * FROM TTAILS, TPRO WHERE TTAILS.REF = TPRO.REF AND TTAILS.FIELD = TPRO.FIELD ORDER BY TPRO.ID
This will preserve program order and be LAZY Evaluation so PHP can test the 1st match 1st then fetch more records from this result if needed.