|
|
Re: PROLOG ENGINES ARE REALLLLLLY SLOW! ((SQL-UNIFY))
Posted:
Nov 20, 2012 3:16 PM
|
|
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.
Herc
|
|
