sql statement: SELECT * FROM table WHERE locate(':539;', CONCAT(options_tag, ';')) > 0
The logic of using like is not rigorous. For example, 4:2539 will also be matched by like, but it is not the desired result.
From the design perspective, if it is a complex data type, it is recommended to save it in json format. The higher version of mysql directly has built-in json parsing and query functions.
Just use like or regular rules. However, it is not recommended to put logic in mysql, which will cause excessive pressure on the database engine and is extremely unsafe. The correct approach should be to take out the value of the entire field, use it as a string and then use a language such as php python nodejs to process it.
SELECT * FROM table
WHERE options_tag LIKE '%539%';
As @小草哥 said, this is a design flaw. This seems to be a one-to-many or many-to-many relationship. It should not be stored in a field. Not only is the query efficiency low (the field is processed in SQL The operation may make the index of this field unusable), and the query is not flexible.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
sql statement:
SELECT * FROM table
WHERE locate(':539;', CONCAT(options_tag, ';')) > 0
The logic of using like is not rigorous. For example, 4:2539 will also be matched by like, but it is not the desired result.
From the design perspective, if it is a complex data type, it is recommended to save it in json format. The higher version of mysql directly has built-in json parsing and query functions.
Just use like or regular rules.
However, it is not recommended to put logic in mysql, which will cause excessive pressure on the database engine and is extremely unsafe.
The correct approach should be to take out the value of the entire field, use it as a string and then use a language such as php python nodejs to process it.
As @小草哥 said, this is a design flaw. This seems to be a one-to-many or many-to-many relationship. It should not be stored in a field. Not only is the query efficiency low (the field is processed in SQL The operation may make the index of this field unusable), and the query is not flexible.
like match
like :539
I say this is a design flaw, does anyone agree?
like similar matching
Blurry
Query
Research