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