database suggestions

[bobbymc]

any kind of reference to columns such as campaign_id or user should be done via a int that auto increments.. for example campaign_id should be self generated and people should only be able to choose the campaign name.. this way allot of database transactions will run faster.. im sure u know this already but i thought i jsut remind you guys..


i got some other index and table type suggestions for database performance.. let me know how i can contribute that exacly.. i can provide database schemes?

[mflorell]

You should check out SVN trunk, we've added several indexes recently that help responsiveness of the database.

Please share yours as well.

[bobbymc]

i will go throw my database and try to find any ods that heled out.. here is a first one.. for vicidial_manager

KEY `improve_speed` (`server_ip`,`status`,`action`,`callerid`),
KEY `serverstat` (`server_ip`,`status`)

[bobbymc]

what i also did it change the table type of vicidial_manager to innodb because of high volume traffic causes locks.. i did the same with vicidial_list but in order to still keep the speed efficiency ont he read i had to add this index for the hopper script to work fine

KEY `hopper_index` (`called_since_last_reset`,`status`,`list_id`,`gmt_offset_now`)

[bobbymc]

the downside of making vicidial_list innodb is that sometimes the hoper script takes a bit longer with over 100 campaigns.. so in order to prevent the script from crashing i had to add that hopper code addition in my other post.. this way in case the hopper script for some reason does take longer then a minute to run.. it will not allow itself to run more then 3 instances

i understand 100 campaign is crazy.. but some offices literally want every user to have their own campaign

[mflorell]

Here is an updated post on issues with using Innodb with VICIDIAL:
http://www.eflo.net/VICIDIALforum/viewt ... 6376#26376