Explain the importance of B-end product database design from the product and business level.

Editor’s note: This article is from WeChat public account “SaaS product said”, author Li Donglin, authorized to reprint.

Today, let’s talk about the business modeling and database design of B-end products. How important is the database design of B-end products? How to say it, If the product positioning determines whether there is a market for a product, then the design of the database often determines how far the product can go. The design rationality of the database is the best for a product. One of the important indicators. There have been a lot of technical articles about database design steps and specifications, and today I explain more about the importance of products and business.

Some of the product technicians who have transitioned from the C-side to the B-end may not agree, is database design so important? In fact, the rationality of B-end product database design is much more important than the rationality of C-end product database design. C-side products generally have relatively simple business, low coupling between data, and many support with non-relational data. The design of the database is relatively simple. Even if the previous design is not appropriate, the problem of adjustment in the later stage will have little effect. The B-end products, the business is complex, the data relationship is also connected, generally using a relational database to support, designing a database structure of a complex B-end product, the difficulty is not small.

What are the common mistakes and what are the consequences of database design? I’m here to explain a few common non-technical issues:

1: A large number of redundant fields are placed in the data table.

When the TO C product was designed, we avoided reading the information in the associated table for the data reading speed. A large number of redundant fields were placed in the table. In the TO B scenario, the amount of data is often inferior to that of TO C. In most cases, performance does not become a bottleneck. If many redundant fields are placed, the coupling of the back-end logic is extremely high, and subsequent scalability and maintenance Extremely high cost (B-end products are extremely critical because of the complexity of the business, scalability and maintainability). The redundant fields mentioned here mainly contain two categories:

  • The first type is the attribute field of the business object, which is maintained as basic data. If these attribute fields are redundant in multiple places, resulting in basic data updates, you need to update a large amount of data in other tables.

  • OneClasses are fields that can be computed by other fields. If set to a redundant field, this will cause the redundant field to be updated whenever the field participating in the calculation changes.

2: The object associated with the attribute field is incorrect.

Associate with the object of the attribute field needs to be considered repeatedly. For example, in ERP, common objects are goods, customers, orders, inventory, etc. Which business object is the most suitable for which attribute field? Whether you need to abstract new objects to place attribute fields, one of the principles of measuring various schemes here is that see which scheme can ultimately minimize the amount of integrated data, which is generally the best solution.

3: One-to-one, one-to-many, many-to-many relationship between objects.

If the correspondence is wrong, after the customer has gone online, it will be adjusted afterwards. It involves the data migration of the old customers, which is extremely painful. Common, for example, the correspondence between users and roles, if the user role has a one-to-one relationship in the early stage,

In a complex business system, when user permissions are complex, it is likely that eventually a large number of roles need to be set to meet the user’s functional permissions. If you allow a one-to-many relationship, you only need to configure a few basic roles that can be combined into all user permissions.

4: Feel free to add fields.

The pattern that is often seen is that the demanding staff will give the developer after receiving the demand, saying that I need a function, and then the developer considers the implementation, and adds a few fields at will. Should this function be done? (For the judgment of function priority, please refer to the previous article “How to define the MVP of the B-side product”< /a>)? What should be the best solution? How is the database compatible with future business? These contents have not been considered, so continuous research and development for many years, farther away from a good product.

There is a principle here to note that the database should not be arbitrarily increasing the number of fields, and the increase of each field or table should be extremely cautious, because for the product, adding fields is easy, for the old Version compatibility is no problem. But if you add a field, it’s very difficult to remove or adjust it later. The workload here includes the migration of user data, andThe original logic involves the part of the field that needs to be adjusted.

In addition, for SaaS products, some basic data, such as cities, account types, countries, and some countries, local regulations and other rules or parameters, such data should not be made into customer-linked data, try to do The basic data table across customers, the benefits of this, First, the data can be unified, it is extremely convenient in the future statistics, the second is that if you need to update, one-time update can be done, do not need a customer to go Update.

The improper design of the database will often lead to the subsequent use of a data structure to support multiple business situations in the face of new business. If multiple product versions are generated, it will be worse. , will have the following consequences:

1: Maintaining multiple product versions is costly. If you want a unified version involving data migration, user education, etc., it is very difficult.

2: Now we are working hard to explore the value of customer data. If the database is not uniform, it is very difficult to do cross-customer data analysis or statistics.

3: It is difficult to establish a standard interface with an external third party.

4: The flow of people has caused no one to know what the old version is, except for the latest version.

5: The old user experience is poor and the word of mouth is difficult to maintain. The operation department encounters great difficulty in customer service, and the user’s wastage rate will increase greatly.

…….

The combined results of these situations, The more customers on the line, the more the products will not move, the rest of the R&D force can only be maintained, and minor repairs. Of course, such a team continues to do large-scale product development, which is not appropriate. If you have already faced such a situation, how should you deal with it, and then we will write the corresponding article for analysis.

The last thing to say is that many companies’ database designs are now placed on the general development below. For such core content, it is recommended that the best people be like Data Architect. If there is no similar ability role, the database design should often be composed of architects, core developers, product managers and other groups to periodically discuss and check.

Author: Li Donglin (micro-channel public number: SaaS product say; Micro Signal: jianguzhuxin), former head of ADP products in Greater China, 14-year To B R & D and product design, team management experience, leading through a variety of large-scale business management Software design, research and development, online, also have 2 years of mobile Internet TO C entrepreneurial experience, to the friends, welcome to add me WeChat communication.