「あいまい検索で」と言われたときの絶望感を言語化してくれてる。OFFSETの罠は今でも頻出だしな
良い…
「あいまい検索」の一語がpg_trgmや全文検索エンジンの運用コストまで確定させる構図は、下流制約を上流に引くシフトレフトそのもの。DB選定より先に語彙の合意が要る
ソート条件は1種類のはずが、フロントエンド側でテーブルの列タップでクライアントでソートを安易に実装して見せてしまったばかりに、ページネーションと整合性合わなくなって、バックエンドソート後にページして...
参考になる。ただ、これ真に口出ししないといけないのはシステムの要件かな
「データ量がそんなに多くなければインデックスが効かずとも問題になるケースは少ない」「私はこの「1万件」くらいの規模感であれば、あまり神経質にならなくてよい、という目安として捉えています」
検索画面ってCAP定理みたいに、常に同時には満たせないトレードオフみたいなのがある気がするんだけど、誰かまとめてくれてないかな。早めの設計でトレードオフに気付いてないと後半詰むから
何なら実データ確認して誰がどんな目的で検索するのかまで確認したい。最近作られたデータが99%のユースケースなら、古いデータは遅くなってもさほど問題ないわけで。
個人的にはフロントエンドとバックエンドでチームが分かれているのはチームにも個人にもデメリットが大きいと思う。全部把握している人が要件定義から基本設計までやればいいのに組織的に難しくするのがアレ。
全半角の差分を吸収しろ、スペースあっても無視しろ、こっちは大文字小文字まで見ろ、こっちは大文字小文字の違い吸収しろみたいなのも追加で。
これは走査自体をSQLにやらせる想定の記事で、その他の「検索画面」が置き去りになるな。JavaScriptがフロントで検索する画面もあれば、pythonが担う画面もある。
検索画面のUI設計で、バックエンドエンジニアが早めに口出しすべき3つのこと
「あいまい検索で」と言われたときの絶望感を言語化してくれてる。OFFSETの罠は今でも頻出だしな
良い…
「あいまい検索」の一語がpg_trgmや全文検索エンジンの運用コストまで確定させる構図は、下流制約を上流に引くシフトレフトそのもの。DB選定より先に語彙の合意が要る
ソート条件は1種類のはずが、フロントエンド側でテーブルの列タップでクライアントでソートを安易に実装して見せてしまったばかりに、ページネーションと整合性合わなくなって、バックエンドソート後にページして...
参考になる。ただ、これ真に口出ししないといけないのはシステムの要件かな
「データ量がそんなに多くなければインデックスが効かずとも問題になるケースは少ない」「私はこの「1万件」くらいの規模感であれば、あまり神経質にならなくてよい、という目安として捉えています」
検索画面ってCAP定理みたいに、常に同時には満たせないトレードオフみたいなのがある気がするんだけど、誰かまとめてくれてないかな。早めの設計でトレードオフに気付いてないと後半詰むから
何なら実データ確認して誰がどんな目的で検索するのかまで確認したい。最近作られたデータが99%のユースケースなら、古いデータは遅くなってもさほど問題ないわけで。
個人的にはフロントエンドとバックエンドでチームが分かれているのはチームにも個人にもデメリットが大きいと思う。全部把握している人が要件定義から基本設計までやればいいのに組織的に難しくするのがアレ。
全半角の差分を吸収しろ、スペースあっても無視しろ、こっちは大文字小文字まで見ろ、こっちは大文字小文字の違い吸収しろみたいなのも追加で。
これは走査自体をSQLにやらせる想定の記事で、その他の「検索画面」が置き去りになるな。JavaScriptがフロントで検索する画面もあれば、pythonが担う画面もある。