Станислав Макаров

> Как лучше хранить данные GeoJson в БД?
Геометрию - в колонке геометрического (или географического, смотря что вам нужно) типа, остальные свойства фич - в колонках соотв. типа.
> Если хранить пространственные данные в БД, то где потом лучше формировать сам GeoJson?
на бэкенде при передаче фронтэнду, на фронтэнде - при передаче бэкенду

Т.к. в реляционных СУБД и так уже придумали, как работать с геометрией, то не вижу смысла в GeoJSON хранить. В какой-нибудь Монге - другое дело, но не в MySQL. А вот для передачи геоданных GeoJSON вполне ничего, поэтому и логичный вывод, где что формировать.
Вообще странный вопрос, будто у вас основная задача не саму фичу передать и сохранить, а сохранить GeoJSON.

Сложно вам посоветовать в такой ситуации что-либо. Интересно, чем занималась контора та, что программисты C# с sql не знакомы, разве что играми..
В целом вам надо ознакомиться с современным представлением о реляционных БД (вы же все-таки аналитик, вам нужно знать на разных уровнях и масштабах), с архитектурой приложений, использующих РБД (толстые и тонкие клиенты, веб-приложения), и потом уже некоторые детали касающиеся языка.
С точки зрения программиста C#, я бы от вас как от аналитика ожидал знание различных принципов и дисциплин доступа к рел. данным, а именно:
- использование ORM: когда можно и нужно), когда хочется, но нельзя, когда можно "толстую" ORM (Entity Framework, NHibernate), а когда - тонкую (LINQ to SQL); использование кода на стороне БД - триггеры, хранимые процедуры;
- принципы построения слоев доступа к данным в сочетании с бизнес логикой (паттерны и антипаттерны в этих ситуациях, например Anemic Data Model);
- способы контроля версий схемы реляционной БД - миграции, source control для триггеров и хранимых процедур (если они есть), политики обновления схемы вместе с выкатыванием новой версии ПО;
- формирование тестовых данных в тестовых базах;

Вот если сможете по этим вопросам проконсультировать, то разработчикам останется только подучить SQL и конкретную ORM, если будете использовать.

Сергей Иванов дал хорошую идею, только не раскрыл до конца. В общем вам действительно будет полезна иерархия - если какая-то кость связана с другой, то эта другая будет для первой точкой отсчета - своей системой координат. Даже ваш рисунок подсказывает, что каждая кость - это вектор, а точка привязки - это начало кости. Т.о. вам достаточно для каждой кости хранить "родительскую" кость (к которой мы привязаны) - для пальцев это будет кисть или локтевой сустав, и вектор - направление кости. Тогда для перемещения группы костей вам достаточно будет переместить ТОЛЬКО родительскую для этой группы (модифицировать ее вектор). А алгоритм определения положения дочерних костей должен будет идти по дереву костей и складывать родительские и дочерние вектора, пока не дойдет до листьев костяного дерева.
update: собственно, у Дмитрий Макаров то же самое)

> где наряду с NoSQL еще и графы используются
интересная формулировка)

> В каких случаях это в БД может быть полезно?
во всех задачах, где глубина и "разнообразие" связей между сущностями сравнимо с количеством этих сущностей.
Возьмем для примера две простые ситуации:
1) есть заказ в интернет-магазине с некоторым числом заказанных товаров. Вне зависимости от того, реляционную модель вы будете использовать или какую-то еще, скорее всего вам будет удобно рассматривать две сущности: Order и OrderItem. В первую вы добавите сведения обо всем заказе целиком (инф. о клиенте, дату заказа, выбранный способ доставки, способ оплаты и т.д.). Во второй сущности у вас будет, например, id товара и его количество (1 микроволновка, 2 флешки, 5 CD-R). Теперь, чтобы вы могли знать, что какие-то OrderItem имеют отношение к конкретному Order, вам следует тем или иным способом смоделировать связь. Если у вас SQL-база, вы добавите к Order-у поле Id, а к OrderItem поле OrderId и сделаете внешний ключ. Если у вас документная база, то, к примеру, можно весь заказ с его элементами разместить в одном json-документе, и элементы заказа будут подобъектами в массиве items объекта заказа. Со временем у вас появится много заказов и много элементов заказов. Однако связи между ними у вас всегда будут достаточно простые: у каждого заказа будет некоторое количество элементов. Сами заказы вы связывать не будете, как не будете связывать элементы заказа. Глубина связей сущностей будет ограничена одним переходом.
2) у вас есть социальная сеть (да, знаю, банальный пример), и конечно же у вас есть функция "добавить в друзья". В отличие от предудыщего примера, мы для рассмотрения можем взять только одну сущность - "пользователь", однако за счет того, что каждый каждого может зафрендить, у вас даже для одной сущности будет очень большой набор фактических связей, потенциально с большой глубиной (знакомые знакомых и т.д.).

Обе проблемы теоретически можно решить с помощью SQL баз данных, однако графовые базы будут выигрывать во второй задаче в сложных запросах по обработке связей (скажем, найти всех моих друзей, которые идут на такое-то мероприятие). Этот выигрыш вытекает из архитектурных особенностей графовой БД, например, в графовой базе часто при сохранении связи сохраняется "указатель" на физическое расположение связанных данных, в то время как в реляционной базе связи моделируются внешними ключами, и при обработке требуют выполнения операций поиска (пусть и индексированного). Вообще, в каком-то смысле связи в графовой БД это first-class citizens, а в реляционной БД связи моделируются программистом (ограничения целостности вроде внешних ключей просто помогают ему поддерживать данные в согласованном состоянии).

Значит так, во-первых вам для Qt и для вашего приложения нужно использовать один тулчейн (компилятор), иначе будет огромное количество странных проблем. Т.к. вы разрабатываете в 2012-й студии, а, к сожалению, официально 4-й кьют под эту студию не собирался, вам придется как минимум поставить компилятор из 2010-й студии (не помню, возможно 2012-ю можно таргетировать на старый компилятор, чтобы не ставить 2010-ю студию целиком). Можно и попробовать собрать из исходников, но я не могу назвать это простым делом.
Во-вторых, если мы представим, что вы выполнили предыдущий этап, и у вас есть собранный Qt и компилятор той же версии, то в зависимости от конфигурации (Debug|Release) ваша программа будет линковаться на разные рантаймы. DLL-файлы рантайма имеют букву 'd' в конце имени файла. Для разных версий VC++ они называются по разному:
msvcr90[d].dll+msvcp90[d].dll - Visual Studio 2008 (MSVC 9.0)
msvcr100[d].dll+msvcp100[d].dll - Visual Studio 2010 (MSVC 10.0)
msvcr110[d].dll+msvcp110[d].dll - Visual Studio 2012 (MSVC 11.0)
msvcr120[d].dll+msvcp120[d].dll - Visual Studio 2013 (MSVC 12.0)
Для чего я это привел - т.к. ваша ошибка прилетела скорее всего из подсистемы side-by-side, и связана с конфликтом версий библиотек, в качестве workaround советую вам найти дебаг-библиотеки там где у вас установлена студия, и скопировать из к exe-шнику вашего приложения, чтобы эти библиотеки подхватывались приоритетнее. Однако перед тем, как вы это сделаете, попробуйте следующее:
0) разберитесь с версией компилятора, под которую собирался Qt. Возможно лучшее решение - таки поставить компилятор из 2010-й, не решив этот вопрос продолжать нормально работать невозможно
1) убедитесь, что пересобрали проект (сделайте Rebuild All)
2) поставьте апдейты на 2012-ю студию, если она не последней версии
Если проблема останется, возьмите Dependecy Walker, натравите на Exe-шник, и проверьте, откуда он подтягивает debug-библиотеки.
Если есть вопросы - в комментарии.