-1

У IIngeoSemTable есть ID, а у IIngeoSemFieldInfo и IIngeoSemDbField нет ID

Сергей Попов 12 aastat tagasi uuendaja Artem Popov 12 aastat tagasi 5

Т.е. если произошло небольшое изменение структуры семантической таблицы (переименование поля), то как это скажется при экспорте с наложением на существующий слой с объектами?

Пример: В таблице 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 полей он не привязан к названиям полей и позволяет пользователям переименовывать поля без нарушения настроек.

Вариант 1, наиболее примлемый, как по мне.

Как по мне, так на роль Ид поля вполне подходит его физическое имя, а оно пользователю не показывается). так что ситуация с полями меня, например, устраивает.

Кстати, если введут порядковый номер поля, то он не скажется на модулях.

Увы показывается. Физическое имя поля показывается пользователям:

1. Меню Анализ -> Запрос по семантическим данным.

2. Импорт dxf. Может и другие импорты.

Порядковый номер поля предлагаю позволить пользователям и через API менять.

Добавлять поля только в конец списка - редко требуется. Заодно необходимо переставить их по смыслу в нужное место.

Может имеет смысл говорить о разных номерах: порядковый номер в СУБД и порядковый номер в ИнГЕО. Порядковый номер в СУБД пользователю будет неважен (ему будет доступен помер в ИнГЕО), следовательно номер в СУБД может использоваться в тех местах, где можно было использовать ID.

Упс. Если поля добавляют в разных базах, что произойдёт при слиянии?

ID эту ситуацию легко разрулит, для этого он и придуман.


 

 Мне кажется нужно менять эти импорты и запрос по семантике.

Ибо название поля для того и придумано чтобы показываться пользователю. а его "физическое имя" и является идентификатором, ибо обеспечивает его уникальность в рамках одной табицы.

Это свойства от идентификатора и требуется.

А вот менять физическое имя поля крайне не рекомендуется. Я сам допустил эту ошибку в модуле печати отчётов и поимен определённый геморрой.

(Сразу скажу, если бы был ИД, была бы таже самая ситуация, ибо я и задумывал сменить тип данных поля с определённым Ид, а нужно былдо создавать новое поле!)

Я бы рад не трогать названия полей, но иногда импорт подкидывает такие названия, с которыми в Oracle и ИнГЕО работать неудобно.

1. Поля на русском языке

2. Поля с чередованием строчных и прописных букв

3. Длинные поля, приближающиеся к ограничению Oracle на длину (30 символов).

ИнГЕО (пока) отображает названия таблиц и полей в верхнем регистре. Подглянув в ИнГЕО, не сразу можно собрать правильное SQL-предложение.

4. При формировании индекса по указанному полю, ИнГЕО формирует имя ограничения добавляя к названию поля суфиксы "_PK" или "_I1". Раньше были проблемы с превышением ограничения в 30 символов, сейчас не пробовал.

Что если завтра, разработчики внесут изменения в алгоритм импорта и в этот момент имена полей и таблиц будут преобразовываться под предпочтения текущей СУБД. Для Oracle все поля на английском в верхнем регистре. Тогда обновление модулей сторонних разработчиков (разрабатывающих под MS-SQL или PARADOX) не смогут идентифицировать собственные поля и таблицы.

1-4: Вот тут не могу не согласится :)
но насчет сторонних модулей: у них как правило есть функция настройки - настраивайтесь на новые ваши поля и вуаля :)