プログラマーに外注している依頼者なのですが、

データベースのつくりにもよりますが

条件に対しスコアを付けてやるなどで可能だと思います。

「不可能」「簡単です」「絶対」という言葉が出てくると

信用ならないな、と思います

できない理由を明確にした方が良いと思います。

その上で他の人を探すなり、予算を上げるなりするしかないのではないでしょうか。

お金と時間を掛ければなんでもできます。

今時のワンチップマイコンだって30年前の大型汎用機よりも処理速度は速いのですから。

仕様を見る限りできないことはないですね。現実的な動作速度でということも問題ないと考えます。

おそらく、そのプログラマのスキルというか「面倒」という空気が伝わってきますね。

私は、仕事の上では「不可能」という言葉は絶対に使いません。

やり方は多々あると思いますが，たとえばこんな言い方をすれば（まともなプログラマなら）作れると思います．

出力するデータは，以下の比較関数を用いて昇順にソートしてください（a, b は比較関数の入力とします）．

・a と b がそれぞれ第1条件を満たすかどうかを検査する．

　- a だけが条件を満たし，b が満たさないなら a < b を表す値を返す．

　- 逆なら a > b を表す値を返す．

　- それ以外（両方とも検査結果が同じ）なら，第2条件について同じ検査を行う．

・第2条件でも検査結果が同じなら次は第3条件について検査し，それでも同じなら第4条件…と，条件の数だけ検査を繰り返す．

・すべての条件について検査結果が同じであれば，a = b を表す値を返す．

これでおそらくお望みの出力が得られるとは思いますが，質問者の方のイメージ通りにぴったり合うかどうかは，上記のアルゴリズムをプログラマの方に見てもらって確認してみてください．

技術的にできないということはないと思います。

仮説１：速度的に不可能か？

どのようなデータの検索でしょうか？

データが大量であり、かつ、更新が非常に頻繁であり、順位が大きく常に変動するようなデータであれば、難しいです。しかし、そうでなければ、ある程度の落としどころを提案するのも技術者の仕事と思っています。

例えばですが、事前にソートの参考になる情報を計算しておくなどすると、完全に最新のデータとは異なるが、ほぼ最新の結果を返す仕様でも問題なければ、工夫しようはいくらでもあります。

仮説２：契約的なものか？

納期、工数、金額で無理というのはあり得るかと思います。

仮説３：曖昧な動作か？

こちらは可能性としては、高いかもしれません。

条件が、A、B、Cと合ったときに、Aの適合度、Bの適合度、Cの適合度はそれぞれ関係ありません。

この複数条件でのまとめ方をどうするかに矛盾がないようにしなければなりません。

例えばですが、A、B、Cとして、幅、高さ、重さといった条件を考えてみてください。

幅と、高さについては、単位が同じと考えられますので、検索条件の値との差の合計でソートしてあげることは可能です。では、重さは同組み合わせればよいでしょうか？幅と高さの差の合計（m)+重さの差（Kg)と単純に足した値でソートしてよいのか、重さになんらかの値をかけて合計するのか、など考えられることはいろいろあります。

また、1,・・・,nから選択するようなものを参考リンクではあげていましたが、条件として、5番目と入力した場合には、幅や高さのように単純に差を表現できないものもありますよね？

感覚的な評価で、「非常によい」、「よい」、「普通」、「悪い」、「非常に悪い」のようなものでソートしようとすると、入力で普通を指定した際に、普通にどれだけ近いというのを計算できるようにしなければなりません。

とはいえ、この条件を依頼主のtomo54さんが詳細につめる必要はないと思っています。

具体例などを色々しめしてあげて、頼んでいるプログラマーに条件をつめさせるのが普通だと思います。

で、結論としては、コミュニケーション不足で、お互いにやりたいことを伝えられていないのではないでしょうか？

契約的なもので難しいのであっても、フェーズ分けをするなど対応のしようはあると思います。

長文、失礼しました。

そのような機能はできなくはないが、現実的な動作速度で動かすことは難しいのではと考えます。

おそらく、何らかのデータベースからデータを取得することとなりますが内部的にはデータベースにある全件にたいして選択した条件でソートした上で1ページ目だったら1-10件目を表示というプロセスになるために1回表示するごとにすべてのデータを走査することになります。

これが数百程度の件数だったらよいのですが数千、数万となるとデータベースとしての負荷も大変高いといえますし、なにより最後まで探すことなどあり得ないのではないでしょうか。

負荷の点でしたら数百件レベルなら何とかなるでしょう。

二つ目にソートキーとして「勤務曜日・時間で選ぶ」「勤務先の会社や働く環境で選ぶ」「勤務先の特徴」という3つの項目に対して複数選択が可能になっているところに注目しました。

並び替え条件でなく検索条件としてでしたらSQL的には「in」という構文で可能なんですが並び替え条件とするには何らかの順番付けできるものに置き換えてやらなければなりません。

たとえば、数字などでしたら大きい順、小さい順に並べ替えてあげることは造作もないことです。ただ、今回の場合はそうではないので、内部的に数字に置き換えてあげなければなりません。たとえば、チェックが入っていたものを「1」入ってないものを「9」などに置き換えてその数字で小さい順に並び替えてあげることで実現しますが、項目数が多いことと複数選択可能であるということでそのロジックがかなり複雑になるかと思います。

まず、SQL自体がかなりの長さになる上、SQL自体が動的に変化する形となりますのでテストにもかなり手間がかかります。

自分の結論としてはデータ件数が少なければ可能であると思うが、これだけの機能を実現するとなるとそれなりの工数が必要＝お金が必要であると思う。

ただ、使用している言語とかフレームワークによってはその縛りによって不可能なのかもしれない。

（この予算じゃ）できない

（この納期じゃ）できない

（こんなあいまいな仕様じゃ）できない

（私のスキルじゃ）できない

ってことではないでしょうか