- Общий
-
Ideed
У IIngeoSemTable есть ID, а у IIngeoSemFieldInfo и IIngeoSemDbField нет ID
Т.е. если произошло небольшое изменение структуры семантической таблицы (переименование поля), то как это скажется при экспорте с наложением на существующий слой с объектами?
Пример: В таблице T поле F1 будет переименовано в F2. Формируем idf c 10-тью объектами и закачиваем в базу в которой 100 объектов. 7 объектов общие – есть и в 10м и в 100.
Вариант 1. Щадящий: В базе поле F1 не удаляется, добавляется поле F2. В базе 103 объекта, поле F1 заполнено у 100, а поле F2 – у 10 объектов. У 7 объектов заполнено оба поля. Потери семантики нет, но есть лишнее поле.
Вариант 2. Замещение. В idf нет поля F1, следовательно это поле удаляется из базы. Добавляется поле F2. Из 103 объектов, это поле заполнено только у 10. Нет лишних полей, но есть потеря семантики.
Вывод: необходимо вводить ID полей семантических таблиц, чтобы реализовать 3-ий вариант, лишённый вышеуказанных недостатков.
Ещё один довод: Сторонний разработчик настраивает работу своего модуля на определённые карты, слои, таблицы и поля. Сохраняя ID полей он не привязан к названиям полей и позволяет пользователям переименовывать поля без нарушения настроек.
Customer support service by UserEcho
Вариант 1, наиболее примлемый, как по мне.
Как по мне, так на роль Ид поля вполне подходит его физическое имя, а оно пользователю не показывается). так что ситуация с полями меня, например, устраивает.
Кстати, если введут порядковый номер поля, то он не скажется на модулях.
Увы показывается. Физическое имя поля показывается пользователям:
1. Меню Анализ -> Запрос по семантическим данным.
2. Импорт dxf. Может и другие импорты.
Порядковый номер поля предлагаю позволить пользователям и через API менять.
Добавлять поля только в конец списка - редко требуется. Заодно необходимо переставить их по смыслу в нужное место.
Может имеет смысл говорить о разных номерах: порядковый номер в СУБД и порядковый номер в ИнГЕО. Порядковый номер в СУБД пользователю будет неважен (ему будет доступен помер в ИнГЕО), следовательно номер в СУБД может использоваться в тех местах, где можно было использовать ID.
Упс. Если поля добавляют в разных базах, что произойдёт при слиянии?
ID эту ситуацию легко разрулит, для этого он и придуман.
Мне кажется нужно менять эти импорты и запрос по семантике.
Ибо название поля для того и придумано чтобы показываться пользователю. а его "физическое имя" и является идентификатором, ибо обеспечивает его уникальность в рамках одной табицы.
Это свойства от идентификатора и требуется.
А вот менять физическое имя поля крайне не рекомендуется. Я сам допустил эту ошибку в модуле печати отчётов и поимен определённый геморрой.
(Сразу скажу, если бы был ИД, была бы таже самая ситуация, ибо я и задумывал сменить тип данных поля с определённым Ид, а нужно былдо создавать новое поле!)
Я бы рад не трогать названия полей, но иногда импорт подкидывает такие названия, с которыми в Oracle и ИнГЕО работать неудобно.
1. Поля на русском языке
2. Поля с чередованием строчных и прописных букв
3. Длинные поля, приближающиеся к ограничению Oracle на длину (30 символов).
ИнГЕО (пока) отображает названия таблиц и полей в верхнем регистре. Подглянув в ИнГЕО, не сразу можно собрать правильное SQL-предложение.
4. При формировании индекса по указанному полю, ИнГЕО формирует имя ограничения добавляя к названию поля суфиксы "_PK" или "_I1". Раньше были проблемы с превышением ограничения в 30 символов, сейчас не пробовал.
Что если завтра, разработчики внесут изменения в алгоритм импорта и в этот момент имена полей и таблиц будут преобразовываться под предпочтения текущей СУБД. Для Oracle все поля на английском в верхнем регистре. Тогда обновление модулей сторонних разработчиков (разрабатывающих под MS-SQL или PARADOX) не смогут идентифицировать собственные поля и таблицы.
но насчет сторонних модулей: у них как правило есть функция настройки - настраивайтесь на новые ваши поля и вуаля :)