@dericdd said:
Well the discussion thread is a clear example of needing multiple queries at a time. If we have 20-30 comments and we query them one at a time it takes forever. So at the beginning of the discussion thread we tie into "discussionController_beforeDiscussionDisplay_Handler" hook to pre-query all the IPs from the discussion and comments. Then we use the "base_authorInfo_Handler" to display flag using pre-loaded geoip info.
Of course, that would take ages if you do it every time the page loads.
You made a good point that we should perhaps record the geoIP data while posting discussion/comment.
This is the key: I assumed it was already done that way! Post -> Record IP -> Store data -> Show it next time. For this process, the standard library works perfectly, it's a single, once-off lookup.
@businessdad Why would i use the standalone binary now that I have all that data loading automatically into a MySQL table? Querying from a database is really not as tough as you make it out to be. Perhaps read that part of my code and you will see how easy it is.
I never said that you should change what you have done. I just pointed out that, based on how I envisioned a solution (which, as I explained, is different from your approach), the standalone binary would have been sufficient. Now that you have your code in place, it's a good idea to keep it.
As for the "querying from the database" part, x00 called me "the SQL guy" for a reason. I've been a DBA for longer than I like to think, and I know the advantages and disadvantages of delegating some type of tasks to the database servers.
@dericdd said:
I understand... Been at this for 15+ years as well, lol. Remember portability and having it work on old data were main concerns.
Very often they still are. So far, most of the projects I worked on required a solution that could work with any RDBMS. The funniest moment I had was to develop a brand new version of an application, from scratch and improve its performance (the original one took one second to show the details of a single customer. If a page contained 50 customers, it took almost a minute to render). The requirements were:
Comments
Of course, that would take ages if you do it every time the page loads.
This is the key: I assumed it was already done that way! Post -> Record IP -> Store data -> Show it next time. For this process, the standard library works perfectly, it's a single, once-off lookup.
My shop | About Me
@businessdad Why would i use the standalone binary now that I have all that data loading automatically into a MySQL table? Querying from a database is really not as tough as you make it out to be. Perhaps read that part of my code and you will see how easy it is.
I never said that you should change what you have done. I just pointed out that, based on how I envisioned a solution (which, as I explained, is different from your approach), the standalone binary would have been sufficient. Now that you have your code in place, it's a good idea to keep it.
As for the "querying from the database" part, x00 called me "the SQL guy" for a reason.
I've been a DBA for longer than I like to think, and I know the advantages and disadvantages of delegating some type of tasks to the database servers.
My shop | About Me
I understand... Been at this for 15+ years as well, lol. Remember portability and having it work on old data were main concerns.
Very often they still are. So far, most of the projects I worked on required a solution that could work with any RDBMS. The funniest moment I had was to develop a brand new version of an application, from scratch and improve its performance (the original one took one second to show the details of a single customer. If a page contained 50 customers, it took almost a minute to render). The requirements were:
This was 2009, they are still working on it.
My shop | About Me
Yeah I have had those issues, lol.