➗ 🧑🏽‍🤝‍🧑🏼 🌍 SQL Olympiadはどうやってやったのですか（終了） ⬆️ 🧙🏿 👼🏽

SQLでどのようにオリンピックを行ったかの話を続けます。これは前の記事の続きであり、すべてが単純に適合しませんでした。

前シリーズの概要：2016年12月と2017年3月にオリンピアードの2つの通信ラウンドがそれぞれ行われ、勝利の申請者はOracleデータベースでSQLを使用する理論と実践の両方で厳しい選択を通過しました。さらに、第3ラウンドについては、2017年6月上旬のソチオリンピックのフルタイム決勝です。

免責事項 念のために、私は自分の役割を繰り返します。そうでない場合は、記事の最初の部分の後、一部の人にはそれほど明白ではないことが判明しました。私自身、このオリンピアードの主催者ではありません。イベントの告知と広告、スポンサーの検索、大学との連携、オフラインでのイベントの開催-これらはすべて他の人によって行われました。私たちの会社はスポンサーであり、オリンピックでいくつかのコンテストを準備していました。個人的には、SQLコンペティションの技術（そして技術のみ）の部分を準備していました。つまり、彼はステージを実施するためのルールを準備し、タスクを準備してチェックしました。それほど多くはないように思えますが、一方で、他のすべてが実際に行われるのはまさにそれです。だから私も恥ずかしがり屋ではありません。

これが何であるかを明確にするために、公式ウェブサイトで 2016/17オリンピックの決勝戦に関するレポートを以下に示します。

オリンピアードのサイトからフォトアルバムへのリンク。それ以外の場所で見つけることは、どういうわけか明らかではありません。

第3ラウンド、対面の決勝戦、ソチ2017年6月

主催者は私たちとソチの参加者を決勝に招待しました。悪い場所ではありません。当初は5月末に計画されていましたが、学校での卒業式パーティーの大規模な祝賀会は、イベントの開催に困難をもたらしました。私は6月1日に1週間移動しなければなりませんでした。

しかし、まず最初に。まず、準備について。

仕事の準備

最初のラウンドのレイアウトは次のとおりでした。最初のラウンドは理論的には厳しいテストフィルターであり、2番目は魔法の問題解決の練習であり、3番目は電撃戦でした。対面モードでは、参加者は問題を実際の非常に限られた時間で解決する必要があるため、これは大打撃になります。そして、電撃は確かに最高のプログラマーを決定する最良の方法ではありません。そして、「最高ではない」-これはまだ穏やかに言われています。しかし、彼らはそれ以上のものを思い付くことができませんでした。

しばらくの間、何らかの決まったアイデアを考え出そうとしていました。これは決勝全体に捧げられ、解決された各問題は参加者を前進させ、新しいタスクを開き、これらのタスクの数は既に解決されたそれぞれで増加しますが、アイデアは決して現実のものに形を整えました。尾をつかまえられませんでした。

時間が不足し、そのようなスキームで停止しました。すべてのタスクはデータベースで暗号化されます。各問題の解決策により、チェーンに沿って次のタスクなどを解読できます。そうすれば、すべてが簡単になります。他の誰もが勝ったよりも先に動く人。 2つのタスクが同じくらい遠くまで進んだ場合、最初に勝った方が勝ちました。タスクの復号化は保存された関数になり、同時に呼び出しが記録されました。これにより、状況をリアルタイムで監視することができました。また、復号化機能は特別に計算が複雑になったため、1回の起動で数秒間動作しました。これは、徹底的な検索によって問題を解決する可能性を排除するためです。また、これらの非常に検索オプションの準備されたデータで、もしあれば、十分であることを確認しました。

決勝戦のこのスキームには、多くの否定できない利点があります。まず、結果をリアルタイムで監視できます。第二に、すべての参加者は絶対に平等な状況にあり、控訴の理由はありません。主な欠点は、これらの同じ利点から正確に続きます-突然脳が「詰まって」、ソリューションが停止した場合、それ以上の方法はありません。電撃戦では、これは確かにそれほど健康的ではありません。なぜなら、それは迷惑であり、すべての参加者が何らかの形でこれに直面するからです。私は、そのようなタスクに決して「行き詰まる」ことのない人を想像することさえできません。

しかし、私は本当にそのようなフォーマットを試してみたかったです。選択肢は明確です。タスク、それぞれのポイント、結果の自動検証-獲得したポイントを最も多く獲得した人。私はこのアプローチが好きではありませんが、それも明らかです-最終結果のタスク（ポイント）の重みのバランスをとります。見逃すのは非常に簡単で、結果は突然不公平になる可能性があります。そして、これらの重みをデバッグする機会はありません。これが唯一のフィナーレです。もう一度オリンピックを開催する場合、私はまだ最高だと思います。今では経験があります。

そのため、アプローチを決定したら、タスクを準備する必要があります。繰り返しになりますが、私はそれを言葉で表現するために、オリンピアード以外のタスクを持ちたいと考えました。つまり、彼らのソリューションは、数論、特別なアルゴリズム、またはそのようなものに関する特別な知識を必要とすべきではありません。私はそれぞれの問題を解決したかったので、条件を実現し、特定の問題なくソリューションと実装を表現する宣言的な方法を想像する必要がありました。さて、第2ラウンドのタスクのように見えるのは、単純です。 2番目のラウンドでは、問題を解決するための目標時間は1日で、3番目の時間は30分でした。タスクの結果として、発明することは非常に困難でした。このバランスのためだけに、決定するのはそれほど難しくありませんが、それも重要です。タスクで正しい結果を得るために必要な機能を忘れないでください。天井から答えを書いたとしても、解決策は勝手に装飾することができます。解決方法はどこでも制御せず、タスクのみをコンパイルしたため、SQLで最も簡単に解決できました。

退屈しないように、キャンペーンタスクでOracleデータベースの興味深い語彙オブジェクトを参加者に紹介しました。知らない人のために、現代のデータベースには、データベースの内容に関するすべてのメタ情報を含む辞書があります。データベースに含まれるテーブル、フィールド、手順、機能、その他の多くの有用な情報を今すぐどのようにデータベースで起こっています。同じ理由で、より楽しくするために、テキストはグレゴリー・オスターのスタイルで設計されました。

これが何が起こったのかです。各タスクの終了時のトピックの表示は条件の一部ではありませんでした。これらは作業メモであり、ここでは関連しています。

決勝チャレンジ

タスク0（スタブ）

人生、宇宙、そしてすべてに関する最も重要な質問への答えは、次のタスクを解読するための鍵です。

回答：42

解決策：この問題の解決には時間がかかりすぎ（約750万年）、答えを知る必要があります。

タスク1

管理者データベースにテーブルを簡単に作成しました。彼はそれが好きで、別のものを作成しました。そしてさらに400回。彼が後で述べたように、テーブルはすべて異なっていましたが、そのうちの2つは完全に少し似ていて、1つのフィールドの名前のみが異なっていました。検索して、Vasyaによって作成された2つのテーブルがあり、1つのフィールド名が正確に異なる。次から次へのタスクをデコードするためのキーは、辞書式の順序で次々に書き込まれたテーブルの名前です。

ヒント：DBA_TAB_COLUMNSシステムビューを使用します。テーブルベイスンはVPOUPKINEスキーマにあります。

トピック：辞書（DBA_TAB_COLUMNS）、サブクエリ、集計

タスク2

Vasyaがテーブルを作成した後、ユーザーKlavaはテーブルに記入し始めました。そして、前のタスクの1つの表にいくつかの非常に重要なデータを入力しました。しかし、ある時点で、彼女は同僚との会話に気を取られ、プログラムウィンドウを機械的に閉じて、データを入力した記録を失いました。彼女が最後に思い出したのは、このレコードのフィールドの1つがフィールドの名前に一致する行で埋められていたことです。管理者Vasyaは、この記録をクラウディアに見つけ、彼女の努力を続けるのを助けました。

前のタスクへの回答からテーブル内で、フィールドの1つ（誰も知らない）の値がフィールド名に一致する行を見つける必要があります。次々に書き込まれるこのフィールドの名前とこのレコードのROWIDは、次のタスクを復号化するためのキーです。ヒント：DBA_TAB_COLUMNSビューを使用します。

トピック：辞書（DBA_TAB_COLUMNS）、他のクエリでクエリを生成する機能

タスク3。

前の問題を解決したVasyaは、それについて考えました。 2時間後、彼は精神的なcoogg-fuを知っており、任意のテーブルの任意のフィールドで任意の値を探すのに費用がかからないという考えに気付きました。そしてさらに。たとえば、途中で数値フィールドを追加できます。彼はとても興奮し、汗をかきました。そして、Vasyaは、すべての数値フィールドの合計が12345であるテーブルを検索することにしました。そして、そのようなテーブルが見つかりました！この行のROWIDは、次のジョブを復号化するためのキーです。

トピック：辞書（DBA_TAB_COLUMNS）、他のクエリでクエリを生成する機能

タスク4。

ヴァシリーがテーブルを駆け巡る中、彼の同僚のゼニア・スミスはひそかにそろばんとシェヘラザードで基地を作ることにしました。まず、Vasyaをきっかけに、彼はテーブルを1,000回作成することを黙想しました。次に、次に何をすべきかを考えました。トランスのヴァシンの声から彼を引き出した：

-そして、これらの2つのテーブルの名前は、文字の循環シフトによって相互に取得されます！

-何？

-さて、このテーブルの名前の先頭が末尾に移動すると、そのテーブルの名前が正確にわかります。

-どこ？

Vasyaは示した。テーブルはJSMITHスキーマにあります。これらの2つのテーブルの名前は、辞書式順序で次々と書き込まれ、次のタスクの鍵となります。 2文字の循環シフトの例：ABCDEF-> CDEFAB。 DBA_TABLESビューを使用できます。

トピック：辞書および文字列関数の使用、DBA_TABLES

タスク5。

最後に、Vasyaは経営陣のニーズに応え、報告書を作成することに同意しました。報告書はすでに2か月間求められていました。レポートでは、次のようにSQL2017.ORG_STRUCTUREテーブルから組織構造を導出する必要がありました。すべての従業員の名前をアルファベット順に印刷します。従業員の1人が部下を持っている場合、頭の下でインデントし、すべての部下を再びアルファベット順にインデントします。部下の1人が部下を持っている場合、再び部下をアルファベット順にインデントして推測します。以下に例を示します。

  ... ------------------------ -------- ----

従業員の従属は、マネージャーIDを参照するMANAGER_IDフィールドによって設定されます。従業員の名前はNAMEフィールドにあります。

報告を行ったVasyaは、Vasya自身が明らかに無関心ではないシャーロットペトロフナ（ID = 716）に出馬した場合、HINTフィールドを見ると、このフィールドが次のタスクの鍵を開くことに気付きました。

トピック：階層クエリ、SIBLINGSによる並べ替え

タスク6。

かつてヴァシャとジェンヤは独立についての論争を始めました。そして、Vasyaは独立した判断を1つも行いましたが、チェックポイントで持ち帰りを求められ、判断を取り戻し、部屋の隅に置く必要がありました。そして、議論は新たな勢いで続きましたが、今は依存についてです。依存関係は、必要な場所と必要でない場所を探していました。最終的には、お気に入りのデータベースで、かなり多くの場所で見つかりました。

データベースオブジェクトが別のオブジェクトに依存している場合、DBA_DEPENDENCIESにレコードがあることがすぐに明らかになりました。OWNER.NAMEはREFERENCED_OWNER.REFERENCED_NAMEに依存しています。誰かがチェーン内の次のオブジェクトに依存している場合、依存関係のチェーンはさらに継続できます。

独立したオブジェクトは興味の対象ではなく、いずれにせよそれらに依存するものはありません。しかし、最も病みつきになる人を見つけることは興味深い出来事でした。さらに興味深いのは、他のすべての人が依存している最も「影響力のある」人を見つけることです。他のオブジェクトの最大数が依存するオブジェクトの名前と、これらのオブジェクトの数は、次々に書き込まれ、次のタスクを解読する鍵となります。

聴衆の中で隣に座っているVasyaと彼の同僚の行動から結果を保護するには、このタスクのLOLスキームに限定してください。オブジェクトはそれ自体にも依存すると考えられています。スキーム内のすべてのオブジェクトの名前は一意です。パッケージの本体と仕様は、1つのオブジェクトと見なす必要があります。

トピック：DBA_DEPENDENCIES、再帰クエリ。

タスク7.（ボーナス）

Kolya Yokも会社のニーズに応じて働いたことがありましたが、多くの方がより良いと信じていました

彼は何もしなかった。たとえば、彼は悪名高いレポートEJEKP.JMACCXBXUKを書きました。

絶えず壊れており、このレポートによると、月の水文気象センターは長い間

すでに彼自身の天気予報を行っています。もう一度レポートが表示されなくなりました

必要なデータ、および一般的な緊急事態が発表されました：職場の誰も発散しません

レポートが機能するまで。必死に試みたコリヤとは異なり

レポートの作業を分析するために、Vasilyは他の方法を採用することにしました。そして代わりに

プロシージャEJEKP.JMACCXBXUKを破った人を探して、Vasyaは自分自身を証明することにしました

彼は個人的にデータベース内の何も変更しなかったことを実証する無実、

影響する可能性があります。これを行うために、彼は手順と機能のリストを見つけました（さらに

サブルーチン）EJEKP.JMACCXBXUKは独立しています。そして、すべてのヴァシーナの修正

コードはこのリストに分類されます。

仮定：

DBA_DEPENDENCIESの依存関係は、オブジェクトレベルまで細分化されます。これで

パッケージルーチン間の依存関係に関心があります。させる

パッケージP1のサブルーチンS1は、パッケージP2のサブルーチンS2を呼び出します。それから私達は言う

そのP1.S1はP2.S2に依存しています。能力ではなく、コード内で呼び出しを行うことに関心があります

この呼び出しを行います。例えば

IF FALSE THEN P2.S2; END IF;

P2.S2への挑戦と考えます。

EJEKP.JMACCXBXUKが依存しないすべてのKEKスキーマパッケージルーチンを見つけます。

これを行うには、表を使用してパッケージのソースコードを分析する必要があります

DBA_SOURCE。ソースコードからすべての依存関係を見つけることができると想定しています。

このスキームのパッケージおよび他のスキームのルーチンは呼び出されません。パッケージなし

コメント。パッケージおよびサブルーチン名は、呼び出されたときに常に配置されます

間にスペースを入れずに1行で入力します。キーワードPROCEDUREおよびFUNCTIONおよび

それらの名前も同じ行にあります。パッケージ名とサブルーチン名

他のすべてのオブジェクトの名前とは異なります。パッケージのみが宣言されます

ルーチンは前方宣言です。

答えは、見つかったプロシージャと関数の名前の文字列です

辞書編集し、カンマで区切られた単一の行に接着します。ローカルを忘れないでください

ルーチンはパッケージ本体で宣言されていますが、仕様では宣言されていません！

トピック：DBA_SOURCE、再帰クエリ。

問題8.（最後のボーナス）

Vasyaは会社のニーズに応えて働いていましたが、Zhenyaは熱意を持って何かをし、時折Vasyaに神秘的な目を向けました。最後に、それを我慢できない、Vasyaは尋ねた：

-さて、何がありますか？

Eugeneの説明：

-そろばんをやっています。 JSMITH.ABACUSネームプレートに数字があります。 1つの番号を選択してから、2番目の番号を（同じレコードからでも）任意に選択して追加します。次に、3番目の数値（既に取得済みのレコードから取得することもできます）と4番目の数値を取得し、これら2つを互いに乗算します。また、このような4つの数字のセットが、最初のペアの合計が2番目のペアの積に等しくなる場合があります。そして、そのようなセットがいくつ発見されたか知っていますか？

「まだわかりませんが、すぐにわかります。」これは基本です！ -ヴァシャは、クラバKの過去のエクスプロイトを思い出して言った。

しかし、リクエストを書いて30分間「お待ちください」という碑文を送った後、VasyaはV $ SESSION_LONGOPSおよびその他の同様の場所を見て、営業日の終わりまで答えが返ってこないことに気付きました。要求は停止されました。彼の心の中に何かを推定して、Vasyaは異なった行動をしました。そして数分後、彼は答えを知った。この答えを見つけてください。

JSMITH.ABACUSテーブルの4つの数字の組み合わせの数は、最初のペアの合計が2番目のペアの積に等しいため、次のタスクを解読する鍵となります。すべての可能なセットは次のように定義されます。最初の場所-テーブルの各番号、2番目の場所-テーブルの各番号、3番目と4番目-同じ。たとえば、テーブルに10個の数字があり、それらすべてがゼロである場合、問題の答えは10 * 10 * 10 * 10 = 10000になります。

トピック：追加のテーブルの作成、最適化（ネストされたループとハッシュ結合の違い）。

タスク9.（最新のボーナス）

VasyaはZhenyaの肩を叩いて言った：

-そして、そろばんを作りました！そして、あなたは私がそれに何を期待していたか知っていますか？

-前のタスクでやったように、作品と一致する合計数は？

-いいえ、-ヴァシャはにやにや笑いました-私は簡単に行動しました。 4つの数値のセットがいくつあるかを計算しました。最初の2つの合計は最後の2つの合計に等しくなります。

「だからそれはさらに簡単です！..」とZhenyaは叫んだ。

-そして、あなたが試してみてください-ヴァシャはにやにや笑いました。

そして、彼が水をのぞき込んだとき、それはそれほど単純ではありませんでした。

テーブルVPOUPKINE.ABACUSから取得した4つの数値の組み合わせの数は、最初のペアの合計が2番目のペアの合計に等しいため、次のタスクの鍵となります。

トピック：ロジック、最適化（書き換え要求）。

タスク10.（スーパーマン用）

Vasyaが勤務している部門には、まだ誰も行っていない多くのオープンタスクがあります。

約設定します。 Vasyaは本当にできるだけ早く休暇に行きたいと思っていますが、このために彼は決めなければなりません

KPIが滑らないように、これらのタスクから少なくともK。 Vasyaはおおよその時間を表します

彼は各タスクの解決策を取り、K個のタスクを開発し、残りのタスクを与えたい

他のプログラマ。これらのKの問題を解決するのに必要な時間を見積もったVasyaは、今すぐチケットを購入するために休暇の開始を調整することにしました。 Vasyaの上司は非常に慎重であり、Vasyaが最後に選択したタスクを完了する時間がないと考えたため、この部分的に解決されたタスクを別の開発者に転送する必要があり、時間がかかります。 Vasyaの休暇は、このタイムリザーブを確保するために進められました。タスクが優先され、開発者は優先度の高い順に実行する必要があります。 TASKSテーブルには、タスクに関するデータが含まれています。各タスクの名前は、NAME、部門番号DEPARTMENT_NUMBER、PRIORITY優先度（数値が大きいほどタスクの優先度が高い）、EXPECTED_TIMEの推定期間、および未解決のタスクを別のADDITIONAL_TIME開発者に転送する推定時間です。 Vasyaは、できるだけ早く休暇を取るために、これらのタスクから正確にKを選択しました。つまりこれらのK個のタスクの推定所要時間と、これらのK個のタスクの最後の（優先順位による）推定伝送時間の合計は、可能な限り最小でした。

組織には複数の部門があり、各部門には独自の「Vasya」があります。テーブルで

DEPARTMENTSには部門データが表示されます：部門番号DEPARTMENT_NUMBERおよび

Vasyaがこの部門から解決しなければならないタスクKの数。に注意してください

各Vasyaがタスクを選択できるという意味で、部門は完全に独立しています

あなたの部門のみ。

各Vasyaの休暇の開始時期を決定する必要があります。

彼らはタスクを最適に選択しました。つまり、部門DEPARTMENT_NUMBERのVasyaはS日間休暇を取ります。Sは、Vasyaが選択したタスクの期間と最後のタスクを別の開発者に転送する時間の合計に等しくなります。キーとして、見つかったS番号を、部門番号DEPARTMENT_NUMBERの昇順でスペースなしのコンマで区切って使用します。テーブルはVACATIONSスキーマにあります。

トピック：並べ替え、ロジック。

タスク11.（スーパースーパーマン用）

何年も経ちました。この間、人類は技術的な特異点を乗り越え、ヴァシャはまだ同じ会社で働いていました。しかし今では、彼の脳はすでに人工知能を備えたスーパーコンピューターに接続されているため、Vasyaは数千の問題を数ミリ秒で解決できました。すべての革新にもかかわらず、Vasyaには「休暇中に早退する」という問題がまだあります。過去に多くの統計が蓄積されており、タスクの優先度が低いほど、タスクを別の開発者に転送するために必要な追加時間が短くなることがわかりました。また、同じ部門内で同じ実行時間の2つのタスクが存在する可能性は無視できることがわかりました。

前のタスクと同じように変更する必要があります

データがMEGAVACATIONSスキーマ、DEPARTMENTSおよびTASKSテーブルにあることを確認してください。

Vasyaが何百万ものタスクを解決できるようになったことに留意してください。

データが条件を満たす：タスクTASK_i != TASK_j

が1つの部門から

TASK_i.EXPECTED_TIME != TASK_j.EXPECTED_TIME

およびTASK_i.PRIORITY <= TASK_j.PRIORITY

からはTASK_i.ADDITIONAL_TIME <= TASK_j.ADDITIONAL_TIME

ます。

トピック：並べ替え、ロジック。

タスク12.（リボンを仕上げる）

おっと！..これはもうタスクではありません。これは実際、仕上げです。おめでとうございます！

スツールに寄りかかって、笑顔で、主催者に静かに手を振ると、彼らも喜ぶことができます。しかし、他の参加者の注意をそらすことなく、クール！

タスクに関するコメント

タスクに関するいくつかのコメント。実際、最終タスクのために6個が準備され、さらにメインの6個が解決された場合は2つのボーナスの難易度が用意されました。タスクは難易度の高い順に配置されました。この複雑さをどのように測定するかは理解できないので、どこかで見落としがあります。さらに、以前のすべての問題をボーナスの問題と一緒に解決するモンスターが突然現れた場合は、さらに複雑な2番目のボーナスタスクのバリエーションを1つ追加します。

つまり、最初の6つの問題には確実にトリックはありません。SQLで書く人は誰でもそれらを解決することができ、時間だけで十分です。はい、追加の知識とスキルを使用すると、これらの問題を迅速に解決できます。ボーナスタスクでは、倒錯者はすでに去っています。 1つ目は、創造的に分析されたかなりの量のデータであり、2つ目は、最適化です。さらに、困難なのは、ここで最適化が必要であると推測する必要があるという事実にあります。「額」の解決策が機能しないため、特別に選択されたからです。追加のボーナスタスクでは、前のタスクと同じ方法では機能しないため、アルゴリズムの最適化が必要です。

次に、割り当てられた時間内に誰も最後まで行かないようにするために、2つの真にオリンピアードのタスクを設定しました。そして、もしあれば、12番のスタブは本当におめでとうございます。もちろん、私たちはこれを信じていませんでしたが、中心の数学者や専門職のプログラマーとして、私たちはそのような場合を考慮すべきでした。

合計で、参加者は最大6つの問題を解決し、7-8-9で立ち往生することが予想されました。またはそれ以前。最悪の事態は、誰もが最初のタスクに突然突っ込んだ場合です。彼ら（参加者）にとっては、「3時間の恥、それからいつも通り」であり、勝者を決める基準によって必死に駆け巡ります。おそらく、自分自身を保護し、最初の項目としていくつかのSELECT ROWID FROM DUAL

タスクを配置する必要があったため、1つの問題が正確に解決されました。しかし、計算は正しいことが判明し、最初のタスクなどがすべて解決されました。

タスクの復号化は次のように行われます。

 SELECT sql2017.decrypt('---', encrypted_text) FROM sql2017_tasks WHERE task_number = 2;

公式の目的でタスクを準備するプロセスでは、テーブルジェネレーター、ラビリンスジェネレーター、および正しい算術式（2回目まで）、コードと相互呼び出しに必要なパラメーターを備えたパケットジェネレーター、人名の単純なジェネレーターが作成されました。

いつものように時間がありませんでした。たとえば、選択した形式でクイーンタスクを実行する方法がわかりませんでした。

オンサイトトレーニング、ソチ2017年6月

今、「純粋な理由」の迷宮から、私たちは死の地に戻ります。

ソチは夏の暖かさと緑に出会いました。チェックインは木曜日に、金曜日にはすべてのカテゴリーで決勝戦が行われました。その後、週末に文化プログラムが開催され、月曜日には賞の授与とプレゼンテーションが行われます。

サーバーに準備されたベースを持ち込みました。参加者も一緒に場所を持ち込みました（ただし、自分自身ではなく、同僚）。同じ条件を作成するために、すべてのユーザーが同じ事前構成済みジョブを持つことになりました。個人的には、参加者が自分のコンピューターを使用することを許可されている場合、エキゾチックな動物園の接続に関する問題の可能性を恐れていました。 krivorukyと永続的な誰かがいます-トラブルは屋根の上にあります。そこで彼らは同じラップトップを持ってきました。メーカーからのGUIを備えた無料の開発ツールとして、ファン（実際にはSQLcl）およびSQL Developer向けの本格的なSQL * PLUSを提供しています。実生活の友人の1人がSQL Developerを積極的に使用したことは覚えていませんが、その後は全員が同じ状態にありました。さて、ドラマ化する必要はありません。少なくともメモ帳では、必要なSQLクエリを何でも収集でき、SQL Developerは問題なく動作します。

木曜日に私たちはこのすべての経済をオリンピックが開催されたオルジョニキーゼ通りのオリンピック大学に持ち込みました。組織的な待ち伏せがありました。 SQLファイナル用に2つの小さな部屋が割り当てられました。 1つでは量に適合しません。ローカルネットワークは、ツイストペアテーブルをラップしました。他に対応する機会がなかったので、私たちは本質的に近隣の聴衆で2つの同時決勝を開催しなければなりませんでした。行うことができた唯一のことと私が変更したことは座席でした。参加者が互いのモニターを見る機会があった場合、それはまったく役に立ちません。意図的に覗き込むことはまずありませんが、さまよう視線につまずき、書かれたものを見ないことは、問題を解決する際に行き止まりになった人にとってはやり過ぎです。そのため、私はネットワーク作成者がすでに行った努力に不満を述べ、断固としてテーブルを円状に配置しました。一部の場所の写真では、特徴的に配置された円テーブルがちらつきます。

ワイヤ、ソケット、ラップトップのダウンロードとチェック、データベースへの接続の設定は複雑ではありませんが、さまざまな小さな質問が常に発生するため、長い間です。ツイストペアが終了した後、ハブのすべての穴がビジーであり、別の穴が必要になります。ネットワークは隔離されていることが判明したため、IPアドレスを配布するにはDHCPが必要です。ネットワーク構成の変更のためにアドレスを常に実行して手動で入力するよりも、1つのDHCPサーバーを構成する方が簡単です。ドキュメントにアクセスするには、インターネットへのゲートウェイが必要です-構成され、動作しました。つまり、夜遅くまで軽微なトラブルで十分でした。

そして、朝に私たちは待っていました...

ファイナル

公式のオープニングについては何も言いませんが、これはSQLのノミネートと関係がありますが、私たちはまったく関与していません。オリンピックにはたくさんの人が集まったとしか言えません。ロビーのレセプションでは混雑していませんでした。前日にチェックインしてバッジをもらったのはいいことです。

グランドオープンの後、私たちはホールに最終参加者を集め、開拓者のリーダーのように、ファイナルの準備ができている聴衆に彼らを導きました。ブリーフィング、ログインの配布、データベースへの接続の検証、決勝戦のルールの説明、問題番号0の例によるテスト問題のデコードの全員による検証最初のタスクの代わりに、スタブがあります。事前に作成されたクエリを使用した解読者のログにより、テストタスクを正しく解読できていないユーザーを追跡します。ああ、うまくいく！

みんな準備はいい？最初のタスクをスタブから実際のタスクに変更し、ログをリセットします。行きましょう！..

注文と状況を監視します。状況を監視し、解読者のログテーブルから選択し、解決された問題の数と解読時間でソートすると便利です。リーダーは目の前にいます（注意して、「ライブ」コード）。

 select l.oracle_user, name, task , (select min(sent_date) from sql2017_log l2 where l.oracle_user=l2.oracle_user and l.task = task_number)+3/24 solve_time , tries from (select oracle_user , max(task_number) task , count(1) tries from sql2017_log group by oracle_user) l , sql2017_users u where u.oracle_user = l.oracle_user order by task desc, solve_time asc

いくつか質問があります。フィナーレ全体のほんの一部。 12:15のオープニングとブリーフィングの荘厳な部分の後、15：30に終了しました。終了時間は、本質的にはそれほど重要ではありませんでした。主なことは、事前に指定することでした。 15から16まで昼食があったという事実から始めました。参加者を30分遅らせるのは普通です。昼食を手放さないのは残酷です。

フィナーレ中のいくつかの事実。最初のタスクは、開始してから4分前に解決されました。ファイナルでリーダーを3回変更しました。3人のリーダーは一般的に非常に動的に変更されました。 , ( ). ( , ), , , . . .

. , , , , . , , , - — . . , , . , , — .

, , . , ( ) ( ).

, , . , , , . , .

, — .

. . , , , .

! . — ! , , - . , - , , , - . , , - . , . , , .

SQL Olympiadはどうやってやったのですか（終了）