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

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

В ранних версиях Best Practices рекомендовалось начинать имя временной таблицы с префикса "Tmp". Например, TmpCustLedger

Современная версия Best Practices (Ax2009) рекомендует вставлять "Tmp" непосредственно за обозначением модуля. Например, CustTmpLedger

Есть ли вообще практический смысл как-то обозначать тот факт, что таблица является временной непосредственно в имени таблицы? Если есть, то стоит ли придерживаться рекомендаций Best Practices или же, например, писать "Tmp" как окончание (или суффикс) имени?

[mazzy]

мне кажется, что практического смысла нет.
все равно в коде любую таблицу можно объявить временной.
поэтому все равно надо отслеживать код.

кроме того, в ax2012 уже и майкрософт не придерживается своих best Practice по наименованиям таблиц.

[DSPIC]

Удобнее всего "Tmp" ставить в самом конце имени, тогда, сортируясь по алфавиту в АОТ, таблица будет находиться на своем месте, среди таких же таблиц, относящихся к общей функциональности, напр. CustPaymOnlineTransTmp. Если же "Tmp" всунуть после названия модуля (CustTmpPaymOnlineTrans), то все временные таблицы модуля "уйдут" вниз АОТ, что неудобно и лишено смысла.

А практический смысл конечно есть. Всегда важно знать, временная таблица, или нет, буть то в АОТ или в коде.

[lvan]

Вот ещё вариантик :
TCustMLedgerP

и вначале и в середине и в конце!

[S.Kuskov]

Цитата:

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

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

Смысл в том чтобы сделать более удобным чтение кода. Т.к. в аксапте ещё принято чтобы имя табличного курсора совпадало с именем таблицы, то при работе с таким курсором по его имени сразу будет понятно что он временный.

Цитата:

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

Если есть, то стоит ли придерживаться рекомендаций Best Practices или же, например, писать "Tmp" как окончание (или суффикс) имени?

В ранних версиях Best Practices рекомендовалось начинать имя временной таблицы с префикса "Tmp". Например, TmpCustLedger

Современная версия Best Practices (Ax2009) рекомендует вставлять "Tmp" непосредственно за обозначением модуля. Например, CustTmpLedger

Рекомендации и старая и новая явно направлены на то чтобы сгрупировать временные таблицы при помощи порядка их следования в AOT. Раньше все временные таблицы собирались бы в разрезе модулей в одном месте, а теперь в каждом модуле получится своя группа временных. Много ли в этом смысла? Не знаю, но раз уж так настойчиво рекомендуют должно что-то быть
Лично я в этом вопросе согласен с DSPIC

[gl00mie]

Цитата:

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

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

По-моему, смысл есть и вот какой: таблицы в Аксапте - это, образно говоря, сгусток метаданных Каждое свойство самой таблицы, ее полей, индексов несет глубокий смысл и может влиять на поведение очень многих мест приложения. В то же время, в случае временных таблиц правила заполнения разного рода свойств обычно соблюдаются "спустя рукова", что в принципе оправдано. Так вот, не скажу за всех, но если я лично вижу на текущем слое таблицу, у которой не выставлен ключ контроля доступа, или метка, или FormRef, или TitleFields, или у которой поля, являющиеся первичным ключом, не помечены как обязательные к заполнению и редактируемые лишь при создании записи... в общем, у меня лично первая реакция - "КАКОЙ <CENSORED> ЭТО СДЕЛАЛ?!" А если таблица временная - ну что ж... фиг бы с ним, может, она вообще нужна лишь для хранения/передачи наборов разнотипных значений как прекрасная альтернатива ненавистным контейнерам. В общем, явное указание в имени того, что таблица - временная, может в каких-то случаях сэкономить несколько нервных клеток

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

Цитата:

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

Смысл в том чтобы сделать более удобным чтение кода. Т.к. в аксапте ещё принято чтобы имя табличного курсора совпадало с именем таблицы, то при работе с таким курсором по его имени сразу будет понятно что он временный.

Какие преимущества (бонусы) дает программисту знание того факта, что данная таблица временная до анализа программного кода? В чем заключается это самое "удобство чтения кода"?

Цитата:

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

В общем, явное указание в имени того, что таблица - временная, может в каких-то случаях сэкономить несколько нервных клеток

Если Вы видите, что у таблицы, например, не выставлен ключ контроля, то для того, чтобы определить временная это таблица или нет Вы будете смотреть на ее имя или таки на свойство Temporary? В смысле, если уж дело дошло до анализа свойств таблицы, то не все ли равно, как эта таблица называется?

[S.Kuskov]

Цитата:

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

Какие преимущества (бонусы) дает программисту знание того факта, что данная таблица временная до анализа программного кода? В чем заключается это самое "удобство чтения кода"?

Ну например, какой-нибудь метод принимает в качестве параметра табличный курсор. Если курсор временный, то можно предположить что передаётся не просто запись (возможно и такое), а ссылка на временный буфер. И соответственно ожидать от кода уже можно обработку не только одной записи а нескольких.

[gl00mie]

Я по-привычке выставляю в настройках сортировку свойств по алфавиту - при этом на моем мониторе с разрешением 1680х1050 свойство Temporary таблицы не помещается на экране, и чтобы его увидеть, свойства нужно прокрутить вниз По имени лично мне ориентироваться проще. Собственно, думаю, Best Practices по именованию таблиц тоже возникли не на пустом месте, а то ведь модуль, к которому относится таблица, и ее "тип" (справочник, группы, проводки, и т.п.) тоже ведь можно было бы не из имени узнавать, а из свойств или, там косвенных признаков вроде примеров использования таблицы в коде...

[MikeR]

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

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

Цитата:

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

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

Можно уточнить о чем речь? Какое отношение данный ответ имеет к заданному вопросу?

[kashperuk]

На самом деле, следует делать так, как советует Майкрософт.
В АХ 2012 рекомендация о наименовании временных таблиц была изменена с "Prefix" на "Infix".

Страницы на MSDN о временных таблицах были обновлены с учетом новых рекомендаций:
Best Practices for Table Properties
Temporary Tables

Майкрософт тоже пытается следовать этим рекомендациям.

Единственное исключение - это таблицы, используемые в качестве структур данных (как, к примеру, InventDimParm)

[S.Kuskov]

Цитата:

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

На самом деле, следует делать так, как советует Майкрософт.

В АХ 2012 рекомендация о наименовании временных таблиц была изменена с "Prefix" на "Infix".

Вопрос. А почему на Infix, а не на suffix?

[kashperuk]

Цитата:

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

Вопрос. А почему на Infix, а не на suffix?

Ну, здесь я могу только гадать, но предполагаю, что это связано с мнемоникой произношения названия таблицы

То бишь, правильнее сказать "Temporary customer transactions" (CustTmpTrans с учетом того, что мы хотим, чтобы она располагалась рядом с другими Cust таблицами) чем "Customer transactions temporary" (CustTransTmp)

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

Насколько я понимаю, указание "Tmp" в имени объекта призвано подчеркнуть тот факт, что временная таблица - это объект приложения отличный от собственно таблицы. Другой тип объектов. Однако по каким-то причинам разработчки Axapta не хотят или не могут довести это выделение до логического конца и выделить этот тип объектов в отдельную ветку AOT, как это было сделано с Maps и Views.

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

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

Рекомендация Best Practices о наименовании временных таблиц имеет смысл, если предполагается выполнение неких групповых операций с однотипными объектами именно в AOT. Не в программном коде, а непосредственно в дереве объектов. Так сразу и не приходит в голову, чтобы такое это могло бы быть. Причем настолько важное, что явно пожертвовали удобством использования в программном коде. Вероятно, это какие-то системные "заморочки" разработчиков Axapta.

Есть какие-либо идеи, что это могут быть за операции? Или я ошибаюсь в своих предположениях? Если эти операции не имеют отношения к процессу разработки, может, лучше не следовать рекомендациям Best Practices в данном случае?

[S.Kuskov]

Цитата:

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

Насколько я понимаю, указание "Tmp" в имени объекта призвано подчеркнуть тот факт, что временная таблица - это объект приложения отличный от собственно таблицы. Другой тип объектов.

Любую постоянную таблицу лёгким движением руки (при помощи использования метода setTmp()) можно превратить во временную. Так что тут не полная аналогия

Цитата:

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

Рекомендация Best Practices о наименовании временных таблиц имеет смысл, если предполагается выполнение неких групповых операций с однотипными объектами именно в AOT. Не в программном коде, а непосредственно в дереве объектов. Так сразу и не приходит в голову, чтобы такое это могло бы быть. Причем настолько важное, что явно пожертвовали удобством использования в программном коде. Вероятно, это какие-то системные "заморочки" разработчиков Axapta.

Есть какие-либо идеи, что это могут быть за операции?

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

[gl00mie]

Цитата:

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

Насколько я понимаю, указание "Tmp" в имени объекта призвано подчеркнуть тот факт, что временная таблица - это объект приложения отличный от собственно таблицы. Другой тип объектов.

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

Цитата:

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

Однако по каким-то причинам разработчки Axapta не хотят или не могут довести это выделение до логического конца и выделить этот тип объектов в отдельную ветку AOT, как это было сделано с Maps и Views.

Ни разу это не другой тип объектов: свойства, поля, индексы, методы - все то же самое. Раньше времянки еще в базе не хранились, так в 2012-й появился тип временных таблиц, хранящихся в tempdb - и где же другой тип? Стоит напомнить также, что с точки зрения Dict-классов Map, View, обычная и временная таблица отличаются друг от друга лишь парой свойств. "Не умножайте сущности без необходимости".

Цитата:

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

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

Если следовать рекомендациям Best Practices, получим группировку таблиц, во-первых, по модулю, во-вторых, по тому, является ли таблица "перманентно временной" или же "конфигурируемо временной". Раньше с точки зрения Best Practices приоритетность группировки была иной.

Цитата:

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

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

Все проще: "map" и "view" - это существительные, а tmp - сокращение от прилагательного. В английском языке, как уже отмечалось, существительные в предложениях принято ставить после относящихся к ним прилагательных, поэтому "map" и "view" - суффиксы, а "tmp" - infix; если бы в именование объектов приложения Аксапты была заложена грамматика, скажем, французского языка, то и Best Practices по именованию объектов были бы совсем иными Опять же, обратите внимание, что "map", "view" и таблица - это разные сущности (существительные), в то время как "temporary" - это лишь свойство сущности (прилагательное).

Цитата:

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

Рекомендация Best Practices о наименовании временных таблиц имеет смысл, если предполагается выполнение неких групповых операций с однотипными объектами именно в AOT. Не в программном коде, а непосредственно в дереве объектов. Или я ошибаюсь в своих предположениях?

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

Цитата:

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

Если эти операции не имеют отношения к процессу разработки, может, лучше не следовать рекомендациям Best Practices в данном случае?

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

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

Цитата:

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

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

С моей точки зрения, это просто вариант программного создания временной таблицы взяв за образец структуру обычной таблицы. То, что получится, будет НЕ постоянная таблица с особыми свойствами, а новый объект. Просто созданный не в AOT, а программно. Естесственно, что объект, созданный программно, может иметь произвольное имя.

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

Цитата:

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

Так что указание "Tmp" в названии таблицы служит лишь для того, чтобы проще было отличать "перманентно временные" таблицы от "конфигурируемо временных"

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

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

Цитата:

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

Ни разу это не другой тип объектов: свойства, поля, индексы, методы - все то же самое.

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

Ну, например, какой смысл для временных таблиц в свойствах Created... и Modified...? А свойство CacheLookup? Вызывает большое сомнение необходимость ключей для временных таблиц. Да Ваши же собственные слова о том, что часть свойств не указывается для временных таблиц! В общем, есть что повыбрасывать...

Цитата:

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

Раньше времянки еще в базе не хранились, так в 2012-й появился тип временных таблиц, хранящихся в tempdb - и где же другой тип?

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

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

Цитата:

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

Стоит напомнить также, что с точки зрения Dict-классов Map, View, обычная и временная таблица отличаются друг от друга лишь парой свойств. "Не умножайте сущности без необходимости".

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

Цитата:

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

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

Проблема в том, что следование рекомендациям Best Practices в данном случае - усложняет поиск нужных объектов в AOT. Это подробно обсуждалось в теме про префиксы.

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

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

[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 - это "отдельная сущность"?

[kashperuk]

Ну, учитывая, что namespaces у нас нет, а таблички хотелось бы называть так же, то была бы ошибка компиляции даже если бы они были в другом узле АОТ из-за конфликта имен. Поэтому все равно пришлось бы добавлять Tmp в название