Как правильно именовать временные таблицы

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

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

Это почему же нежелательно?

Цитата:

Сообщение от Владимир Максимов

Вопрос "зачем?" в голову не приходил? Если, как Вы утверждаете, между "перманентно временной" или же "конфигурируемо временной" нет никакой разницы, то зачем их вообще как-то отделять друг от друга?

Можно ссылку, где я утверждал, что нет никакой разницы? Различать же такие таблицы нужно затем, что работа с ними немного отличается. Точно так же, как отличается работа с настроечными таблицами, которые полностью кэшируются АОСом, и с транзакционными, точно так же, как отличается работа с таблицами, для которых настроена оптимистичная и пессимистичная конкурентная модель...

Цитата:

Сообщение от Владимир Максимов

Т.е., с точки зрения Best Practices разница таки есть. Раз специально предусмотрено их выделение в отдельную "группу".

Кто бы спорил... Таблицы, относящиеся к разным модулям, тоже выделяются в отдельные "группы", и что теперь? Сделать их разными объектами приложения?

Цитата:

Сообщение от Владимир Максимов

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

Это было раньше - теперь их предлагается группировать с постоянными таблицами, относящимися к тому же модулю. К тому же для меня лично "расстояние между элементами приложения в AOT" не является необходимым и достаточным основанием выделять их в разные типы. Между классами AfArray и xUtilElements "расстояние в AOT" больше, чем между любыми двумя таблицами, а между AfArray и Application оно еще больше, как ни парадоксально, - и что теперь? Сделать их разными типами объектов приложения, потому что якобы на это намекает Best Practices?

Цитата:

Сообщение от Владимир Максимов

То, что сейчас набор свойств временной таблицы совпадает с набором свойств обычной таблицы не означает, что так и должно быть. Если бы временные таблицы выделили в отдельную ветку AOT, то, очевидно, часть свойств просто выбросили бы в виду их бессмысленности для временных таблиц.

И что это даст? И как это будет стыковаться с "конфигурируемо временными" таблицами? Их в какую ветку АОТ вынести?

Цитата:

Сообщение от Владимир Максимов

Вы действительно считаете что временные таблицы MS SQL тот же самый объект, что и постоянные? То, что временные таблицы "свопятся" в базу временных данных MS SQL никак не означает, что это постоянные таблицы. Это просто технология хранения временных данных.

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

Цитата:

Сообщение от Владимир Максимов

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

Не придирайтесь к словам - лучше прочтите What's new in AX 2012 - Technical for Developer. В оригинале новое свойство называется TableType с вариантами на выбор: Regular, InMemory, TempDB. Т.е. с точки зрения разработчиков ядра всё это - лишь типы таблиц, а не разные типы объектов приложения, хотя "за кулисами" их реализация и отличается.

Цитата:

Сообщение от Владимир Максимов

Проблема в том, что сущности уже сейчас "умножены без необходимости". Для временных таблиц часть свойств - лишние.

Сущности и свойства сущностей - это немного разные понятия. Для таких классов, как Application, Info, Company, VersionControl свойство RunOn, к примеру, тоже лишнее, потому что его никак нельзя изменить в приложении, но никакого "умножения сущностей" это не создает.

Цитата:

Сообщение от Владимир Максимов

Проблема в том, что следование рекомендациям Best Practices в данном случае - усложняет поиск нужных объектов в AOT. Это подробно обсуждалось в теме про префиксы. Выделение Tmp в начало приводит к тому, что постоянная таблица и временная таблица сделанная по ее "образцу" (или логически связанная) оказываются далеко разнесенными друг от друга в AOT. Т.е., например, при внесении изменений в постоянную таблицу можно просто забыть изменить еще и временную (если это необходимо, конечно)

Очень интересно, что это за парные таблицы у вас, и кто тут еще занимается умножением сущностей Забыли добавить поле во временную таблицу - не беда, это вылезет сразу же, как предположительно имеющееся уже поле надо будет заполнить. И какая разница, как при этом отличаются названия постоянной и временной таблиц?..

Цитата:

Сообщение от Владимир Максимов

Да и вообще, именование временных таблиц выбивается из общей схемы именования объектов AOT. Т.е. нужно заранее знать, что ищем именно временную таблицу. Следовательно, с точки зрения Best Practices - это все-таки отдельный объект! Отдельная сущность.

Я че-то не поспеваю за этими логическими выкладками: какой именно поиск таблиц имеется в виду, по первым буквам названия? А если мне, скажем, нужно найти таблицу, относящуюся к модулю WMS, и я ищу ее по первым буквам названия, а не, скажем, по конфигурационному ключу, к которому таблица привязана, то я ведь тоже должен заранее знать, что первые буквы ее названия - это "WMS", а не "Cust" и не "Ledger"? Можно ли на основании этого утверждать, что с точки зрения Best Practices таблицы из модуля WMS - это "отдельная сущность"?

[Владимир Максимов]

gl00mie

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

Цитата:

таблица может стать временной (...) за счет отключения конфигурационного ключа

И, если возможно, пример использования именно этой фичи в стандартном функционале.

======================================

Про остальное, думаю, стоит закончить. Поскольку начнется нудное выяснение кто и что имел в виду, кто к чему придрался, кто чего не понял, и т.д. и т.п. Никому, в общем-то, не интересное.

А по теме обсуждения, насколько я понял, большинство сходится во мнении, что раз есть четко прописанная рекомендация Best Practices, то этой рекомендации и стоит придерживаться, даже если кажется, что эта рекомендация бесполезна или создает некоторые трудности.

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

каким образом отключение конфигурационного ключа делает из постоянной таблицы временную?

Ну вот как-то так ядро устроено: выключен конфигурационный ключ - значит, нет таблицы в базе. Это сделано было с давнишних времен в первую очередь, думается, для ограничения возможности использовать функционал, на которой не куплены лицензии. Возьмите любую "постоянную" таблицу, относящуюся к модулю, на который у вас нет лицензий или конф. ключ которой просто выключен, и выведите в инфолог, что для нее напишет new DictTable( tableId ).isTmp(). В 2012-й, правда, уже обещают не грохать отключенные таблицы из базы - видать, нормализация данных "не ложится" на прежний подход.

Цитата:

Сообщение от Владимир Максимов

И, если возможно, пример использования именно этой фичи в стандартном функционале.

Версии спецификации и метод InventTable.insertBOMTable()

Цитата:

Сообщение от Владимир Максимов

Про остальное, думаю, стоит закончить.

Ok.