Добавление полей в существующую таблицу - баг или фича ?

[sukhanchik]

Цитата:

Сообщение от Vadik

Не уверен что понимаю физический смысл выражений "поле распологается до и после", но все же... Ну допустим - и чо ?

Я думаю, что имеется в виду, что отображение структуры таблицы в SQL Management Studio отображает поля в порядке, описанном топикстартером.

Это влияет на то, что если в двух родственных приложениях (т.е. полученных недавно путем копирования исходного приложения, но в которых после копирования уже были выполнены некоторые модификации, т.о. сделавших их неидентичными)
одно и то же поле в таблицу независимо добавлялось разными разработчиками разными способами - то данные между этими двумя таблицами нельзя будет перенести через конструкцию INSERT INTO <table1> SELECT * FROM <table2>.
Т.е. * в таблице <table2> выдаст список полей в ином порядке, нежели ожидается в конструкции INSERT INTO для <table1>

Другое дело - что это некритично и лечится копированием приложения и административным запрещением параллельного добавления полей в родственные приложения

[kair84]

Действительно, ничего критичного, если обходиться только средствами разработки АХ. Но некоторые "убер-запросы" можно реализовать только через SQL, и при использовании конструкции INSERT INTO <table1> SELECT * FROM <table2>, возникают... - неудобства, не более того. Но конструкция INSERT INTO <table1>[(<Field1>,<Field2>,...)] SELECT [(<Field1>,<Field2>,...)] FROM <table2> устраняет эти неудобства.
Разработка ведется в отдельной копии приложения, а готовый проект импортируется в основное приложение, здесь ОНО и всплыло, мелочь - казалось бы, а не приятно. Основное непонятно - почему поля добавляются разными способами.

[sukhanchik]

Цитата:

Сообщение от kair84

Действительно, ничего критичного, если обходиться только средствами разработки АХ. Но некоторые "убер-запросы" можно реализовать только через SQL, и при использовании конструкции INSERT INTO <table1> SELECT * FROM <table2>, возникают... - неудобства, не более того. Но конструкция INSERT INTO <table1>[(<Field1>,<Field2>,...)] SELECT [(<Field1>,<Field2>,...)] FROM <table2> устраняет эти неудобства.

Ну... тут можно что сказать... Только то, что уже давно всем известно:
Вести разработку не только в АХ чревато

• неполнотой информации в перекрестных ссылках, на которые очень полезно опираться, как на информацию что где и в каком качестве используется. А для полей таблиц - эта информация особенно полезна - она позволяет показать где происходит запись данных, а где чтение
• необходимостью иметь в штате человека, одновременно знающего и T-SQL (PL-SQL) и X++

Правда, сейчас сам Microsoft взял курс на разработку для АХ в разных программных средах (C#, Visual Studio)

А самое главное - в ряде случаев код в БД может быть заменен на код Х++ без заметной потери производительности путем изменения архитектуры данных, алгоритма обработки или постановки задачи. Тут конечно мне тяжело говорить за все случаи, потому что далеко не всегда есть возможность переделки механизма "с нуля". Но тем не менее, при разработке нового кода - имеет смысл лишний раз задуматься об этом.

В частности, на моей практике я встречал случаи реализации тех или иных алгоритмов путем выборки данных, перелива результата выборки во временную таблицу, затем их обработки, еще нескольких раз перелива и т.д.
Такой подход как раз и требует конструкции INSERT INTO на больших объемах данных.
Но при достаточно тщательном продумывании архитектуры алгоритма "с нуля"- этих переливов часто получалось избегать (или они не были столь объемными). Что повышало производительность системы.

Впрочем это все лирика, а к исходному вопросу отношения не имеет. Мое мнение - что об порядке полей в таблице просто никто не задумывался при реализации ядра.

[S.Kuskov]

Цитата:

Сообщение от kair84

Основное непонятно - почему поля добавляются разными способами.

Где-то проскакивала информация о том, что аксапта для увеличения производительности добавлении поля в таблицу вместо использования ALTER TABLE может пересоздавать всю таблицу целиком. Ключевое слово - может, т.е. может пересоздавать таблицу а может и не пересоздавать. Возможно именно с этим связан различный порядок следования полей?

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

Где-то проскакивала информация о том, что аксапта для увеличения производительности добавлении поля в таблицу вместо использования ALTER TABLE может пересоздавать всю таблицу целиком.

Не думаю. Тогда бы терялись данные, либо было бы заметно долгое добавление поля (представьте себе время на "переливку" InventTrans на нормальном объеме данных), которое и так встречается при изменении индекса (время на создание индекса на больших объемах данных - очень не маленькое)

[S.Kuskov]

Цитата:

Сообщение от sukhanchik

Не думаю.

Оптимизация апгрейда больших баз

[kair84]

Да, по максимуму обходимся средствами разработки Ах., через SQL, напрмер, реализовали формирование прайсов, время сократилось в разы, ну это так....

Больше похоже но то, что это 2 разных метода (написанные разными разработчиками) выполняющих одну и ту же задачу.
В прочем, особо тут нечего обсуждать, это еще одна из "особенностей" Ах., хотел поделиться наблюдением, может кому то и пригодится.