検索画面のUI設計で、バックエンドエンジニアが早めに口出しすべき3つのこと

会議の場で「あいまい検索でお願いします」「部分一致でお願いします」という言葉だけが飛び交うことがよくありますが、この4つのどれを指しているかで、実装コストが変わります。 完全一致・前方一致であればRDBのB-treeインデックスがそのまま使えますが、後方一致・部分一致はLIKE '%〇〇%'の形になり、インデックスが効ききません。 ただ、データ量がそんなに多くなければインデックスが効かずとも問題になるケースは少ないです。『達人に学ぶDB設計』でも、データ量が1万件を超えない程度ならインデックス検索でもスキャンと比較してもそれほど速くないだろうと書かれています。私はこの「1万件」くらいの規模感であれば、あまり神経質にならなくてよい、という目安として捉えています。 なので、バックエンドエンジニアが顧客のデータ量がどのくらいかを質問して把握するなどして、要件に口出ししたりしなかったりするのが良い

[civicpg]

ソート条件は1種類のはずが、フロントエンド側でテーブルの列タップでクライアントでソートを安易に実装して見せてしまったばかりに、ページネーションと整合性合わなくなって、バックエンドソート後にページして...

[momonga_dash]

検索画面ってCAP定理みたいに、常に同時には満たせないトレードオフみたいなのがある気がするんだけど、誰かまとめてくれてないかな。早めの設計でトレードオフに気付いてないと後半詰むから

[simplememofast]

「あいまい検索」の一語がpg_trgmや全文検索エンジンの運用コストまで確定させる構図は、下流制約を上流に引くシフトレフトそのもの。DB選定より先に語彙の合意が要る

[nil0303]

全半角の差分を吸収しろ、スペースあっても無視しろ、こっちは大文字小文字まで見ろ、こっちは大文字小文字の違い吸収しろみたいなのも追加で。

[jukuringo]

調べてみたら全然使われてなかったり、一部ユーザーが使いだしたらいきなり障害の火種になったりとかあるあるなので気をつけたい。

[pchatsu]

via https://x.com/mconfjp/status/2079566445118472580

[bopperjp]

マジ重要。誰か部分一致の検索がなんで全文検索エンジンだと速くできるのか教えて。。

[repon]

営業「という感じで契約取れましたので！なるはやでヨロです！！」みたいなのは止めようがないね……で自分の名刺に「伝説の営業」とか書く。CDD

[yarumato]

“会議の場で「あいまい検索でお願いします」「並び替えはとりあえず全部」という言葉が飛び交う。検索方式は4種類のどれか、ページネーションはオフセット型かカーソル型、総件数表示は正確か、並び替え項目の数”

[spray_donuts_3co]

これは走査自体をSQLにやらせる想定の記事で、その他の「検索画面」が置き去りになるな。JavaScriptがフロントで検索する画面もあれば、pythonが担う画面もある。

[strawberryhunter]

個人的にはフロントエンドとバックエンドでチームが分かれているのはチームにも個人にもデメリットが大きいと思う。全部把握している人が要件定義から基本設計までやればいいのに組織的に難しくするのがアレ。

[n_231]

何なら実データ確認して誰がどんな目的で検索するのかまで確認したい。最近作られたデータが99%のユースケースなら、古いデータは遅くなってもさほど問題ないわけで。

[nilab]

「データ量がそんなに多くなければインデックスが効かずとも問題になるケースは少ない」「私はこの「1万件」くらいの規模感であれば、あまり神経質にならなくてよい、という目安として捉えています」

[himanahitodesukun]

参考になる。ただ、これ真に口出ししないといけないのはシステムの要件かな

[fuji_haruka]

良い…

[nguyen-oi]

「あいまい検索で」と言われたときの絶望感を言語化してくれてる。OFFSETの罠は今でも頻出だしな