|
Notes |
|
|
|
Приаттачил модель БД, которая использовалась для SQLite3, в виде экспорта в pdf.
Там же внутри есть текстовое описание полей.
Но вот текста хранимых процедур, типа связей (on delete cascade или restrict) в pdf нет, за этой информацией надо лезть в саму модель.
Модель находится тут:
https://bitbucket.org/vasketsov/tilestorage_dbms
в папке model
файл
SAS_MARKS.pdm
Эта модель создана в PowerDesigner 16.5.0.4057.
ps. Экспортировать в pdf модель SAS_DB.pdm не удалось из-за непонятного бага. |
|
|
|
|
Поскольку в нормальных взрослых СУБД в поле типа int нельзя засунуть text и наоборот, то модель для СУБД в любом случае необходимо дорабатывать. Как минимум, это касается произвольных атрибутов (меток, категорий и т.п.) и "стандартных" свойств меток (типа даты создания, описания метки и т.п.)
Также требуется решение о логике применяемых блокировок сущностей на прикладном уровне: скажем, нельзя менять описание метки, если некто "в это же время" меняет её картинку.
Если есть умные мысли - не держите в себе ;) |
|
|
|
|
|
|
|
|
|
Ну, конкретно для этого тикета вряд ли оно будет полезно, а вообще конечно интересно будет поглядеть. |
|
|
|
|
>Ну, конкретно для этого тикета вряд ли оно будет полезно
Спорный вопрос. Геометрии все равно нужно как-то в блоб записывать, так чем изобретать велосипед можно воспользоваться готовым стандартом плюс получить поддержку от взрослых СУБД.
> а вообще конечно интересно будет поглядеть.
Ну там особо ничего интересного нет. Формат простой. Реализован на самом базовом уровне, тоесть без высот и скоростей и без особо сложных конструкций, тоесть точки, линии, мульти-линии, полигоны и мульти-полигоны - то что хоть как-то поддерживается САС.Планетой. |
|
|
|
(0015309)
|
|
zed
|
|
21-02-2015 09:48
|
|
vdemidov
Ну так, ссылку в студию :) |
|
|
|
|
|
Ссылку на что? На описание формата? Так вон внизу есть ссылка на википедию. Ну а реализацию нужно просто закоммитить. Где-то год назад писал для работы с MySQL. Все вроде бы работало. Векторные данные вытягивались из базы и отображались в том же виде что и викимапия. |
|
|
|
(0015311)
|
|
zed
|
|
21-02-2015 10:11
|
|
> Ну а реализацию нужно просто закоммитить.
Ну так о том и речь. Нафиг мне википедия. |
|
|
|
|
|
|
|
|
>Геометрии все равно нужно как-то в блоб записывать
А сейчас, думаешь, я в блобы в SQlite святой дух коммичу? ;) Пишется, как миленькая, метки же хранятся в SQLite.
>воспользоваться готовым стандартом
Этих стандартов - как собак.
А между тем "велосипед" с приведением координат к INT-у позволяет очень сильно уменьшить io, а ошибка на экваторе будет в сантиметры. Так что велосипед велосипеду рознь.
>плюс получить поддержку от взрослых СУБД
И в чём заключается поддержка? Я не готов пока отказаться от заточки под базовые типы меток, если свалить всё в одну кучу и хранить всю геометрию в одном поле, сильно просядет скорость работы и увеличится io. Индексы по такой конструкции всё равно не заработают, для этого хранятся bounds. Я реально не представляю, где будет выигрыш для взрослых СУБД в контексте темы. В принципе, моя структура любое количество полигонов с любым количеством дырок покрывает, криволинейные фигуры только нет, но на это можно ещё табличек наделать, даже можно извратиться и сохранить объединение точки и полигона ))). |
|
|
|
|
>И в чём заключается поддержка? Я не готов пока отказаться от заточки под базовые типы меток, если свалить всё в одну кучу и хранить всю геометрию в одном поле, сильно просядет скорость работы и увеличится io.
В том то и дело что СУБД будет сама строить MBR по которому можно строить индексы и выполнять запросы. Если у тебя bounds хранятся в виде 4-х отдельных чисел (не помню уже, давно схему смотрел), то СУБД запросы по пространственному индексу будет выполнять эффективнее.
Плюс в довесок от СУБД получаете возможность представления данных в человеко-читаемом виде WKT. |
|
|
|
|
Рисую тут модель новую, исходя из того, что во "взрослых" СУБД можно сделать по-другому и оптимальнее. С многоязычностью (из другого проекта свистнул).
Прихожу к выводу, что надо попробовать слить метки, ссылки и категории в одну таблицу (то есть, их заголовки, геометрии и описания будут отдельно). Это и настройки видимости упростятся, и атрибуты упростятся, и запросы упростятся, и потенциально из-за наличия возможности ссылки на себя можно будет нехило так разных фич потом навыдумывать, вплоть до настоящей иерархии категорий и меток, вложенных меток и т.п.
То есть, в простейшем виде таблица заголовков меток-ссылок-категорий представляется в виде (представлено только относящееся к теме обсуждения):
id_object int identity,
id_category int null,
id_source int null,
m_name univarchar(400) not null
Здесь:
id_object - суррогатный идентификатор (наружу не торчит);
id_category - ссылка на категорию (эту же таблицу) для меток и ссылок, для категорий - пусто;
id_source - ссылка на метку (эту же таблицу) для ссылок.
Пример заполнения, чтобы было понятнее (значения в порядке id_object, id_category, id_source, m_name):
1, null, null, 'Первая категория'
2, null, null, 'Вторая категория'
3, 1, null, 'Метка в первой категории'
4, 1, null, 'Ещё метка в первой категории'
5, 2, null, 'Метка во второй категории'
6, 1, 5, '*Метка во второй категории' - это ссылка
7, null, null, 'Третья категория'
8, 7, 5, '*Метка во второй категории' - это ещё одна ссылка
Здесь * отметил ссылки, как они показываются в менеджере меток. То есть, 6 - это ссылка на метку 'Метка во второй категории' внутри категории 'Первая категория'.
Таким образом, для разных объектов дела обстоят так.
Категория: id_category пусто, id_source имеет произвольное значение (выше везде null).
Обычная метка: id_category заполнено ссылкой на категорию, id_source пусто (null).
Ссылка на метку: id_category заполнено ссылкой на категорию, id_source заполнено ссылкой на исходную метку.
Однако, в таблице должен быть уникальный ключ (индекс). Ибо:
Категории - уникальность по имени.
Ссылки - уникальность по паре (метка, категория).
Метки - уникальность по ...? Имени в категории?
В рамках данной структуры таблицы можно создать уникальный индекс по полям (id_category, id_source, m_name), и для ссылок писать в m_name одно и то же (например, "*"). Поскольку запрос по таблице всегда будет попадать в этот уникальный индекс (при запросе категорий условие id_category is null, при запросе меток для показа условие id_category is not null), проблем со скоростью быть не должно, главное чтобы поле id_category было первым, иначе будет адъ.
И всё бы зашибись, и уникальность для категорий и ссылок какая надо, но вот побочный эффект возникает в виде уникальности имён меток в категории. Как бы, порядок это всегда хорошо, но это требуется обдумать.
Данный вопрос уже поднимался, когда я делал метки в SQlite3. Тогда обошлись без уникальности по имени метки внутри одной категории (внутри разных категорий одноимённые метки могут быть, и они совершенно независимы), и таблицы категорий и меток сделались разными.
Источники одноимённых меток в одной категории с тех пор не изменились (так что просто скопирую этот текст из старой темы про SQlite3):
а) при импорте тех же KML-ек запросто может быть одинаковое имя у разных объектов (собственно с одинаковыми именами разные метки и залетают, пример - покрытие ESRI в соответствующей теме или обновление гугла, да собственно любые KML-ки, в которых автор не позаботился об уникальности объектов);
б) импорт трека или полигона, состоящего из нескольких обособленных кусков;
в) можно руками сделать метку с таким же именем, как у существующей метки в этой же категории (или перенести в другую категорию к существующей).
С тех пор пункт б) стал неактуален, так как реализована поддержка мультигеометрий. Так что остаётся а) импорт и в) создание или перенос меток руками.
С созданием и переносом руками, если честно, не вижу проблем. В крайнем случае юзер получит в лицо сообщение о неуникальности, и пойдёт переименовывать метку, или же наоборот скажет спасибо, потому что ошибся категорией при переносе метки. А при создании вообще можно добавлять что-нибудь типа (1) к имени. Это в худшем случае.
А вот с импортом есть вопросы. Как бы в том же kml у разных Placemark могут быть разные атрибуты (не настройка видимости, и даже не цвета, а более серьёзные), терять которые в общем случае при импорте не хочется. Отделять геометрию от метки и под один заголовок метки импортировать несколько Placemark из kml, возможно даже разного типа, в принципе тоже можно, но мне жалко юзеров, запутаются (хотя в той или иной степени всё равно придётся отделять геометрию от метки, потому что иначе даже wiki корректно не загрузить, в реальности там геометрия = точка+полигон).
Можно поступить как с потоками в NTFS, чтобы внутри одного имени файла скрывались не только filename.ext::DATA, но и filename.ext::1, filename.ext::2, и соответственно нумеровать метки искуственным образом. Аналогичный подход применяется во всех СУБД, которые поддерживают группировку хранимых процедур (там правда суть несколько другая, но в смысле именования - полная аналогия). В нашем случае, при известной прямоте рук, юзер даже не узнает о том, что имена меток такие вот псевдоуникальные, так как наружу будет торчать только оригинальное имя метки, а операции с метками выполняются по id_object из этой таблицы, который заведомо уникален (как суррогатный идентификатор). Это можно сделать как специальным суффиксом у метки, так и введением дополнительного поля типа int и заполнением его только для меток (что формально правильнее, если вообще в данной ситуации это слово применимо).
Повторюсь, затевается это по той причине, что без этого не слить все метки и категории в одну таблицу, что в свою очередь обуславливается приличным таким количеством приятных таких бонусов.
Какая цена вопроса? Всё просто.
Если этого (сливание в одну таблицу) не сделать:
а) чуть усложнится запрос получения перечня меток и ссылок в категории (потенциально в худшем случае придётся исполнять один запрос на метки, и один на ссылки, если сервер совсем будет тупить при исполнении одного большого универсального запроса);
б) утроится число таблиц для хранения видимости, настроек отображения и атрибутов (для категорий, ссылок и меток потребуются разные таблицы);
в) зато можно обеспечить уникальность ссылок и имён категорий без уникальности имён меток.
Есть правда ещё третий вариант, если уникальность по приведённому перечню полей не натягивать вообще (бардак форева). Но тут больше концептуальных вопросов типа "на кой нам идентичные записи в ссылках вида 11 1, 5, '*Метка во второй категории' и 12, 1, 5, '*Метка во второй категории'" и "чего мы хотим добиться от дублирующихся одноимённых категорий". Хотя, если на такие дубли раздать разные права для разных пользователей, то запах смысла на горизонте появляется. Вместе с тем, неуникальные имена категорий явственно вызывают когнитивный диссонанс, остальное уже как-то меньше. Может и правда обойтись без уникальности? И в списке категорий при создании новой метки выдавать дубли?
В общем, нужен совет, или хотя бы просто мысли вслух.
2Виктор: (де)сериализацию геометрии использовать буду, от неё есть польза, уже погонял тесты и даже прикрутил в SQLite3. |
|
|
|
|
Приаттачил экспорт модели SAS_Marks_DBMS в pdf.
Модель целиком лежит тут:
https://bitbucket.org/vasketsov/vsasas/src/8b41eb11ff9d92b3fd0fc3802db3106079083fa1/Resources/Model/?at=default
Модель открывается в SAP (Sybase) PowerDesigner 16.5.SP04.PL01.4535.
У кого нет - вот ссылки на Viewer:
https://s3.amazonaws.com/powerdesigner/PowerDesigner165SP04/PowerDesigner165SP04x86_Viewer.exe
https://s3.amazonaws.com/powerdesigner/PowerDesigner165SP04/PowerDesigner165SP04x64_Viewer.exe |
|
|
|
|
> 2Виктор: (де)сериализацию геометрии использовать буду, от неё есть польза, уже погонял тесты и даже прикрутил в SQLite3.
Ну хоть озвучил бы какие тесты гонял и в чем пользу видел, хоть примерно. Может я бы еще что-то подсказал. |
|
|
|
|
Тезисы отличия от модели для SQLite3 и некоторые особенности, на которые хочу обратить внимание, следующие:
1. Модель не предполагает привязку к конкретному типу СУБД. Требуется лишь учёт разных диалектов SQL и особенностей СУБД при формировании скриптов и выполнении запросов. То есть, работать должно на всех тех же самых СУБД, где умеем хранить тайлы. Однако по причине потенциально разной политики создания резервных копий (backup), настоятельно предлагается не хранить метки и тайлы в одной базе, а хранить в разных базах, пусть даже на одном сервере (экземпляре) СУБД.
2. Модель сложнее, чем для SQLite3 и несовместима с ней в плане структуры данных и запросов к СУБД. Основная причина этого - отсутствие типизации полей таблиц для SQLite3 и особенности разных СУБД, которые необходимо учитывать. Кроме того, добавлена многоязычность. Прочие отличия не принципиальны.
3. Заголовки категорий, меток и ссылок (дополнительных связей между меткой и другими категориями) слиты в одну таблицу g_object, в которой отсутствуют названия (поскольку они могут быть разные на разных языках). Соответственно, вообще говоря никакой уникальности по имени категории или имени метки в категории не будет. И даже для одной и той же метки и категории можно наделать много разных экземпляров ссылок между ними. Это сделано по ряду причин для упрощения структуры БД. Уникальность будем пытаться (в некотрых случаях) реализовывать на клиенте. Но вместе с тем, отсутствие указанной уникальности не будет являться ошибкой, а будет допустимой штатной ситуацией.
4. Для атрибутов и их значений добавлены ЕИ (единицы измерения). Справочник ЕИ (таблица u_unit) ссылается сам на себя, что позволяет реализовать категории ЕИ прямо поверх ЕИ, и в атрибутах использовать категорию ЕИ, а в значениях - ЕИ из данной категории. Введено для повышения наглядности значений атрибутов в метках, чтобы некоторые поля преобразовывались не в отдельные значения отдельных атрибутов, а пристёгивались к другим атрибутам в качестве ЕИ. Хотя, не факт, что это всегда получится, если например ЕИ будет при импорте идти раньше чем собственно значение. Тогда руками. Или чего полезного наколдуем по мере возникновения проблем.
5. Многоязычность реализована для разных сущностей в БД по-разному. Прежде всего, различия связаны с особенностями способов доступа к разным сущностям. Общим является справочник языков (таблица g_language), к которому пристёгивается рядом табличка с кодами i_lang_code. Служат они для идентификации языка (получения id_language по его коду). На клиенте используется код текущего языка (ru,uk,.. из ISO 639) - вот в справочнике языков (с учётом дополнительных кодов ISO 639 и ГОСТ 7.75-97) должны быть записи для этого языка. Если нет - будем создавать их автоматически.
Многоязычность включается руками как отдельная опция. Пока она не включена, никаких видимых изменений не будет (по крайней мере пока что так предполагается).
6. Для категорий и меток описание хранится отдельно (в таблице i_object) и зависит от языка. Однако реализовать запрос, который вытащил бы название и описание метки исходя из предпочтений пользователя (перечня понимаемых им языков, их приоритета, фактического наличия данных на этих языках) представляется нереальным ввиду того, что эту операцию надо будет делать много и часто, любой сервер просто упадёт под такой нагрузкой.
Поэтому реализовано следующим образом. При создании метки (автоматически) определяется язык, на котором написано её название и описание (для этого задуманы поля в справочнике языков). Если язык не определился или многоязычность отключена - берётся язык текущего пользователя (возможно, здесь стоит брать некий фиксированный язык организации, а не текущего пользователя). Ссылка на него кладётся в заголовок метки. Этот язык нарекается языком метки. Именно для него сохраняется название и описание метки. При чтении метки из БД, если многоязычность включена, приоритетным является язык текущего пользователя, но если многоязычность отключена или для языка текущего пользователя нет названия и описания метки, будет браться название и описание на языке метки. То есть, даже при включении многоязычности, покуда не поредактировать руками на кириллице метки из китая, даже для доморощенных пользователей там будут иероглифы. Что представляется логичным. Для категорий аналогично. То есть, для основных объектов базы меток будет два языка. В принципе, расширение до 3 языков (например, китайский как национальный язык источника информации, английский как международный для коммуникации между разными подразделениями и идентификации меток в сообщениях, русский как язык текущего пользователя) возможно и без изменения структуры БД и ещё будет терпимо по скорости работы (хотя старый Sybase ASE 12.0 уже бы "умер" и потребовал abstract plan руками). Больше уже просто будут тормоза при чтении меток на любых СУБД.
7. Многоязычность ЕИ (единиц измерения) реализована как отдельное опциональное описание краткого и полного названия ЕИ. В отличие от меток, это чисто информационные поля, не несущие смысловой нагрузки, не отображающиеся на карте (только опционально в хинтах у меток). Поэтому ЕИ на языке метки не имеет особенного смысла (зачем видеть в хинтах метры на китайском, а не "м"?). Так что ЕИ берётся на языке текущего пользователя, если его нет - значит берётся название собственно из справочника ЕИ, что там будет - то и будет. Может быть, например, международное название ЕИ.
8. С названиями атрибутов меток и с текстовыми значениями атрибутов меток (таблицы a_param, a_item и a_value) в справочнике атрибутов и в перечне значений для объектов ситуация ровно аналогичная многоязычности для ЕИ (таблицы i_param, i_item и i_value). Если нет значения на языке текущего пользователя, берётся значение по умолчанию, что бы там ни было.
9. Настройка видимости категорий и меток работает по заголовкам и слита в одну таблицу v_show. Там ещё надо будет возможно заменить пару полей m*_zoom (диапазон видимости) на одно поле типа int, всё равно индекс по ним работать скорее всего не будет (при запросе попадания зума в диапазон от min до max), зато получим возможность задания любого перечня зумов для отображения (все зумы отлично пакуются в один int, битовые операции над int поддерживают все поддерживаемые СУБД). Но замена полей zoom на int ещё требует анализа необходимости, решение ещё не принято.
10. Настройки отображения меток (цвета и т.п.) по сравнению с моделью для SQLite3 претерпели изменения с целью упрощения структуры. Справочник вариантов оформления границ полилиний и заливок полигонов слит в одну таблицу s_geometry (возможно, до релиза я её переименую). Она по-прежнему формируется автоматически при сохранении меток. Однако теперь из настроек (таблица v_object) в справочник идёт две ссылки, одна для полилиний и границ полигонов, другая - для заливки полигонов. Поскольку настройки отображения привязаны к заголовкам меток и категорий, кроме уменьшения числа таблиц, по-прежнему есть возможность для категории установить оформление всех меток и не сохранять его для каждой метки. А также по-прежнему остаётся возможность наследования оформления метки от владельца метки.
11. Для экспорта и импорта меток без потерь сделана таблица m_raw. В модели для SQLite3 для этого была таблица m_descript, но поскольку здесь поля в таблицах строго типизированы, такой способ уже не прокатит. Поэтому значения при импорте меток будут (смогут) падать в m_raw как есть, собственного типа (в крайнем случае - как строка). Заполнение m_raw опционально.
12. Таблицы g_plugin и p_object будут хранить перечень плагинов для отображения меток и их привязку к категориям меток. Эта функциональность задумана ещё с времён реализации меток для SQLite3, там тоже есть таблицы по это дело, но пока не реализовано.
13. Таблицы g_msg и i_msg задуманы для двух вещей. Первое - хранение многоязычных строк и сообщений об ошибках на уровне СУБД, если они будут необходимы, например, для использования в хранимых процедурах и триггерах. Второе - для построения произвольного количества различных справочников (без особых сложностей). Возможно, к релизу добавлю им ещё атрибуты.
14. Расширение объектов для меток (таблица m_mark) сделана таким образом, что можно будет вытащить все метки за один запрос, чего нельзя было сделать в модели для SQLite3. Возможно, эта таблица претерпит некоторые изменения к релизу, потому что есть некоторые мысли на тему компонования bounds в одно поле (вероятно, взлетит это не на всех поддерживаемых СУБД), а также поддержки нескольких картинок для одной метки, но пока что это лишь фантазии.
Вот как-то так. |
|
|
|
(0015847)
|
|
vasketsov
|
05-05-2015 10:45
(edited on: 05-05-2015 11:05) |
|
>какие тесты гонял
У меня в SQLite3 есть признак, как сохранять новую геометрию, по старому или через твой (де)сериализатор. То есть, уже сохранённое читается исходя из того, как фактически сохранено (там есть ещё поле для типа геометрии, кроме BLOB-а с геометрией), но при создании и изменении можно навалить в базу геометрии нового формата.
Так вот тест был очень простой: я импортировал всю свою базу меток в SQLite3 заново, уже в новый формат геометрии. Ну и просто посмотрел счётчики производительности при чтении меток в разных местах карты.
На POI это разумеется никакого влияния не оказало (парсер прикручен только к полилиниям и полигонам). Влияние для прочих геометрий - в пределах погрешности при выполнении сетевых операций и при выполнении чтения с диска с локальной базы SQLite3. В общем, заметной разницы нет.
Поскольку перевести движок меток SQlite3 только на однопроходное чтение всех меток было бы слишком сложной задачей только лишь для игрового теста, я этого не делал. Так что всё равно чтение полилиний осуществлялось отдельно от чтения полигонов, а также отдельно от ссылок на них (правда, ссылки я вычистил, их не было). А в случае применения только парсера с новым типом геометрии возможно было бы однопроходное чтение. Так что тест весьма неуклюж. Но зато близок к реальности.
На мультигеометриях твой парсер даёт выигрыш из-за того, что не надо испускать вторичные запросы для вытаскивания всей мультигеометрии. Хотя на локальном SQLite3 это сидит всё в его кэше и выполняется быстро. По сетке тоже проблем не было. Но у меня мультигеометрий немного, в основном это полигоны из вики и росреестра. Подавляющая часть полигонов - это границы снимков и треки.
С треками ситуация имеет особенность: треки мегадлиннющие. Соответственно, поскольку я хранил связные куски геометрии целиком, парсить их в поисках разделителя не надо было (раньше просто копировался кусок памяти - и всё). Соответственно, как только возникает необходимость найти в целиковом треке разделитель и разделить его на куски памяти, так сразу возникает вопрос парсера BLOB-а со всеми вытекающими тормозами. Но таких супердлинных мультитреков у меня немного. И погоды они не делают совершенно.
В общем, для локального SQlite3 прикручивание парсера было скорее тренировкой.
>и в чем пользу видел
Польза будет для СУБД.
Без подобного парсера нельзя свести все возможные геометрии в одну таблицу, чтобы можно было бы вытащить все метки одним запросом. А число запросов для СУБД является критичным, потому что так устроено клиент-серверное взаимодействие. Это уже не локальный SQlite3.
|
|
|
|
|
> Польза будет для СУБД.
Проверь на нормальной СУБД с поддержкой пространственных расширений и индексов вот такие селекты:
'Select id as id, AddData as caption, asWKB(GeoData) as geom from sas_houses where MBRIntersects(GeoData, LineString(Point(:left,:top),Point(:right,:bottom)))'
Чисто теоретически, они должны выполнятся быстрее, чем запросы со сравнением координат bounds |
|
|
|
(0015851)
|
|
vasketsov
|
05-05-2015 11:38
(edited on: 05-05-2015 11:41) |
|
>СУБД с поддержкой пространственных расширений и индексов
Кроме PostgreSQL никого и не знаю толком. Но поизучаю ввиду желания слить bounds в одно поле.
>должны выполнятся быстрее, чем запросы со сравнением координат bounds
Ты немного путаешь разные вещи.
Для одной конкретной записи:
1. Проверка bounds - сравнение 4 полей даже сейчас.
2. А проверка пересечения для геометрии будет расти с увеличением длины геометрии.
Так что выигрыш возможен только за счёт идеально работающего индекса. Ибо в самом идеальном случае индекс по геометрии при чтении как раз и будет равносилен голому bounds и сравнению диапазонов. А при записи индекс потребуется актуализировать. А bounds у нас уже известно при сохранении.
В общем, проверять пока не буду, ограничусь академическим изучением способов хранения bounds на разных СУБД, авось и получится чего.
То, что ты имеешь в виду, я понимаю несколько иначе. Откуда может взяться ускорение при чтении вообще, а не конкретной записи? Оно будет, если геометрия сильно разрежена, и bounds не даёт реального представления о том, где именно находится объект. Например, два сильно удалённых друг от друга куска одного мультиполигона. То есть ускорение будет оттого, что кучка меток просто не прилетит из СУБД в рисовалку.
Но не оттого, что сам по себе запрос будет выполняться быстрее. То есть, запрос может быть даже будет выполняться медленнее, но в итоге рисоваться всё будет быстрее. Такое возможно и даже сильно вероятно. В конце концов, ради этого такие вещи как пространственные типы и индексы и затевались.
Но у отказа от bounds в пользу пространственных индексов и потенциальной привязке только к СУБД с их поддержкой я вижу достаточное количество минусов, чтобы пока не идти по этому пути. Возможно, в будущем и сделаем это как опцию, но только с сохранением bounds и только для некоторых СУБД, где такое возможно (поскольку это потребует только внесения изменений в запросы с клиента). В частности, сейчас в тайлохранилище в СУБД тоже достаточно мест, где используется специфика СУБД (upsert-ы и т.п.) для оптимального выполнения запросов. Так что неприятия к использованию специфики СУБД, ускоряющей работу с ней, у меня нет.
|
|
|
|
|
> Кроме PostgreSQL никого и не знаю толком.
В MySQL точно есть и работает.
>Ты немного путаешь разные вещи.
Это ты путаешь. Поверь.
> А проверка пересечения для геометрии будет расти с увеличением длины геометрии.
Не будет. Там идет именно проверка Bounds:
MBRIntersects проверяет именно пересечение двух минимальных ограничивающих прямоугольников, то есть Bounds в твоей терминологии. Причем проверка эта выполняется по пространственному индексу в разы быстрее чем просто по 4-м полям, а сама геометрия для этого не прасится.
>Но не оттого, что сам по себе запрос будет выполняться быстрее.
Именно, что быстрее. Когда в базе будет пару миллионов геометрий отбор по пространственному индексу будет гораздо быстрее.
>привязке только к СУБД с их поддержкой я вижу достаточное количество минусов
Вот это да, большой минус. |
|
|
|
|
>Это ты путаешь. Поверь
Охотно верю. Ещё не разбирался с этим.
>Там идет именно проверка Bounds
Если так - значит я был не прав. И как следствие - уменьшение кучки выкачанных разреженных меток мы не получим.
>сама геометрия для этого не прасится
Чудес не бывает. Если bounds берётся из индекса по полю геометрии, значит при сохранении или изменении геометрии сервер должен обновить этот индекс, а для этого всё равно необходимо найти bounds по геометрии при insert или update (а самое обидное - что и при delete надо индекс трогать, хотя казалось бы).
>выполняется по пространственному индексу в разы быстрее чем просто по 4-м полям
Вот конкретно в этом я ничуть не сомневаюсь. Собственно, это и есть причина желания запихнуть bounds в одно поле и работать с ним как с пространственным типом.
>Когда в базе будет пару миллионов геометрий отбор по пространственному индексу будет гораздо быстрее
Если я тебя правильно понял, то замена отдельных полей bounds на одно поле пространственного типа с индексом по нему как раз даст тот же эффект (оптимизация при работе с пространственными типами), но позволит сократить время на вставку и измененение геометрии на сервере, так как индекса по сложной геометрии не будет, а будет более простой индекс по известному прямогуольнику bounds, который тем не менее сливанием полей удастся "ускорить" (оптимизацией при работе с пространственными типами). |
|
|
|
|
> Если я тебя правильно понял, то замена отдельных полей bounds на одно поле пространственного типа с индексом по нему как раз даст тот же эффект
Даст, но только опять же при наличии ровно такого же пространственного индекса уже для этого поля со всеми накладными расходами на его изменение.
>но позволит сократить время на вставку и измененение геометрии на сервере, так как индекса по сложной геометрии не будет, а будет более простой индекс по известному прямогуольнику bounds
ИМХО экономия на спичках и излишняя денормализация структуры базы. Чтения выполняются обычно гораздо чаще изменений. Но в целом рабочий вариант. |
|
|
|
|
Перетряхнул метки:
1. Временно выпилен IMarkId; по завершению работ над данным тикетом предполагается вернуть его к жизни; а может быть и нет.
2. Фабрики (меток и категорий) по объектам системы не размножаются, а берутся из подсистемы меток, которая и так пропихивается, где требуется.
3. Из подсистемы меток наружу торчит только одна БД, для SML всё скрыто внутри.
4. Вроде бы локализовано всё, что относится к SQLite3 и Sml; поскольку идентификатор объектов в СУБД планируется типа bigint, а для SQLite3 и Sml он типа int, то даже если что-то и осталось, то это обнаружится и исправится.
5. Проверяется принадлежность метки к конкретной БД меток; раньше была менее строгая проверка.
Из известных проблем - временно не работает экспорт в Sml. |
|
|
|
|
|
С целью унификации интерфейсов, классов и кода вообще - заменил тип идентификатора для SQLite с Integer на Int64. Тем более что для SQLite как раз он базовым для идентификаторов и является. Поле "Код" тоже заменил на Int64. В модели поправил. В скриптах изменения не нужны. Для СУБД поле "Код" тоже увеличено с Integer до Int64. |
|
|
|
(0017102)
|
|
sheavy
|
|
24-03-2016 11:35
|
|
|
Просто хотел проголосовать за этот инцидент. Ждем-с |
|
|
|
|
|
Попробую выкроить время и довести до ума на новогодних каникулах. |
|
SAS_MARKS.pdf (89,976) 22-12-2014 19:32