AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.05.2011, 18:49   #1  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,699 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Как правильно именовать временные таблицы
В ранних версиях Best Practices рекомендовалось начинать имя временной таблицы с префикса "Tmp". Например, TmpCustLedger

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

Есть ли вообще практический смысл как-то обозначать тот факт, что таблица является временной непосредственно в имени таблицы? Если есть, то стоит ли придерживаться рекомендаций Best Practices или же, например, писать "Tmp" как окончание (или суффикс) имени?
Старый 12.05.2011, 19:14   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
мне кажется, что практического смысла нет.
все равно в коде любую таблицу можно объявить временной.
поэтому все равно надо отслеживать код.

кроме того, в ax2012 уже и майкрософт не придерживается своих best Practice по наименованиям таблиц.
__________________
полезное на axForum, github, vk, coub.
Старый 12.05.2011, 19:21   #3  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1243 (44) ++++++++
Регистрация: 11.04.2008
Удобнее всего "Tmp" ставить в самом конце имени, тогда, сортируясь по алфавиту в АОТ, таблица будет находиться на своем месте, среди таких же таблиц, относящихся к общей функциональности, напр. CustPaymOnlineTransTmp. Если же "Tmp" всунуть после названия модуля (CustTmpPaymOnlineTrans), то все временные таблицы модуля "уйдут" вниз АОТ, что неудобно и лишено смысла.

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

Последний раз редактировалось DSPIC; 12.05.2011 в 19:27.
Старый 12.05.2011, 19:41   #4  
lvan is offline
lvan
Участник
Аватар для lvan
Лучший по профессии 2014
 
858 / 82 (4) ++++
Регистрация: 15.04.2011
Записей в блоге: 1
Вот ещё вариантик :
TCustMLedgerP

и вначале и в середине и в конце!
Старый 12.05.2011, 20:00   #5  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,440 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Есть ли вообще практический смысл как-то обозначать тот факт, что таблица является временной непосредственно в имени таблицы?
Смысл в том чтобы сделать более удобным чтение кода. Т.к. в аксапте ещё принято чтобы имя табличного курсора совпадало с именем таблицы, то при работе с таким курсором по его имени сразу будет понятно что он временный.
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если есть, то стоит ли придерживаться рекомендаций Best Practices или же, например, писать "Tmp" как окончание (или суффикс) имени?

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

Современная версия Best Practices (Ax2009) рекомендует вставлять "Tmp" непосредственно за обозначением модуля. Например, CustTmpLedger
Рекомендации и старая и новая явно направлены на то чтобы сгрупировать временные таблицы при помощи порядка их следования в AOT. Раньше все временные таблицы собирались бы в разрезе модулей в одном месте, а теперь в каждом модуле получится своя группа временных. Много ли в этом смысла? Не знаю, но раз уж так настойчиво рекомендуют должно что-то быть
Лично я в этом вопросе согласен с DSPIC
Старый 12.05.2011, 23:10   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Есть ли вообще практический смысл как-то обозначать тот факт, что таблица является временной, непосредственно в имени таблицы?
По-моему, смысл есть и вот какой: таблицы в Аксапте - это, образно говоря, сгусток метаданных Каждое свойство самой таблицы, ее полей, индексов несет глубокий смысл и может влиять на поведение очень многих мест приложения. В то же время, в случае временных таблиц правила заполнения разного рода свойств обычно соблюдаются "спустя рукова", что в принципе оправдано. Так вот, не скажу за всех, но если я лично вижу на текущем слое таблицу, у которой не выставлен ключ контроля доступа, или метка, или FormRef, или TitleFields, или у которой поля, являющиеся первичным ключом, не помечены как обязательные к заполнению и редактируемые лишь при создании записи... в общем, у меня лично первая реакция - "КАКОЙ <CENSORED> ЭТО СДЕЛАЛ?!" А если таблица временная - ну что ж... фиг бы с ним, может, она вообще нужна лишь для хранения/передачи наборов разнотипных значений как прекрасная альтернатива ненавистным контейнерам. В общем, явное указание в имени того, что таблица - временная, может в каких-то случаях сэкономить несколько нервных клеток
Старый 13.05.2011, 10:24   #7  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,699 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от S.Kuskov
Смысл в том чтобы сделать более удобным чтение кода. Т.к. в аксапте ещё принято чтобы имя табличного курсора совпадало с именем таблицы, то при работе с таким курсором по его имени сразу будет понятно что он временный.

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

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

Если Вы видите, что у таблицы, например, не выставлен ключ контроля, то для того, чтобы определить временная это таблица или нет Вы будете смотреть на ее имя или таки на свойство Temporary? В смысле, если уж дело дошло до анализа свойств таблицы, то не все ли равно, как эта таблица называется?
Старый 13.05.2011, 10:32   #8  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Я по-привычке выставляю в настройках сортировку свойств по алфавиту - при этом на моем мониторе с разрешением 1680х1050 свойство Temporary таблицы не помещается на экране, и чтобы его увидеть, свойства нужно прокрутить вниз По имени лично мне ориентироваться проще. Собственно, думаю, Best Practices по именованию таблиц тоже возникли не на пустом месте, а то ведь модуль, к которому относится таблица, и ее "тип" (справочник, группы, проводки, и т.п.) тоже ведь можно было бы не из имени узнавать, а из свойств или, там косвенных признаков вроде примеров использования таблицы в коде...
Старый 13.05.2011, 15:10   #9  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,628 / 627 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Я понимаю, что, наверное, слишком дорого отслеживать Best Practices вендору среди своих молодых разработчиков.
Но, и еще раз но... быстрота поиска и распознавания сущности стоит этих усилий.
__________________
Axapta book for developer
Старый 13.05.2011, 15:19   #10  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,699 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от MikeR Посмотреть сообщение
Я понимаю, что, наверное, слишком дорого отслеживать Best Practices вендору среди своих молодых разработчиков.
Но, и еще раз но... быстрота поиска и распознавания сущности стоит этих усилий.

Можно уточнить о чем речь? Какое отношение данный ответ имеет к заданному вопросу?
Старый 13.05.2011, 15:29   #11  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,440 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Какие преимущества (бонусы) дает программисту знание того факта, что данная таблица временная до анализа программного кода? В чем заключается это самое "удобство чтения кода"?
Ну например, какой-нибудь метод принимает в качестве параметра табличный курсор. Если курсор временный, то можно предположить что передаётся не просто запись (возможно и такое), а ссылка на временный буфер. И соответственно ожидать от кода уже можно обработку не только одной записи а нескольких.
Старый 13.05.2011, 15:43   #12  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
На самом деле, следует делать так, как советует Майкрософт.
В АХ 2012 рекомендация о наименовании временных таблиц была изменена с "Prefix" на "Infix".

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

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

Единственное исключение - это таблицы, используемые в качестве структур данных (как, к примеру, InventDimParm)
Старый 13.05.2011, 16:00   #13  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,440 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от kashperuk Посмотреть сообщение
На самом деле, следует делать так, как советует Майкрософт.

В АХ 2012 рекомендация о наименовании временных таблиц была изменена с "Prefix" на "Infix".
Вопрос. А почему на Infix, а не на suffix?
Старый 13.05.2011, 16:10   #14  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Вопрос. А почему на Infix, а не на suffix?
Ну, здесь я могу только гадать, но предполагаю, что это связано с мнемоникой произношения названия таблицы

То бишь, правильнее сказать "Temporary customer transactions" (CustTmpTrans с учетом того, что мы хотим, чтобы она располагалась рядом с другими Cust таблицами) чем "Customer transactions temporary" (CustTransTmp)
Старый 16.05.2011, 14:46   #15  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,699 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Насколько я понимаю, указание "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 в данном случае?
Старый 16.05.2011, 15:03   #16  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,440 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Насколько я понимаю, указание "Tmp" в имени объекта призвано подчеркнуть тот факт, что временная таблица - это объект приложения отличный от собственно таблицы. Другой тип объектов.
Любую постоянную таблицу лёгким движением руки (при помощи использования метода setTmp()) можно превратить во временную. Так что тут не полная аналогия

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

Есть какие-либо идеи, что это могут быть за операции?
Разовью вашу мысль. Возможно временные таблицы решили "скучковать" не столько для того чтобы над ними самими выполнять какие-то груповые действия, а для того чтобы они не мешали подобные действия выполнять над оставшимися, т.е постоянными таблицами. Возможно в будущем появятся действия (синхронизации, индексации), которые не будут совместимы одновременно и с временными и постоянными таблицами.
Старый 16.05.2011, 15:34   #17  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Ну, учитывая, что namespaces у нас нет, а таблички хотелось бы называть так же, то была бы ошибка компиляции даже если бы они были в другом узле АОТ из-за конфликта имен. Поэтому все равно пришлось бы добавлять Tmp в название
Старый 16.05.2011, 15:45   #18  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,699 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Ну, учитывая, что namespaces у нас нет, а таблички хотелось бы называть так же, то была бы ошибка компиляции даже если бы они были в другом узле АОТ из-за конфликта имен. Поэтому все равно пришлось бы добавлять Tmp в название
Да, конечно. Только в любом случае это не будет совпадать с тем, что рекомендует Best Practices сейчас. Поскольку логика именования будет другой:

1. Если имя временной таблицы не совпадает с именем обычной таблицы, то конфликат имен нет. Нет необходимости добавлять "Tmp"
2. Если совпадает, то, скорее всего, добавили бы "Tmp" в конец имени, а не в начало или середину.

В качестве примера можно опять же привести узлы Views или Maps, где именно такая логика именования и реализована.
Старый 17.05.2011, 01:43   #19  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Насколько я понимаю, указание "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 - облегчение другим программистам, знакомым с ними, понимание кода и вообще модификаций, хотя насколько эта возможность ценна, каждый решает для себя сам.
Старый 17.05.2011, 11:51   #20  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,699 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от 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 - это все-таки отдельный объект! Отдельная сущность.
Теги
временная таблица, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Временные таблицы и их временные файлы AraraT® DAX: Прочие вопросы 6 12.04.2010 00:39
И опять временные таблицы ek_Pendulum DAX: Программирование 22 07.05.2007 11:30
И снова Query и временные таблицы Def DAX: Программирование 19 08.12.2006 15:46
Временные таблицы в отчетах konfet DAX: Программирование 5 19.01.2005 11:32
Временные таблицы Diamond DAX: Программирование 3 30.12.2003 09:33

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 15:24.