Tagged: directory database tables

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • December 31, 2014 at 3:30 pm #3767
    philmay
    Member

    you guys say it is possible to create multiple directories with BePro, ie businesses, vehicles, real estate etc on one single install. That raises a question, does this also mean that each separate directory has its own database tables? It would be fantastic if so. I currently have almost 300k business listings on my site and I want to add another state but the current plugin i use will just add the new cloned directory for the second state to the same tables causing massive lag in bulk listing importing. Right now i import csv files of 5000 businesses and it takes hours for wordpress to finish the import even with range partitioned innodb tables. We are looking to solve that problem with a directory plugin that will allow us to import new states to dedicated tables.

    December 31, 2014 at 4:12 pm #3768
    BePro Software Team
    Keymaster

    Hi,

    Thanks for considering BePro Listings.

    We believe that your issue is exactly why we designed BePro Listings. The short answer is yes, we do store the various directory types in different tables, when you use an addon. At the same time, I must be pellucid, there are some reuse of tables with each and every save.

    Let me explain further. BePro Listings in its stock form has its own table “A”. The real estate addon will create its own table B. The vehicles addon will create its own table C. Now note, with each and every save, table A is involved. It holds some basic info necessary for the free plugin. More importantly, it stores relational info that we need for all features to have a central place to look. The perk of this approach, is that we reduce (eliminate) redundant tables.

    We also store some base info with wordpress itself. Images, title, categories and anything else thats native to wordpress is stored by them. I mention this because wordpress itself would probably be a bottleneck before BePro Listings. For example, one category relation is stored between 3 different tables. This deep storage for one single field is also the reason we use very few custom post types or custom fields. These things degrade performance, especially when you combine them and we eliminate them for our search data

    The form builder also has its own table. It will capture everything as a json string. We are working on ways to refine this, seeing that its redundant bulk storage. Its a quick fix that we would be happy to implement if you choose the BePro Listings platform

    Our goal is to perform at a steady realistic rate as records and visitor requests increase. We did an article about how we gauge our performance and would love to hear your teams analysis

    – https://www.beprosoftware.com/documentation/architecture-built-to-scale/

    Ultimately, being bias, we definitely believe that our approach will scale better than anything else on wordpress. In fact, we humbly believe that wordpress will be the bottleneck before BePro Listings. Although most of our small customers will never notice, we specifically designed BePro Listings large data sets in mind.
    ___
    BePro Software Team

  • Author
    Posts
Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.