Комментарии 12
>от варианта с PostGis я отказался заранее без сравнения исключительно по этическим соображениям
с этого места поподробнее?
с этого места поподробнее?
А как увидел, что для установки postGis нужно что-то ещё устанавливать, так сразу и подумал: «ну вот, начинается». )
а вообще, если подальше от этических соображений, то, во-первых, я на c# пишу и соответственно возникает вопрос о наличии провайдера и его работоспособности (например с firebird однажды работал и там провайдер местами глючил (версию не спрашивайте, не помню)), потом SQL Server просто более знакомая среда, mySQL — тоже эксперементировал, ну и наконец, место хранения и его характеристики для меня важности не представляли — просто нужно было место, куда геометрию складывать.
а с postGIS я обязательно, будет время, ознакомлюсь.
а вообще, если подальше от этических соображений, то, во-первых, я на c# пишу и соответственно возникает вопрос о наличии провайдера и его работоспособности (например с firebird однажды работал и там провайдер местами глючил (версию не спрашивайте, не помню)), потом SQL Server просто более знакомая среда, mySQL — тоже эксперементировал, ну и наконец, место хранения и его характеристики для меня важности не представляли — просто нужно было место, куда геометрию складывать.
а с postGIS я обязательно, будет время, ознакомлюсь.
>пространственный индекс реализован в SQL Server на основе B-деревьев
Я не уверен, что курсив в начале статьи ваш, но все равно спрошу. Странно как-то с этими деревьями, в руководстве PostGIS, да и Википедии
«B-Trees are used for data which can be sorted along one axis; for example, numbers, letters, dates. GIS data cannot be rationally sorted along one axis (which is greater, (0,0) or (0,1) or (1,0)?) so B-Tree indexing is of no use for us.»
postgis.refractions.net/documentation/manual-1.3/ch04.html#id2743643
описание B-деревьев на сайте MS больше похоже на R-деревья
technet.microsoft.com/en-us/library/bb964712.aspx
глючит MS похоже, зачем одно другим называть…
Я не уверен, что курсив в начале статьи ваш, но все равно спрошу. Странно как-то с этими деревьями, в руководстве PostGIS, да и Википедии
«B-Trees are used for data which can be sorted along one axis; for example, numbers, letters, dates. GIS data cannot be rationally sorted along one axis (which is greater, (0,0) or (0,1) or (1,0)?) so B-Tree indexing is of no use for us.»
postgis.refractions.net/documentation/manual-1.3/ch04.html#id2743643
описание B-деревьев на сайте MS больше похоже на R-деревья
technet.microsoft.com/en-us/library/bb964712.aspx
глючит MS похоже, зачем одно другим называть…
И еще один вопрос, про клиентуру.
Кто сейчас в роли клиента для пространственных данных хранимых подобным образом может выступать?
Кто сейчас в роли клиента для пространственных данных хранимых подобным образом может выступать?
Трудно сказать. Вообще все и в то же время никто. )
Эти данные, например, может купить фирма, занимающаяся разработкой карт для gps-устройств, а затем перегнать их во внутренний формат.
Геодезические фирмы можно вспомнить, но карты для конкретных работ они берут у государства и ему же сдают обновленные. Не знаю, как везде, но кое-где фрагменты карт (т.н. планшеты) хранятся в формате гео-tiff.
Эти данные, например, может купить фирма, занимающаяся разработкой карт для gps-устройств, а затем перегнать их во внутренний формат.
Геодезические фирмы можно вспомнить, но карты для конкретных работ они берут у государства и ему же сдают обновленные. Не знаю, как везде, но кое-где фрагменты карт (т.н. планшеты) хранятся в формате гео-tiff.
Все хорошо, только имейте в виду, теперь, после выхода Enitiy Framework для майкрософт именно это технология стала приоритетной в обасти доступа к данным. То есть, майкрософт теперь рекомендует использовать Enitiy Framework, а не Linq to SQL.
Я не хочу, сказать, что Linq to SQL мертв, но вряд ли msft будет одинаково развивать оба эти направления, у них слишком много общего.
Так что, при решении, в изучение какой технологии инвестировать свое время, имейте это в виду.
blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
visualstudiomagazine.com/blogs/weblog.aspx?blog=2990
Я не хочу, сказать, что Linq to SQL мертв, но вряд ли msft будет одинаково развивать оба эти направления, у них слишком много общего.
Так что, при решении, в изучение какой технологии инвестировать свое время, имейте это в виду.
blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
visualstudiomagazine.com/blogs/weblog.aspx?blog=2990
спасибо, обязтаельно посмотрю.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Конечно, это некрасиво, что тут говорить.
Я смотрю на это спокойно, только потому, что не подсел ни на первую технологию, ни на вторую. Поигравшись вдоволь еще с LINQ Preview, мы решили его не использовать, а остановились на своем собственном «полумаппере», который нас в общем-то устраивает.(и который завсит только от ado.net)
Сейчас по идее можно было бы начинать щупать EF, но больно уж он тяжеловесно выглядит.
Вобщее, при увеличении сложности приложения, смысл использования мапперов стремится к 0. Да, для прототипирования самое оно, но в продакшене лучше быть как можно ближе к SQL:)
Я смотрю на это спокойно, только потому, что не подсел ни на первую технологию, ни на вторую. Поигравшись вдоволь еще с LINQ Preview, мы решили его не использовать, а остановились на своем собственном «полумаппере», который нас в общем-то устраивает.(и который завсит только от ado.net)
Сейчас по идее можно было бы начинать щупать EF, но больно уж он тяжеловесно выглядит.
Вобщее, при увеличении сложности приложения, смысл использования мапперов стремится к 0. Да, для прототипирования самое оно, но в продакшене лучше быть как можно ближе к SQL:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LINQ to SQL и пространственные данные SQL Server