Jan Janak pisze:
And if we eventually do something like this, I'd
prefer to do that one
little extra step and implement support for selects, PVs, and AVPs
instead of escape sequences like %1 and %2. The query from your
example might then look like this:
I just thought that simplified parser would be
better than involving
parser for selects and PVs, but i'll not insist on that ;-)
There is no need to store any attributes in the credentials table. You
can get everything with one query from both credentials and user_attrs
There might be a reason from business logic point of view, this may be a
table which is used for number of other purposes (like other services)
and may contain some critical data like "account enabled" and/or
"account locked" (yes i know that this particular example can be
"workarounded" by using database views)
Minimizing the number of queries per SIP message is something I have
had on my todo list for quite a while, including the optimization
above. I have done some private experiments with this stuff and
managed to cut the number of queries down to 2 per SIP message with
MySQL. Those two queries loaded all the attributes, digest
credentials, URIs and contacts from location table.
My personal experience from other areas shows, that sometimes its better
to do more simpler queries than constructing excessive joins, but this
may be subjective view.
[..]
efficiently is a precondition for such optimizations. So right now we
need to agree on the database schema for sip-router.
Ok, so i guess i'm going to shut up (for) now ;-)
Jan.
Grzegorz Stanislawski