ルート百科事典のデータベース構造

「都市/郊外の輸送ルートの百科事典にどのような形式の記録保管を選択するか」というトピックに関するエッセイをフリースタイルで。

何よりも、このテキストを書くとき、私はプログラミングの分野の知識の残党に導かれ、同時に「データベースに書き込む通常の形式」の概念を自分自身で再考しました。


1.私が初めて行く外国の都市のバス/トロリーバスのルートを見ることができるシステムが欲しいです。 最も基本的な場合は、どのように進むか、どの交差点で曲がるか、どこにあるかを知るだけでよく、停車地については、指揮者またはドライバーと話をします。 最もコーシャの豪華な場合-旅行にどれくらいの費用がかかりますか、移動の間隔、ドライバーの交換ができるように、そのような詳細なルートのあらゆる種類の辛い詳細。


2.ルートエンサイクロペディアは、実際には何らかのDBMSである必要があります。 つまり、すべてのルートをデータベースに入力する必要があります。 そのようなデータベースのレコードの形式を決定する必要がありますが、これは簡単に処理でき、DBMSで何かが変更された場合でも、古いデータベースを引き続き使用できることが望ましいです。 記録が不必要でなく、より必要であったことが必要です。

3.記録には何が必要ですか？ 基本的に、ID、ルートトレース、およびメタデータが必要です。
idを使用すると、すべてが明確なように見えます。つまり、識別子自体です。 ルートのルートは、％bus％が乗客と順番に通過する地理的ポイントのセットであり、これらのポイントの一部には停留所（乗降）があります。 各トラックは最初のストップで始まり、エンドで終わります。 ルートが循環的であっても、ルートが条件付きで開始する場所を見つけることができます（たとえば、通常、車はルートで生産を開始します）。 最初の停止地点から最終的な停止地点（方向を含む）までの1本の破線が表示されます。 それ以外はすべてトラックではありません。 また、車両のUターンはそうではありません（その前にすべての乗客がターミナルで追い出されます。そして、彼らが蹴られない場合、原則として、Uターンをルートの一部と見なすことができます。しかし、とにかく-Uターン前の「最終」と「初期」であり、実際の生活では、少なくとも正式に）。

すべてのバリエーションの1つのルートに関連するメタデータがあります。これは、その番号を持つ個別のバス%%がどのルートを取るかに依存しません。 （このタイプのメタ情報の顕著な代表は、実際のルート番号です）。 特定のルートにのみ適用されるメタデータがあります（それらは主に旅行の時間-費用-空間パラメータを記述しています）。 これは、それらを対応するトレースとともに表示する必要があり、前のタイプのメタデータとは関係がないことを意味します。
このように見える場合、データベース構造は次のように見えます：id; トラックに依存しないメタデータ。 それらにのみ関連するメタデータを持つトレースのいくつかのセット。

3+。 小さな詳細。 ルートの統計的大部分は、レールかトラックレスかに関係なく、1つのIDに対して正確に2つのルート（「そこ」と「戻る」）が必要です。 この事実により、データベース内の記録形式を選択する際に何らかの制限を強いられるべきではありませんが、インターフェースと検索を開発する際には考慮すべきです。 たとえば、ユーザーがルートの特定のバリエーションを要求する場合、ほとんどの場合、特にルートが視覚的に乱雑にならないため、直接ルートと戻りルートの両方をすぐに見る方が便利です。
（ただし、一方の端だけでも、一度にルートのすべてのルートをマップ上に描画すると、これはマップを繰り返し描画された線で混乱させ、注意をそらします。）

3 ++。 たとえば、1秒おきに発車する％bus％が異なるルートルート（たとえば、ある種のアレイまたはステーションにドライブする）がある場合、ポリモーフィックルートのケースがあります。 モスクワにはこのようなルート365があります-それ自体はありませんでしたが、彼らは私に言った：それは1つのルートと見なされますが、実際には同じ番号で4つのルートが隠されています。 そして確かにそれらの特定の次はバスのフロントガラスの印によって常に警告されます。 実際には、「365」、「Aに停車する365」、「365を介してB」、「365を介してAおよびB」の4つの異なるルートがあります。 ルートは実際には4つ異なるため（最初の停留所の近くからポイントAに向かって作業する場合、4つの結果のうち2つだけが落ちるはずです）-したがって、特にそのようなルートの圧倒的多数があるため、4つの異なるIDでそれらを提案および保存します。 繰り返しますが、使いやすさはそれほど苦しみません。 データをユーザーに出力するときに、「類似ルート」のリストのようなものをユーザーに簡単かつ簡単に表示できます。

4.ルートストレージモデルが選択されたので、メタデータについて考えることができます。 さらに、それらの一部は特定のルートに依存し、一部は特定のルートにのみ依存します。それらは2つのグループに分けることができます-手動で入力する必要があるグループと（標準化された同じ方法ですべてのデータを保存するために）ユーザーは与えない方が良いでしょう。 たとえば、すべての地理データ（連邦地域都市の国）を標準形式で保存する必要があります。そうしないと、タグをすばやくスムーズに固定できません（詳細については、10項を参照してください）。 google maps APIなどの形式で情報を取得すると便利です。 （GEOSのような代替手段があり、例としてのみGoogleマップを選択しました）。
これからは、「都市」という言葉の下のすべての場所で、同時にそれに関するメタカテゴリーの完全なセット、つまり国-地域-都市を意味します。

5.カタログから1つの都市へのルートを強制的に記録する必要はありません。そうでない場合、郊外のルートでは多くの疑問が生じます。 DnepropetrovskとDneprodzerzhinsk（近い）のような2つの双子の都市間のルートは、さらに多くの疑問を投げかけます。 しかし、少なくともルートに何かを接続する必要があります。さもなければ、「トラム30番」のリクエストに応じて、モスクワ、サンクトペテルブルク、キエフ、ヘルシンキから30番のトラムを取得するリスクがあります。 さらに悪化するのは、同じモスクワ内で、ゼレノグラードのバス番号1、コロレフのバス番号1、最初のバスが2つあることです。 バスの出発地を示すIDごとに特別なフィールドを作成する必要があります-「ルートが割り当て/承認されている都市」など（半自動-リストから選択するか、Google APIにアクセスできる地図をクリックします）。 比Fig的に言えば、このフィールドは「ホームポート」と呼ばれます。

私の考えを理解しやすくするために、例：
-Nerezinovaには同じ番号のルートがあります：1（コロレフ）; 1c; 1（ゼレノグラード）; 1（ヒムキ）。 このトリッキーなフィールドへの最初のルートでは、「コロレフ」、2番目の「モスクワ」、3番目と4番目の「ゼレノグラード」、「ヒムキ」をそれぞれ記述します。 ユーザーがA地点からB地点までの道路を検索すると、AとBが完全にモスクワにいる場合でも、「バス1」という回答の代わりに「バス1（コロレフ）」を返します。 もちろん、検索のポイント「から」と「どこ」が両方とも「ホームシティ」にある場合、このフィールドは表示されない可能性があります。 他の用途の中でも、このフィールドはカタログ化の基礎であり、同じ都市の同じルートと戦う手段です。

別の例：セバストポリ市のバス70は郊外にあり、セバストポリのかなりの部分を通過してから、郊外を通ってフォロスに到着します。 誰かがForos内またはForosからルートを検索し、この同じバス番号70を受け取った場合、「70（Sevastopol）」とそのフルルートが表示されます。これはユーザーに干渉する可能性は低いですが、彼を助けます。 （私は誇張しています：フォロスのユーザーは、ある時点で2つの70のルートから引き渡しを受け取る可能性があります。ここでは、表示形式「70（セヴァストポリ）」、「70（ヤルタ）」は単に彼を救います。）

6.次に、必要であると判断したメタデータのリストを提供します。これはすぐにルート全体に適用されます。 それらについてのコメントもあります。

最小限のユーザーの自由で満たされるべきフィールドは、括弧（自動）または（半自動）でマークします-後者はリストからの選択を提供します。

すぐにルート全体に帰属するメタデータ：
-「レジストリの都市」-5.を参照
-トランスポートのタイプ（セミオート-リストから選択）-1つのドロップダウンリスト。 便宜上、ユーザーはカテゴリに分類できます。たとえば、鉄道（地下鉄、路面電車、市電、ケーブルカー、モノレール、その他のエキゾチック）、水（フェリーまたは川の路面電車、ところでセヴァストポリからの挨拶）、地上（バス、トロリー、シャトル）タクシー）。
-ルート番号-原則として、これはテキストフィールドです。 理由： "422d"; 3-trトラムのキャンセル時のバス。 またはAeroexpressやSkyBusでさえも。 ただし、長さなどを制限する必要があります！ そうしないと、データベース（および単一の大都市のルートの出力）に、郊外および都市間ルートの長い番号のない名前（「Orekhovo-Zuevo-Spasokukotsko-Narochnenskoe」）が散らかり、単一のメガロポリスのルートの「カタログ」が恐怖のうめきなしで視聴できなくなります。 そして一般的に、私は個人的にそのようなルートはバスステーションによって完全にサービスされるべきであるという信念を固守します。
-運送業者-可能であれば、法人所有者の完全な（所有権の形式を含む）名前。 ちなみに、ここではタグの使用も適切であり、タグjurだけでなく、指定するところまでです。 運送業者の人だけでなく、ルートにサービスを提供しているATP /コンボイ/デポの人（公共交通機関のある巨大都市に関連し、非常に興味深い）。
-運賃-ルートのコストは多くの場合固定されており、ルートに依存しません-運送業者/ルート番号のみに依存します。 しかし、そうではない場合もあります。たとえば、高速道路の一方通行などによる帰りのルートが非常に長くなり、民間キャリアが別の料金を請求する場合などです。 これはまれなので、コストはルートのグローバルフィールドです。 故郷に基づく通貨の自動代替は、もちろん美しいです。 ただし、ルート/コストを距離/ゾーンに依存するルートを作成する場合、ユーザーがフィールドminimum-maximumに入力するか、コメントを残すことをユーザーに警告する必要があります。
-ルートの一般的な機能。 -たとえば、「ルートは最新のMAZ-107バスによってのみ提供されます」、「ターンスタイルはルートバスに設置されます」。

7.メタデータを簡単に残し、ルートルートを処理します。 1つのルートは、既に決定したとおり、片道1フライト％バス％に対応する必要があります。 原則として、同じGoogleのWebマップがポイントを置いたときに座標を提供する精度は、GPSの測位精度とかなり匹敵します（少し悪いですが、メートルの単位であり、同じエラーは約、悲しいかな、異なるソースからのカードの組み合わせを示しています）。 新しいルートを描くときに文明の利点を活用する価値があります-インターチェンジと通りの脇を通過するすべての微妙さで、最もアクセスしやすい詳細でそれを描くために。 そのような詳細がなければ大きな問題はありませんが、努力する価値はあります。 データの正規化におけるこれの重要性に加えて（冗談なしでトラックを録音すること、それが実際にどのように行われるかということよりも良いものはありません）-このジャンクションで％bus％がどこで曲がるのか、それに応じてどのように到達するのかを知ることは時々興味深いですやめて！ さらに、一度外国の都市に来て、少なくとも徹底的にナビゲートすることを安心させることは素晴らしいことです。

8.選択したデータストレージモデルによると、「そこ」と「戻る」ルートのルートは、互いに独立したオブジェクト（ルート）として処理する必要がありますが、互いに近づける必要があります。 定期的に（たとえば週末に）変更されるルートルートと、フライトごとに異なるルートルート（最初のバスはAに、2番目のバスはすべてBに行く）は、異なるIDでそれらを配布します。 これにより、ルートの往復ルートのペアを検索および作成するためのメカニズムが簡素化されます。 繰り返しますが、「リングルート？ はい/いいえ "または"一方向のルート？

9.ルートルート-それらを接続するポイントとラインのセット。 トレースを保存する論理的で経済的な方法-ポイントのシーケンス。 各トラックには少なくとも2つの特別なポイントがあり、開始点と終了点の2つのストップでもあります。 おそらく、それらの名前を保存すると同時に、残りのストップを座標リストのトラックとともに保存することをお勧めします。 その後、それらは処理が簡単です。名前が座標ペアの反対側にある場合、これはストップであり、レンダリング時に適切に選択する必要があります。 名前がない場合、これは通常のウェイポイントであり、名前を選択する必要はありませんが、単純にルートラインを描画します。 数字やテキストに干渉しないようにするために、メタデータのトラックにストップのシーケンス番号などのラベルを付けるだけです。 少なくとも、ストップをルート全体が構築されるのと同じポイントにすることは、私にとって非常に論理的に思えます。

ウェイポイントとストップにデータを保存するという考え方を発展させることができます。最初のストップには番号1を割り当て、最後のストップには0または9999などを割り当てることができます。たとえば、ウクライナのキエフ市のルート33：

50.46611, 30.64351, 1 //   50.46414, 30.63630, //    50.46494, 30.63596, 2 //  50.46825, 30.63379, 3 50.47176, 30.63141, {…} // n-      50.48083, 30.62724, 50.48251, 30.63317, 0 //  

これにはもう1つの利点があります-[リターンルートを描く]ボタンをクリックすると、開始点（前の終了点と同じ名前）と終了点（その逆）をすぐに入力できます。

遠い将来の機能は、1つのストップが複数のルートを提供する場合に、マルチルートストップを考慮することです。 彼はそのような停止をクリックし、ポップアッププロンプト「ここで停止：...」をクリックしたようです。 たとえば、描画するときに、描画されたトレースの既存の停止がある「磁石」として実装します。

また、停止を追加する必要があるすべてのユーザー、開始と終了のみ、または一度にすべてのユーザーに警告することもできます。

10.次に、位置情報と都市タグについて説明します。 ユーザーがルートの描画に成功し、「ルートの保存」ボタンをクリックしたとします。 これで、描画されたストップをGoogleマップAPIにフィードして、これらのブレークポイントが都市に属しているかどうかの回答を分析できます。 さらに、ルートを作成しているユーザーがまだ停車していない場合でも、定義により、初期と最終の2つが既に存在します！

回答に基づいて、これらの都市へのルートの相互参照を自動的に作成し（少なくとも1つがまだ存在しない場合は、すぐに都市データベースに作成します）、このルートへの都市を作成します（この都市でも実行されるためです！）。 これがタグクラウドになります。

そこに「愚か者からの保護」のための十分な機会があります-ID＃のグローバルデータベース入力フィールドから「レジストリの都市」であることが判明した都市がない場合-おそらく、ここにエラーが入り込んでいます。
これで、都市の「ルートカタログ」には、この都市の名前のタグがあるすべてのルートが表示されます。

11.特定のルートに起因するメタデータ：
-ルートが通る都市タグの雲-10および3 ++を参照-特定のルート/ルートのペアへの理由。
-ストップ名のリスト-最小の場合、少なくとも2つが必要です。 したがって、データベースにルートを追加するときは、すぐにこの入力を行う必要があります。 ルートにアクセスするたびにDBMSを使用して最初と最後のストップを削除し、完全なリストとは別に、またはリストとともに必要な場所に表示するか、リターンルートの構築に使用できます。
-移動の間隔-自由形式のコメント用のシンプルなテキストフィールド。 たぶん、百科事典が旅行時間を計算し、さらには信じられる場合、平均待機時間を計算するためにこのフィールドを標準形式にする必要があります-多くのバスは、他の時間とはまったく異なる規則でラッシュアワーに行きます。
-マップ上のルートの長さ（自動計算）。
-毎週のスケジュール-私たちが選択したスキームに従って、たとえば週末にルートがルートを変更する場合、別のIDが作成されます。 したがって、特定のルート/ルートのペアのIDにバインドする場合、「週間スケジュール」フィールドは、ルートの％buses％がこのルート/ルートのペアに沿って進む時間でのみ埋められます。
-勤務時間-前の段落と同様。
-運動の間隔-前の2つと同様。


12.本質的に、データベースがすべてのようです。 これで、私が触れていないように思われること、つまりデータベースにレコードを追加するためのインターフェイスに少し時間を割くことができます。



ps「スキーマなしのデータベース」アーキテクチャを使用すると、必要なフィールドを必要に応じてねじ込んで、ほとんど副作用なしで使用できるため、多くの問題を解決できると言われています。