With MySQL, customer resource management is under control_PHP tutorial

MySQL is very suitable for supporting customer resource management (CRM) systems within websites. It has become an integral part of many Web sites, and its price level is unrivaled. In addition, in dynamic websites, there is likely to be a considerable amount of CRM data to be explored.
While working as a SAP implementation team administrator for a telephone company, I gradually became proficient in its excellent CRM toolkit. I learned that about 90% of the work in CRM is system configuration implementation and maintenance to meet the changing requirements of users. A CRM developer must be proficient in process and structure design. Now let's discuss the process you go through when using MySQL to create a scalable, high-performance CRM system.
Designing a CRM solution for MySQL
CRM databases are complex: your user form is linked to your contact form, which in turn is linked to your address and organization forms, which are in turn Links to your transaction table, which in turn links to your catalog table, and so on. For some relationships, you need to create complex composite indexes. For other relationships, you may only need simple indexes, or not at all. Updates and deletes in your implementation may or may not be cascaded.
This means that you need to be extremely familiar with the tuning methods available in MySQL. But before you can make adjustments, you need to design a CRM process that takes advantage of these adjustments.
Logic and Data Flow
As you can see in Figure A, you can use MyISAM tables as a source of report type data. This is very useful because ISAM tables are a lightning-fast data source when you are simply querying the database. The disadvantage of ISAM is that the table file itself may crash, and updates to its data can easily cause such problems.

Figure A

Data flow of CRM design

To solve the instability of ISAM, you can use InnoDB tables to add, update and delete Records in the data table. The InnoDB engine is transactional, so if an update fails, the data is returned to the state before the change. InnoDB is more complete in reference, so that data updates will not violate any relationship rules between tables.
What the chart above doesn’t reflect is that you should always back up your data. In this case, all the data stored in the ISAM table is valuable. These tables are things you should back up. You can get the same data in an InnoDB table, but ISAM tables are more suitable for queries during backup processes.
Restore operations on InnoDB tables are done for the same reason - they are more suitable for updates (e.g. referential integrity, speed, stability, etc.), and they will be automatically updated with any pending additions/updates Operations are synchronized. If the InnoDB table unfortunately crashes, the ISAM data can be used to rebuild the table, which is why it's best to split the process up like this. After all, redundancy equals safety.

http://www.bkjia.com/PHPjc/631129.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/631129.htmlTechArticleMySQL is very suitable for supporting customer resource management (CRM) systems within websites. It has become an integral part of many Web sites, and its price level...