[LilLoco]

Это как-то связано с упомянутыми полигонами? »

Изначально, когда было разделение на небольшие возможные регионы (лишь несколько районов московской области), использовалась таблица, в столбце которой хранились полигоны этих районов и использовался тип данных - geometry. Далее осуществлялась проверка вхождения точки из таблицы измерения в полигон. таким образом точки соотносились с географическими областями.

Откуда будут браться координаты реальных географических объектов? Какая-то база? »

Планируется, сделать геокодирование по всем точкам при помощи яндекс-карт, google-maps, 2gis, mapinfo. Каким именно сервисом пользоваться еще не знаю. Но выбор будет среди них. Другого под рукой ничего нет.

[Iska]

lxa85, некоторые сами «рисуют» карты: Waze: нам по пути, или История маленького, но очень гордого стартапа.

Изначально, когда было разделение на небольшие возможные регионы (лишь несколько районов московской области), использовалась таблица, в столбце которой хранились полигоны этих районов »

Ну, таково было и моё видение. Вы от этого решили уйти? Почему?

и использовался тип данных - geometry. »

Где можно почитать — что это за тип данных в Microsoft SQL Server?

[LilLoco]

Где можно почитать — что это за тип данных в Microsoft SQL Server? »

Когда я разбирался, читал все на MSDN.

Вы от этого решили уйти? Почему? »

Проверка вхождения точки в полигон, созданный типом geometry Sql Server занимает довольно долгое время. Притом, что было всего порядка 25-30 таких полигонов. С учетом, того, что сейчас необходимы полигоны не только такого количества групп, а намного больше, я думаю, время обработки намного увеличится. Кроме того, для создания этих полигонов, необходимо знать краевые точки всех этих географических объектов. Что так же добавляет трудности в создании таблицы с географическими объектами.

[Iska]

Когда я разбирался, читал все на MSDN. »

Спасибо, ясно.

LilLoco, почему бы не делать привязку к нижнеуровневому объекту не в момент выборки, а в момент добавления строки с измерением в таблицу?

[LilLoco]

а в момент добавления строки с измерением в таблицу? »

Процесс добавления - закрытый. Добавление происходит при помощи ПО, поставляемого вместе с измерительным комплексом. Получается, что при добавлении мы никак не можем повлиять на структуры таблиц.

Плюс, могу сказать, что добавление производится не всегда в одни и те же базы данных. Поэтому, например, использование триггеров, срабатывающих на добавление записей, является невозможным.

привязку к нижнеуровневому объекту »

В любом случае необходим источник этих объектов. И вот в каком формате целесообразнее хранить эти объекты, на данный момент, является для меня все еще загадкой.

[Iska]

Процесс добавления - закрытый. »

Ясно. Я думал, всё сугубо Ваше.

А как насчёт делать привязку в момент пересчёта? Есть же технологические перерывы какие-нибудь?

В любом случае необходим источник этих объектов. И вот в каком формате целесообразнее хранить эти объекты, на данный момент, является для меня все еще загадкой. »

Например: Измерения[Id Измерения, Координаты, Измерения, Принадлежность] ⇚ один ко многим → Объекты[Id, Наименование, Подчинение (ссылка на Id в этой же самой таблице)] ← один ко многим ⇛ Полигоны[Id, Id Объекта, координата точки полигона, порядковый номер точки].

Схема базы данных:



(вторая таблица «Объекты» на схеме — фиктивная, только для того, чтобы показать связь, ссылку с одной записи таблицы на другую запись той же таблицы).

Так вот, в этой схеме поле «Принадлежность» (к объекту нижнего уровня) можно заполнять позже.

Пожалуй, таблицу Полигоны также стоит разбить на две подтаблицы: собственно Объект[Id, Наименование (что-то я забыл про это на схеме), Подчинение] и ТочкиПолигона[Id точки, координата точки полигона, порядковый номер точки, Id Полигона].

[LilLoco]

А как насчёт делать привязку в момент пересчёта? Есть же технологические перерывы какие-нибудь? »

Да такой вариант вполне уместен. Перерывов предостаточно, в разумной степени естественно.

Iska, Спасибо большое за разъяснения. Буду пробовать.

Спасибо всем за помощь в этом, нелегком для меня, деле.

Тему пока отмечу решенной

[Iska]

LilLoco, я сейчас ещё подумал (да, бывает и такое — я думаю ) — таблицу Полигоны, что на схеме, надо обязательно разбить на две таблицы: один объект может состоять из нескольких полигонов, тогда как раз логично держать отдельно сами полигоны (как сущность) и отдельно, так же — как сущность, точки конкретного полигона.