Re: [Gnumed-devel] test-area/sjtan

[Karsten Hilbert]

> > a) get matches from both sources and merge/sort them
> I personally would consider all sources as just one large list (that is,
> there should be no need to name the single lists it consists of, i.e.
> DiagnosisMatchList instead of (ICD-10,UserDefinedDiagnoses)).
> Maybe we need some class to transparently handle a number of sources.
cMatchProvider_SQL already does this if I understand you
correctly. It can handle input from any number of tables (one
field per table) and presents matches as a uniform list.

> Link tables seem to be a reasonable solution, on the other hand we have to
> make sure that the references to the source table never get wrong. 
Foreign keys ?

> One could additionally make a distinction between queries that should run on
> the whole list from the very
> beginning and those that should first search in a reduced set (the
> favourite/known entries) and continue to search on the whole list only after 
> failing
> to find the term in the first set.
That is entirely possible to do by writing an appropriate
match provider provided someone finds a need to and has a use case.

> > (Of course, scores don't make all too much sense with things
> > like streets and urbs, I'd say.)
> Why not ?
Well, I've been thinking of the German scenario. You'd start
out with nearly no streets/urbs in the DB and build up your
tables every time a chip card is read into the system ...
That way one would only have "relevant" data in the tables
anyway. Also, hopefully, a demographic widget asks for the zip
code first-off by means of which the known matching
streets/urbs are reduced *drastically*.

> Or even have a mixture of both. In the latter case, you
> would limit the first set to entries with a *score* higher than a given
> threshold, in which case new streets will automagically show up next time, 
> but you
> will find them at the end of the list because of the low score. That way you
> wont need different lists for "known" and "unknown" streets, you just
> preselect the "known" from the whole list and keep the set to search small.
Now, isn't that pretty much exactly what Richard had in mind
originally ? Common entries bubbling up in the list courtesy
of their high score ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346