Размер полей в shp файле.

Question

Наткнулся на фичу. Делюсь. Вроде раньше не видел.
Имена полей в shp файлах не могут превышать 10 символов.
В geodatabase такого ограничения нет.
Так что сконевртировав в shp из geodatabase - такое бывает нужно, например, при смене домена координат - можно обратно такие же имена полей не получить.
Для истории.

Answer 1

В DBF это спокон веку, даже какое-то такое ограничение SQL имеется. Когда появилось ArcView, они зачем-то стали с этим бороться и побеждали алиасами, и было с ними много забавных казусов.

Answer 2

В DBF это спокон веку, даже какое-то такое ограничение SQL имеется. Когда появилось ArcView, они зачем-то стали с этим бороться и побеждали алиасами, и было с ними много забавных казусов.

Ага. Я когда то даже библиотеку классов для работы с dbf писал. :)
По идее внутри там это не зашито, но по факту требуется.
Думаю, здесь со стороны ESRI скорее политика, чем реальная целесообразность.
Чтобы юзеры на geodatabase переходили.

Проблема оччень смачно вылезла. В глазах юзеров выглядела как ошибка в нашем модуле. Я представляю, к чему это может привести, например, при работе с SDE да еще со связанными таблицами. Так можно потерять всю базу.
Получается, это при проектировании баз данных надо закладывать.
А имена полей могут и программно генериться при различных вычислениях атрибутов. Тут еще добавлю один из практических советов, кажется Дейта или кого-то из классиков реляционных баз данных "В имена полей желательно включать названия таблиц"

Например Mylovetable_Mylovefield.
Вот после следования вполне классическим рекомендациям мы получаем замечательные стихи
Myloveta_1
Myloveta_2
Myloveta_3
Myloveta_4
...

Answer 3

В DBF это спокон веку, даже какое-то такое ограничение SQL имеется. Когда появилось ArcView, они зачем-то стали с этим бороться и побеждали алиасами, и было с ними много забавных казусов.

Думаю, здесь со стороны ESRI скорее политика, чем реальная целесообразность.
Чтобы юзеры на geodatabase переходили.

При чём ту политика?  я вам улыбаюсь... есть стандарты в стандарте Shape файла хранятся только координаты и типы, вся атрибутика хранится в таблице данных dbf (data base file), а у неё ещё с давних пор стандарт такой ещё ArcView не было, когда такое такой стандарт был... а сейчас другие времена, есть другие форматы, а ПОЛИТИКА ТУТ НИ ПРИ ЧЁМ...

историю знать надо

Answer 4

Теперь буду знать.

Когда писал работу с dbf для одной софтины (89-90годы), внутри самого формата прямых ограничений не заметил. Но мне не требовалась индексация, возможно дело в ней. Тогда как раз DBase уходил, и появилось сразу несколько программ для работы с базами.

Еще подумал. А собственно какая разница почему не поддерживается?
Какая-то правда в этом вопросе мне безразлична. Ничего она не даст.

Важно, что юзеру надо знать про ограничение. И девелоперу, разумеется, тоже.

Роман, привет Белгороду из Перми.
Правду по такой мелочи мог бы учинить и по Аське

Answer 5

Странно... Поглядел первый попавшийся DBF: ограничения ТОЧНО ЕСТЬ, достаточно глянуть сам файл внимательно - на заголовки колонок отведено по 10 позиций, 12-я задает тип поля (N,C и т.п.). 11-я позиция вроде пустая, и не понять с ходу зачем, но,наверно, хранит количество знаков или что-то в этом роде, а если и нет, то тоже погоды не делает. DBF файл по сути текстовый, и глядеть его нетрудно. Формат его опять же фиксированный, и задан жестко, без вариаций. Что вы имели в виду, когда говорили "нет ограничений"? Формат, по-моему, раз и навсегда был определен в DBase (фирма Ashton-Tate, кажется), и там спокон веку было по 10 символов. Вряд ли в такие дремучие времена разработчики стали бы закладывать "запас". Когда в Microsoft подхватили все эти разработки, то уже ничего не меняли - да и не смогли бы, формат разошелся не только вширь, но и вглубь: влез как базовый в разные системы, начиная от Клиппера и кончая ArcINFO/View.