SQL-запрос для использования точки в полигоне PostgreSQL
Сложная часть ОО состоит в том, какие вещи следует объединить в один объект. Как вы уже упоминали об эволюции вашего исходного кода, здесь у вас есть простое руководство о том, как развивать ваш исходный код в направлении разработки ОО:
"Put stuff together that changes together."
Когда два фрагмента кода имеют одинаковые скорости изменения, это намек на то, что они должны быть помещены в один и тот же объект. Когда скорости изменения различны, рассмотрите возможность размещения их в разных объектах.
Это также известно как «Изменение скорости».
Если вы будете следовать этому руководству, ваш код будет естественно развиваться в направлении хорошего дизайна ОО. Почему?
Фрагменты кода часто имеют одинаковые скорости изменения, если они получают доступ к общему представлению. Каждый раз, когда меняется представление, все части кода, которые его используют, должны меняться сразу. Это одна из причин, по которой мы используем объекты в качестве модулей для инкапсуляции представления. Отделение интерфейса от реализации также имеет смысл в этом руководстве - реализация меняется чаще и, следовательно, имеет более высокую скорость изменения.
Если класс имеет стабильную часть и нестабильную часть, это разница в скорости изменения, которая предполагает перемещение стабильной части в (возможно, абстрактный) базовый класс.
Точно так же, если класс состоит из двух частей, которые изменяются одинаково часто, но в разное время или в разных направлениях (то есть по разным причинам), то это снова предполагает рефакторинг класса.
Иногда заменяют «класс» на «метод». Например, если одна строка метода может меняться чаще, чем остальные - возможно, именно эта строка создает новый экземпляр объекта и содержит имя его класса - рассмотрите возможность перемещения его в свою собственную подпрограмму. Тогда подклассы могут легко повлиять на их изменение, переопределив его.
Я сталкивался с этой концепцией в C2 wiki много лет назад , но с тех пор я редко видел, чтобы она использовалась. Я нахожу это очень полезным. Он выражает некоторую основополагающую мотивацию объектно-ориентированного дизайна. Конечно, поэтому это ослепительно очевидно.
Это изменения программы. Есть еще одно ощущение скорости изменения - вы не хотите, чтобы переменные экземпляра изменялись с разной скоростью, или, скорее, это признак потенциальных проблем. Например, в графическом редакторе не следует хранить рисунки и маркеры в одной коллекции, потому что цифры меняются раз в минуту или раз в час, а маркеры меняются раз в секунду или раз в минуту.
В более широком представлении вы хотите, чтобы система могла достаточно быстро меняться, чтобы не отставать от изменений в бизнесе.
PS: другой принцип, которому вы должны следовать, это «Закон Деметры», то есть объект должен говорить только со своими друзьями. Друзья: вы, переменные экземпляра, параметры, локальные объекты и члены дружественных коллекций, но не глобальные и статические переменные.
2 ответа
Многоугольник - это фундаментальный тип Postgres, над которым PostGIS строит. Вы включаете столбцы геометрии с помощью функции PostGIS и выбираете AddGeometryColumn (...) . В противном случае вы работаете с прямыми многоугольниками:
=> create table gt (id int, space polygon);
=> insert into gt values (1, '((2,2),(3,4),(3,6),(1,1))');
INSERT 0 1
=> select point(space) from gt where id = 1;
point
-------------
(2.25,3.25)
(1 row)
Это центральная точка многоугольника
=> select circle(space) from gt where id = 1;
circle
--------------------------------
<(2.25,3.25),1.93994028704315>
(1 row)
Это минимальная ограничивающая окружность многоугольника, выраженная в виде круга Постгреса . Все геометрические операторы описаны здесь: http://www.postgresql.org/docs/8.3/interactive/functions-geometry.html Базовый многоугольник не имеет данных проекции, SRID и т. Д., так что, если он работает с PostGIS, вероятно, это просто предустановки по умолчанию и удача. Но, конечно, есть масса случаев, когда вам просто нужна геометрия в суб-геопространственном масштабе.
Хорошо, как ни странно, я обнаружил, что следующий гораздо более простой синтаксис работает:
insert into tbl_test (poly) values ('(0,0),(0,10),(10, 10), (0, 0)')
select * from tbl_test where poly @> '(2, 8)'
Но я изо всех сил пытаюсь понять разницу между этими наборами функций и операторов. Использует ли этот более короткий синтаксис (который на самом деле не совместим с OpenGIS) те же пространственные индексы и т. Д.?