1

Мне нужно представить размеры квадрата прямоугольника в базе данных SQL Server 2008. Мне нужно будет выполнять запросы на основе расстояния между разными точками и общей площадью поверхности.Какова относительная производительность 1 столбца геометрии против 4 десятичных знаков в Sql Server 2008?

Будет ли мое исполнение лучше использовать геометрический тип данных или 4 десятичные столбцы? Почему?

Если геостатический тип данных не является необходимым в этой ситуации, какая сложность геометрической формы потребуется для использования геостационарного типа данных?

+0

Похоже, что у вас есть достаточно информации, чтобы иметь возможность создавать репрезентативные данные и запросы и определять, какая из них лучше - мы этого не делаем. Вопросы производительности в целом не отвечают в реферате. –

+0

@Damien_The_Unbeliever, я согласен, что на конкретные вопросы производительности нужно отвечать в их конкретном контексте, но я думаю, что сравнение скорости работы с двумя разными типами является достаточно общим для этого вопроса. Можно было бы оправдаться, говоря: «В общем, быстрее быстрее запрашивать столбец' int', чем '' varchar (255) 'column, и я действительно не вижу, как это отличается. – smartcaveman

+0

В основном, потому что я понятия не имею *, что * вы планируете хранить в этих 4 десятичных столбцах - вы начали с разговоров о четырехстороннем - если бы я собирался хранить один как десятичный знак, я бы подумал, что буду сохраняя 4 координаты, поэтому потребуется 8 столбцов. У вас, очевидно, есть какой-то дизайн, который означает, что 4 столбца будут работать для вашей конкретной ситуации, но я не знаю, что это за дизайн ... –

ответ

-4

Geometry тип данных Пространственное и decimal нет,

Пространственные против непространственных данных

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

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

Можно игнорировать различия между пространственными и не пространственными данными. Однако существуют фундаментальные различия между ними: пространственные данные, как правило, многомерны и автокоррелированы. не пространственные данные, как правило, одномерны и независимы.

Эти различия помещают пространственные и не пространственные данные в различные философские лагеря с далеко идущими последствиями для концептуальных, обработки и хранения. Например, сортировка - это, пожалуй, самая распространенная и важная функция обработки не пространственных данных. Непонятно, как даже сортировать данные локации, так что все точки заканчиваются? их ближайших соседей.

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

Вот несколько больше, если вы заинтересованы: http://www.ncgia.ucsb.edu/giscc/units/u045/u045_f.html

Heres ссылку я нашел о Бенчмаркинг пространственных хранилищ данных: http://hpc.ac.upc.edu/Talks/dir08/T000327/paper.pdf

+0

вопрос о производительности действительно - но очень четкое сравнение между типами –

+0

Zee Tee, я уже понимаю все, что вы только что опубликовали. Мой вопрос заключается не в различии между 'geometry' и' decimal', а между относительной эффективностью использования их в приложении. Моя объектная модель представляет данные как пространственные, но мой пример использования достаточно прост, чтобы я мог эффективно использовать 4 'десятичных' столбца для представления модели. Если производительность не была проблемой, я бы использовал 'geometry', потому что это более точное представление, но я готов написать дополнительный код для своих запросов, если есть значительная разница в производительности. – smartcaveman

+0

Heres ссылка, которую я нашел о Benchmarking Spatial Data Склады: http://hpc.ac.upc.edu/Talks/dir08/T000327/paper.pdf –

0

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

Поскольку каждая БД вопрос может относиться к соотношению вставок v выбирает/известково-х

+0

Единственный пользователь, который будет создавать записи, содержащие эти столбцы, будет администратором, но они будут запрошены всеми пользователями. (Намного больше выбирает + calcs, чем вставки) – smartcaveman

+0

Тогда я бы подумал, что использование встроенных функций должно дать вам лучшую производительность.У меня нет доказательств, так что было бы интересно посмотреть, что люди ответят на это :-) –

+0

Я бы подумал наоборот. Мое рассуждение состоит в том, что мой вариант использования находится на крайнем нижнем конце поддерживаемой сложности для типа данных. Инфраструктура типа данных позволяет многое, и вполне возможно, что стоимость создания экземпляра данных может быть больше, чем встроенная оптимизация логики запроса. – smartcaveman

1

Я не использовал геометрию типа данных, и никогда не было причин, чтобы прочитать на нем. Несмотря на это, мне кажется, что если вы просто выполняете базовую арифметику на простом геометрическом объекте, обычные старые типы данных SQL должны быть достаточно эффективными, особенно если вы вбрасываете некоторые расчетные столбцы для часто используемых вычислений.

Например:

--DROP TABLE MyTable 
CREATE TABLE MyTable 
(
    X1 decimal not null 
    ,Y1 decimal not null 
    ,X2 decimal not null 
    ,Y2 decimal not null 
    ,Area as abs((X2-X1) * (Y2-Y1)) 
    ,XLength as abs((X2 - X1)) 
    ,YLength as abs((Y2 - Y1)) 
    ,Diagonal as sqrt(power(abs((X2 - X1)), 2) + power(abs((Y2 - Y1)), 2)) 
) 

INSERT MyTable values (1,1,4,5) 
INSERT MyTable values (4,5,1,1) 
INSERT MyTable values (0,0,3,3) 

SELECT * from MyTable 

Гадкий расчеты, но они не будут выполнены, если и пока они на самом деле ссылки (или, если вы не хотите индексировать их). У меня нет статистики, но выполнение тех же операций с помощью типа данных Geometry , вероятно, означает доступ к редко используемым математическим подпрограммам, возможно встроенным в системные сборки CLR, и я просто не вижу, что это значительно быстрее, чем арифметические подпрограммы SQL ,

Я просто взглянул на BOL на тип данных Geometry. (a) Zounds! (b) Круто! Просмотрите записи в разделе «Справочник по типу данных геометрии» (online here, но вы хотите посмотреть расширенное древовидное представление в этой записи.) Если это тот тип функциональности, который вам понадобится, обязательно используйте тип данных геометрии, но для простой обработки я придерживался типов данных knucklescraper.