Это бы вызвало либо повторный update одного из документов
либо необходимость руками управлять идентификаторами.
И то и другое не слишком красиво.
Кроме того, цикл предполагает наличие упорядочения в обходе разных классов.
А поскольку в самой задаче такое упорядочение не заложено, оно будет привнесено искусственно, а значит обязательно вылезет потом в виде ограничений/издержек.
Да, кстати. Предположим что у вас более 2, пусть 3 класса, описывающих то, что когда-то было одной таблицей. Какова будет топология взаимоотношений между ними?
Вот вы нарисовали одну ссылку из psc в xyz. Пусть есть еще qwe.
Циклы делать нехорошо по понятным причинам. Звезда?
Ок, у нас ссылки psc->xyz и psc->qwe. Рассмотрим select, в котором задействованы только колонки из xyz и qwe. Опять не обойтись без центрального узла с его ссылками.
Зачем пихать в индекс идентификаторы нескольких документов,
если это один документ? Вместе с идентификатором документа придётся хранить и идентификатор таблицы/класса. Конечно можно, но зачем, если можно обойтись без этого?
… is like sleeping with your sister. Sure she's a great piece of tail with a blouse full of goodies, but it's just illegal.
Конкретный запрос — построение статистики совместного распределения JKH
при фильтрации по пространственному критерию не требует дополнительного чтения.
В том и суть, если я знаю как собираюсь искать, то имею возможность настроить данные так, чтобы избежать чтения ненужного.
Почему пытаюсь, в статье описано как сделать это без дополнительного чтения.
И зачем городить огород с разными классами, когда можно всё сделать в рамках старого доброго SQL?
Подвох здесь незатейливый.
Конечно, логично прицепить пространственный индекс к кому классу, который содержит координаты (twomass_psc). Но тогда при фильтрации по пространственному критерию придется сделать лишнее чтение, чтобы получить ссылку на класс со светимостями (twomass_xyz).
Делать (дублировать) пространственный индекс к twomass_xyz нелогично.
Хранить в пространственном индексе ссылки на все экземпляры классов — некрасиво.
Да и позволит ли это СУБД.
Иметь один индекс на всех — а кто будет синхронизировать идентификаторы в разных классах?
Никто ведь не запрещает и в реляционной парадигме иметь разные таблицы (twomass_psc,twomass_xy...) и join-ить их при необходимости. Но возникнут те же самые вопросы.
Вообще, противостояние табличных и сетевых СУБД длится столько же, сколько существуют сами СУБД. Это как противостояние брони и снаряда.
Я использовал алгоритм A. R. Butz, «Alternative Algorithm for Hilbert's Space-Filling Curve», IEEE Trans. Comp., April, 1971, pp 424-426.
Насколько понимаю, это компромисс между числом проходов и объемом предвычисленных данных.
Симпатично. Проблема с этой кривой в том, что ее невозможно одним разрезом разделить на два непрерывных интервала значений. А значит работать с ней крайне неудобно алгоритмически. Т.е. можно разделить по диагонали, но на самой диагонали окажутся точки с обеих половин.
либо необходимость руками управлять идентификаторами.
И то и другое не слишком красиво.
Кроме того, цикл предполагает наличие упорядочения в обходе разных классов.
А поскольку в самой задаче такое упорядочение не заложено, оно будет привнесено искусственно, а значит обязательно вылезет потом в виде ограничений/издержек.
Вот вы нарисовали одну ссылку из psc в xyz. Пусть есть еще qwe.
Циклы делать нехорошо по понятным причинам. Звезда?
Ок, у нас ссылки psc->xyz и psc->qwe. Рассмотрим select, в котором задействованы только колонки из xyz и qwe. Опять не обойтись без центрального узла с его ссылками.
Но сам так делать не стану и никому не посоветую.
если это один документ? Вместе с идентификатором документа придётся хранить и идентификатор таблицы/класса. Конечно можно, но зачем, если можно обойтись без этого?
Так же как и в строчных СУБД (и в колоночных, кстати).
Поэтому при фильтрации по индексу нет необходимости делать дополнительное чтение, чтобы узнать ссылку на экземпляр нужного класса.
Уж не знаю как и разжевывать.
при фильтрации по пространственному критерию не требует дополнительного чтения.
В том и суть, если я знаю как собираюсь искать, то имею возможность настроить данные так, чтобы избежать чтения ненужного.
И зачем городить огород с разными классами, когда можно всё сделать в рамках старого доброго SQL?
Конечно, логично прицепить пространственный индекс к кому классу, который содержит координаты (twomass_psc). Но тогда при фильтрации по пространственному критерию придется сделать лишнее чтение, чтобы получить ссылку на класс со светимостями (twomass_xyz).
Делать (дублировать) пространственный индекс к twomass_xyz нелогично.
Хранить в пространственном индексе ссылки на все экземпляры классов — некрасиво.
Да и позволит ли это СУБД.
Иметь один индекс на всех — а кто будет синхронизировать идентификаторы в разных классах?
Никто ведь не запрещает и в реляционной парадигме иметь разные таблицы (twomass_psc,twomass_xy...) и join-ить их при необходимости. Но возникнут те же самые вопросы.
Вообще, противостояние табличных и сетевых СУБД длится столько же, сколько существуют сами СУБД. Это как противостояние брони и снаряда.
XYZ-светимости в разных диапазонах
Ra|Dec — координаты
Где пространственный индекс будет?
Насколько понимаю, это компромисс между числом проходов и объемом предвычисленных данных.
Либо резать на 4 части. В двумерном случае, на 256 частей в 8-мерном.