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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 08.02.2018, 15:08   #1  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Используете ли вы суррогатные ключи?
Собственно, вопрос: Используете ли вы суррогатные ключи?
Когда - да, когда - нет? Если это простой справочник, то будете его создавать?

По библии, нужно создавать, а на практике, по-моему, редко кто их делает
Если бы вам дали код на ревью, вы бы как восприняли тот факт, что новые таблицы
сурргатные ключи не используют (Ax2012R3 )



Спасибо
Старый 08.02.2018, 17:07   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,271 / 3465 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Суррогатные ключи и есть RecId в понятии АХ - т.о. их специально создавать не надо. Конечно можно и свой создать, но это уже будет совсем излишняя работа (на мой взгляд).

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

На практике ключевыми критериями необходимости суррогатного ключа для меня всегда являлось:
1. Удобство переноса данных (если данные необходимо переносить - например, это те или иные настройки) - то суррогатные ключи идут лесом - это сильное усложнение поддержки. Библия библией, а простота поддержки важнее библии (это лично мое мнение).

2. Необходимость иметь некий идентификатор для пользователя, например, код заказа на продажу, код ваучера и т.д. В этом случае суррогатные ключи непрезентабельны и опять лишний раз усложняют работу с данными. К примеру, InventDimId вполне мог себе быть суррогатным ключом, т.к. он не является для пользователя каким-либо идентификатором.

3. Заведомо известная ситуация, при которой ключом является другое поле (не RecId). Например, импортируются данные из другой программы вместе с идентификатором записи из другой программы. В этом случае (если заведомо точно известно, что ошибочных ситуаций быть не может) ключом можно назначить другое поле. Это удобно, если по этому полю (что скорее всего) будет выполняться поиск.

Ну а в остальных случаях ... в общем -то можно обойтись и суррогатными ключами. Хотя лично мне ближе в душе естественные ключи и суррогатный ключ я большей частью делаю только в том случае, когда использование естественного ключа неудобно / невозможно (тот же InventDimId по сути - суррогатный ключ)
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: IKA (1), Prof (1).
Старый 08.02.2018, 19:21   #3  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Некоторые аргументы за СК приведены здесь
  • С СК несколько сложнее отлаживаться и делать импорт и экспорт.
  • Контролы в Ax2012 достаточно хорошо поддерживают СК, но надо не забывать обяснять аксапте про связи
  • Аксапта поддерживает переименование первичного ключа, так что в принципе можно его переименовывать, но на больших объемах это будет тормозить (так что если ваш EK это наименование чего-то - то оно может либо потерять актуальность либо потребовать длительной процедуры, если много ссылок).
  • Отдельный интерес вызывают составные ЕК, в особенности как поведут себя сочетания релейшенов на отдельных полях и общего релейшена на таблице.
  • Аксапта не поддерживает индексов на view то есть, если надо будет проиндексировать поле из другой таблицы, то надо будет как-то денормализовывать. В случае если это поле будет EK этой другой таблицы, то можно будет включить его в индекс без дополнительных действий. Если будет СК, надо будет создавать дополнительное поле и как-то его заполнять. Правда то же самое будет, если поле не совпадет с ЕК.
  • В Ax2012 разрядность RecID - 64 бита, так что 1) Не надо выполнять дефрагментацию RecID 2) по размеру теоретически выигрыш наступает при длине ЕК больше 4 юникодных символа.
За это сообщение автора поблагодарили: Logger (3).
Старый 09.02.2018, 10:03   #4  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
С СК нельзя использовать Array, по крайней мере в АХ 2012 R2.
Старый 12.02.2018, 15:56   #5  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,649 / 1146 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Спорить и рассуждать по этому поводу можно долго и вдумчиво, но начиная с Ax2012 "правилом" является использование системного поля RecId в качестве суррогатного ключа

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

Соответственно, стоит придерживаться такого же принципа деления. Если Вы делаете расширение существующего функционала, где Primary Key - это естественный ключ, то такой же тип Primary Key сделать у нового функционала. Если это совсем новый функционал, не имеющий аналогов, то использовать суррогатный ключ по RecId

Т.е. все-таки, всегда сначала стоит следовать "правилу", принятому в текущей системе.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 12.02.2018, 16:42   #6  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Бывает здравый смысл, а бывает - следование политике партии, отсюда, соответственно, и возник же вопрос... Я могу просто недооценивать что-то, поэтому и поинтересовалась

Спасибо всем
Старый 12.02.2018, 19:27   #7  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,649 / 1146 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от IKA Посмотреть сообщение
Бывает здравый смысл, а бывает - следование политике партии, отсюда, соответственно, и возник же вопрос... Я могу просто недооценивать что-то, поэтому и поинтересовалась
"Здравый смысл" - это всего-лишь опыт Проблема в том, что это опыт, приобретенный в другой версии системы. Работающей по другим "правилам". И в новой версии системы этот опыт может завести сильно не туда.

Именно поэтому и советую, по возможности, придерживаться правил текущей системы. В Ax2012 уже все "заточено" под RecId. И автоматическое отображение на форме вместо RecId значений альтернативных ключей, и автоматический поиск по альтернативным ключам, и автоматическое приджойнивание таблиц-справочников. Много всего, в общем.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: Vadik (1).
Старый 16.02.2018, 11:11   #8  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Использую сам и требую от других, чтоб использовали, так как отныне это "лучшие мировые практики" и ошибка BP.

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

Попытки MS обосновать использование суррогатных ключей увеличением производительности выглядят довольно нелепо. Если раньше добавление в документ ссылки на 5 новых справочников практически никак не отражались на производительности, то теперь это + 5 дополнительных outer join к основному запросу формы. В купе с таблицами-экстеншенами жалкое зрелище на более-менее приличных объемах данных. Но, искусство требует жертв...

Ну и забавный глюк или фича, связанная с использованием суррогатных ключей - это невозможность поиска пустых значений в следствие специфики реализации outer join. Т.е. система прекрасно позволяет найти в документе значение "А" или "Б" в поле на основе RecId, но не позволяет найти пустые значения в этом поле.
И если пользователю ну прямо очень нужен такой фильтр - приходится делать отдельную кнопку или как-то еще извращаться. Ну а пользователю рассказывать про "лучшие мировые практики", которые требуют для поиска пустых значений отдельную кнопку. Со стороны пользователя, наверное, кажусь идиотом, но что он вообще понимает в "лучших мировых практиках". Для него, конечно, без разницы, какое значение в поле искать. Хорошо, что хоть потребность в поиске пустых значений возникает не часто.
__________________
Dynamics AX Experience
За это сообщение автора поблагодарили: Logger (3).
Старый 16.02.2018, 11:57   #9  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от CDR Посмотреть сообщение
И если пользователю ну прямо очень нужен такой фильтр - приходится делать отдельную кнопку или как-то еще извращаться.
Как вариант, использовать QueryFilter вместо QueryBuildRange:
https://msdn.microsoft.com/en-us/library/gg881181.aspx
Старый 16.02.2018, 12:01   #10  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от CDR Посмотреть сообщение
Маленькое неудобство состоит лишь в дополнительной конвертации RecId в что-то более понятное для пользователя при отображении сообщений пользователю через инфолог, когда где-то внутри класса нужно проверить ключевое значение RecId на предмет допустимости.
А как же отладчик ? Неудобно видеть везде recid значения.

Цитата:
Сообщение от CDR Посмотреть сообщение
Попытки MS обосновать использование суррогатных ключей увеличением производительности выглядят довольно нелепо. Если раньше добавление в документ ссылки на 5 новых справочников практически никак не отражались на производительности, то теперь это + 5 дополнительных outer join к основному запросу формы. В купе с таблицами-экстеншенами жалкое зрелище на более-менее приличных объемах данных. Но, искусство требует жертв...
Как-то легко вы идете на такие жертвы. Видимо проблемы с производительностью еще не допекали. Или вы придумали простой способ как их обойти ?


Еще из неудобств добавлю невозможность легко организовать ссылки на разные таблички.
Например было поле со ссылкой на строковый первичный ключ таблички. Пришло требование чтобы оно могло ссылаться на разные таблички. Раньше - просто добавляешь поле с енумом и делаешь Relation-ы (по аналогии с парой InventTrans.TransRefId, InventTrans.TransType).

Если же поле было суррогатным ключом то так просто не получится. По крайней мере reference контрол такого не понимает и отобразить не может. Очень негибко.
Старый 16.02.2018, 12:05   #11  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Как вариант, использовать QueryFilter вместо QueryBuildRange:
https://msdn.microsoft.com/en-us/library/gg881181.aspx
Вариант хороший, но немного не про то.
__________________
Dynamics AX Experience
Старый 16.02.2018, 12:07   #12  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от Logger Посмотреть сообщение
Как-то легко вы идете на такие жертвы. Видимо проблемы с производительностью еще не допекали. Или вы придумали простой способ как их обойти ?
Это был сарказм, если что.
__________________
Dynamics AX Experience
Старый 16.02.2018, 12:27   #13  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,628 / 627 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Сообщение от Alexius Посмотреть сообщение
С СК нельзя использовать Array, по крайней мере в АХ 2012 R2.
А кто и насколько часто пользуется именно Array?
__________________
Axapta book for developer
Старый 16.02.2018, 12:41   #14  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,490 / 1060 (38) ++++++++
Регистрация: 22.07.2003
Адрес: МО
Цитата:
Сообщение от MikeR Посмотреть сообщение
А кто и насколько часто пользуется именно Array?
Hardly ever
За это сообщение автора поблагодарили: MikeR (2).
Старый 16.02.2018, 14:13   #15  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,628 / 627 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Сообщение от raz Посмотреть сообщение
Hardly ever
Это я к тому, что этот объект я как-то использовал в java в программировании модема, где не было базы данных и надо было все хранить в подобных структурах, запаковывать один массив другой и так далее. В аксе есть БД и использовать Array ну как бы совсем уж рудмент. Тем более, что есть временные таблицы, любимые народом Map и все такое.
Ну и как бы если Array что-то не поддерживает, да и бог бы с ним.
Если быть уже совсем близко к тебе, я за бизнес ключи.
Суррогаты хорошо. но бизнес, как говорится, ближе к телу.
Некоторую религию, которую в аксу притянули индоамериканцы, считаю ересью.
Это мое имхо, и спорить об этом со мной не надо.
__________________
Axapta book for developer
Старый 16.02.2018, 14:30   #16  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от MikeR Посмотреть сообщение
Это я к тому, что этот объект я как-то использовал в java в программировании модема, где не было базы данных и надо было все хранить в подобных структурах, запаковывать один массив другой и так далее.
Я имел в виду Array-поля в контексте СК/ЕК, а используются они действительно не часто, хотя на мой взгляд - очень удобная конструкция.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Используете ли вы @SYS метки при создании своих партнерских расширений? kashperuk DAX: Программирование 35 12.03.2011 23:23
Покупка Аксапта... Лицензионные ключи и модули edd DAX: Прочие вопросы 20 20.12.2006 14:33
Используете ли Вы OLAP в Аксапте? Hidden DAX: Функционал 21 20.07.2006 17:19
Как загрузить лицензии чтобы не слетели конф. ключи? MironovI DAX: Администрирование 2 20.01.2006 12:42
Лицензионные ключи eremite DAX: Администрирование 12 26.07.2004 14:53
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.