- Общий
-
Idéer
У 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 полей он не привязан к названиям полей и позволяет пользователям переименовывать поля без нарушения настроек.
Kundesupport af UserEcho
Вариант 1, наиболее примлемый, как по мне.
Как по мне, так на роль Ид поля вполне подходит его физическое имя, а оно пользователю не показывается). так что ситуация с полями меня, например, устраивает.
Кстати, если введут порядковый номер поля, то он не скажется на модулях.
Увы показывается. Физическое имя поля показывается пользователям:
1. Меню Анализ -> Запрос по семантическим данным.
2. Импорт dxf. Может и другие импорты.
Порядковый номер поля предлагаю позволить пользователям и через API менять.
Добавлять поля только в конец списка - редко требуется. Заодно необходимо переставить их по смыслу в нужное место.
Может имеет смысл говорить о разных номерах: порядковый номер в СУБД и порядковый номер в ИнГЕО. Порядковый номер в СУБД пользователю будет неважен (ему будет доступен помер в ИнГЕО), следовательно номер в СУБД может использоваться в тех местах, где можно было использовать ID.
Упс. Если поля добавляют в разных базах, что произойдёт при слиянии?
ID эту ситуацию легко разрулит, для этого он и придуман.
Мне кажется нужно менять эти импорты и запрос по семантике.
Ибо название поля для того и придумано чтобы показываться пользователю. а его "физическое имя" и является идентификатором, ибо обеспечивает его уникальность в рамках одной табицы.
Это свойства от идентификатора и требуется.
А вот менять физическое имя поля крайне не рекомендуется. Я сам допустил эту ошибку в модуле печати отчётов и поимен определённый геморрой.
(Сразу скажу, если бы был ИД, была бы таже самая ситуация, ибо я и задумывал сменить тип данных поля с определённым Ид, а нужно былдо создавать новое поле!)
Я бы рад не трогать названия полей, но иногда импорт подкидывает такие названия, с которыми в Oracle и ИнГЕО работать неудобно.
1. Поля на русском языке
2. Поля с чередованием строчных и прописных букв
3. Длинные поля, приближающиеся к ограничению Oracle на длину (30 символов).
ИнГЕО (пока) отображает названия таблиц и полей в верхнем регистре. Подглянув в ИнГЕО, не сразу можно собрать правильное SQL-предложение.
4. При формировании индекса по указанному полю, ИнГЕО формирует имя ограничения добавляя к названию поля суфиксы "_PK" или "_I1". Раньше были проблемы с превышением ограничения в 30 символов, сейчас не пробовал.
Что если завтра, разработчики внесут изменения в алгоритм импорта и в этот момент имена полей и таблиц будут преобразовываться под предпочтения текущей СУБД. Для Oracle все поля на английском в верхнем регистре. Тогда обновление модулей сторонних разработчиков (разрабатывающих под MS-SQL или PARADOX) не смогут идентифицировать собственные поля и таблицы.
но насчет сторонних модулей: у них как правило есть функция настройки - настраивайтесь на новые ваши поля и вуаля :)