mysql 表中字段option_tag 存储的值格式(分号)为: 4:539;8:543;4:545;8:549通过 find_in_set() 可以查找到以逗号分隔的字符串。以分号分隔的 字符串 有什么函数直接能查询到 option 含有 539的所有值?
ringa_lee
SQL ステートメント: SELECT * FROM tableWHERElocate(':539;', CONCAT(options_tag, ';')) > 0
like を使用するロジックは厳密ではありません。たとえば、4:2539 も like と一致しますが、これは望ましい結果ではありません。
設計の観点から、複雑なデータ型の場合は、json 形式で保存することをお勧めします。mysql の上位バージョンには、json 解析関数とクエリ関数が直接組み込まれています。
「いいね!」または「通常のルール」を使用してください。 ただし、mysql にロジックを組み込むことはお勧めできません。データベース エンジンに過剰な負荷がかかり、非常に安全ではありません。 正しいアプローチは、フィールド全体の値を取り出し、それを文字列として使用し、それを処理するために php、python、nodejs などの言語を使用することです。
リーリー
@小蔹哥が言ったように、これは 1 対多または多対多の関係のようです。クエリ効率が低いだけではありません。 (フィールドは SQL で処理されます。この操作により、このフィールドのインデックスが使用できなくなる可能性があります)、クエリは柔軟性がありません。
いいねマッチ
いいね:539
これは設計上の欠陥だと思いますが、同意する人はいますか?
似たようなマッチング
ぼやけたクエリリサーチ
SQL ステートメント:
SELECT * FROM table
WHERElocate(':539;', CONCAT(options_tag, ';')) > 0
like を使用するロジックは厳密ではありません。たとえば、4:2539 も like と一致しますが、これは望ましい結果ではありません。
設計の観点から、複雑なデータ型の場合は、json 形式で保存することをお勧めします。mysql の上位バージョンには、json 解析関数とクエリ関数が直接組み込まれています。
「いいね!」または「通常のルール」を使用してください。
ただし、mysql にロジックを組み込むことはお勧めできません。データベース エンジンに過剰な負荷がかかり、非常に安全ではありません。
正しいアプローチは、フィールド全体の値を取り出し、それを文字列として使用し、それを処理するために php、python、nodejs などの言語を使用することです。
リーリー
@小蔹哥が言ったように、これは 1 対多または多対多の関係のようです。クエリ効率が低いだけではありません。 (フィールドは SQL で処理されます。この操作により、このフィールドのインデックスが使用できなくなる可能性があります)、クエリは柔軟性がありません。
いいねマッチ
いいね:539
これは設計上の欠陥だと思いますが、同意する人はいますか?
似たようなマッチング
ぼやけた
クエリ
リサーチ