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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.07.2007, 02:44   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5803 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от belugin Посмотреть сообщение
Кстати, ограничение в 7 таблиц - аксаптовское или откуда?
Здрассти... известный глюк парсера запросов в трешке. Уже и официально в MBS в 2005-м году писали об этом, и с порядком соединения datasource'ов люди шаманили, и выяснили, что вроде как глюки начинаются только со "2-го уровня" join, и даже что там, где на Ms SQL вылезает данный глюк, при использовании Oracle может быть все ok.
Старый 05.07.2007, 09:50   #2  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,628 / 627 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Есть ли количественные оценки выгоды от перехода str --> int?
на больших таблицах выигрыш будет ощутимым.
Старый 05.07.2007, 11:47   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Есть ли количественные оценки выгоды от перехода str --> int?
Насколько я понимаю, и в MS SQL и в Oracle, числовые поля с фиксированной точностью (numeric aka decimals) храняться как Binary Coded Decimal (То есть - каждый десятичный разряд занимает полбайта). Время поиска по уникальному ключу грубо приблизительно равняется логарифму числа записей по основанию числа ключей в странице. Соответствнно - чтобы посчитать выигрыш надо посчитать соотношение логарифмов по основанию n и n*2. Как-то я правила алгебры уже подзабыл порядком - попробуйте сами подсчитать в общем случае
Ну и по хорошему - надо еще помнить о том что в странице на каждый ключ еще добавляется 6-8 байтов служебной информации со ссылками. Поэтому - если ключи и так были короткие, то особого прорыва не случиться.
Теги
естественный ключ, искусственный ключ, как правильно, ключ, суррогатный ключ, crm2011

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Абстрактный классификатор Maxim Gorbunov DAX: Программирование 52 17.01.2005 13:52
Централизованные справочники ZVV DAX: Прочие вопросы 12 02.09.2004 13:42
А есть ли в Аксапте стандартные российские справочники? edd DAX: Функционал 11 22.07.2003 05:49
Как заполнять основные справочники? renat DAX: Функционал 9 13.11.2002 17:39
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра
Комбинированный вид Комбинированный вид

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

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

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