Time-sufixed tables complex search about homer-api HOT 5 CLOSED

Another solution is to change DB design from "large, flat table with TEXT(call-id,tags,from/to users) searches on it", to a set of tables, reflecting possible search criteria. The purpose of this is to substitute "text search" with "integer JOINING" and subset of special, optimized, criteria dependent queries. It will make more complex WRITE operation, but will make "lighter" READing.

from homer-api.

yes, this can be bad for "NORMAL DB" operation, but here we are talking about calls/registrations transactions. So, how it works in the real life:

1. NOC has a ticket: calls or registrations doesn't work.
   2.
   a. NOC checks calls OR registrations ( first logical sharding) + time range (second logical sharding)
   or
   b. NOC can search in all transactions(call, registrations, rest) for specific the time range (logical sharding) + user id (RURI, FROM, PAI) (index scope)

in the both cases the result will be smaller than this limit and will absolutely compatible with "NOC's logic"

create temporally mysql's table and do order/limit inside make for me no sense, because much quicker and better manipulate with results inside php: concatenate results and do sorting (we do usort already). This is also correct way for multiple DB nodes.

maximum that we can do, it's create special API call and do inside aggregation for each transaction with original limit, sort it and return limited data.

from homer-api.

Ok, thanks. Now I see and will assume "NOC logic" as a basement.
It seems to me, that I am to implement a solution with "aggregation and sorting inside of PHP scripts" to match user's expectations.

BTW: I think, it would be great to release a document with "NOC logic" description in git repo to prevent such questions in future. A simple "How to".

from homer-api.

sure, we will do it asap, please don't hesitate contact me in gtalk :-) we can also discuss there.

from homer-api.

Ok. See you there.

from homer-api.