Используете ли вы суррогатные ключи?

[IKA]

Собственно, вопрос: Используете ли вы суррогатные ключи?
Когда - да, когда - нет? Если это простой справочник, то будете его создавать?

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



Спасибо

[sukhanchik]

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

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

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

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

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

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

[belugin]

Некоторые аргументы за СК приведены здесь

• С СК несколько сложнее отлаживаться и делать импорт и экспорт.
• Контролы в Ax2012 достаточно хорошо поддерживают СК, но надо не забывать обяснять аксапте про связи
• Аксапта поддерживает переименование первичного ключа, так что в принципе можно его переименовывать, но на больших объемах это будет тормозить (так что если ваш EK это наименование чего-то - то оно может либо потерять актуальность либо потребовать длительной процедуры, если много ссылок).
• Отдельный интерес вызывают составные ЕК, в особенности как поведут себя сочетания релейшенов на отдельных полях и общего релейшена на таблице.
• Аксапта не поддерживает индексов на view то есть, если надо будет проиндексировать поле из другой таблицы, то надо будет как-то денормализовывать. В случае если это поле будет EK этой другой таблицы, то можно будет включить его в индекс без дополнительных действий. Если будет СК, надо будет создавать дополнительное поле и как-то его заполнять. Правда то же самое будет, если поле не совпадет с ЕК.
• В Ax2012 разрядность RecID - 64 бита, так что 1) Не надо выполнять дефрагментацию RecID 2) по размеру теоретически выигрыш наступает при длине ЕК больше 4 юникодных символа.

[Alexius]

С СК нельзя использовать Array, по крайней мере в АХ 2012 R2.

[MikeR]

Цитата:

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

С СК нельзя использовать Array, по крайней мере в АХ 2012 R2.

А кто и насколько часто пользуется именно Array?

[raz]

Цитата:

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

А кто и насколько часто пользуется именно Array?

Hardly ever

[MikeR]

Цитата:

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

Hardly ever

Это я к тому, что этот объект я как-то использовал в java в программировании модема, где не было базы данных и надо было все хранить в подобных структурах, запаковывать один массив другой и так далее. В аксе есть БД и использовать Array ну как бы совсем уж рудмент. Тем более, что есть временные таблицы, любимые народом Map и все такое.
Ну и как бы если Array что-то не поддерживает, да и бог бы с ним.
Если быть уже совсем близко к тебе, я за бизнес ключи.
Суррогаты хорошо. но бизнес, как говорится, ближе к телу.
Некоторую религию, которую в аксу притянули индоамериканцы, считаю ересью.
Это мое имхо, и спорить об этом со мной не надо.

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

Спорить и рассуждать по этому поводу можно долго и вдумчиво, но начиная с Ax2012 "правилом" является использование системного поля RecId в качестве суррогатного ключа

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

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

Т.е. все-таки, всегда сначала стоит следовать "правилу", принятому в текущей системе.

[IKA]

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

Спасибо всем

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

Цитата:

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

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

"Здравый смысл" - это всего-лишь опыт Проблема в том, что это опыт, приобретенный в другой версии системы. Работающей по другим "правилам". И в новой версии системы этот опыт может завести сильно не туда.

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

[CDR]

Использую сам и требую от других, чтоб использовали, так как отныне это "лучшие мировые практики" и ошибка BP.

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

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

Ну и забавный глюк или фича, связанная с использованием суррогатных ключей - это невозможность поиска пустых значений в следствие специфики реализации outer join. Т.е. система прекрасно позволяет найти в документе значение "А" или "Б" в поле на основе RecId, но не позволяет найти пустые значения в этом поле.
И если пользователю ну прямо очень нужен такой фильтр - приходится делать отдельную кнопку или как-то еще извращаться. Ну а пользователю рассказывать про "лучшие мировые практики", которые требуют для поиска пустых значений отдельную кнопку. Со стороны пользователя, наверное, кажусь идиотом, но что он вообще понимает в "лучших мировых практиках". Для него, конечно, без разницы, какое значение в поле искать. Хорошо, что хоть потребность в поиске пустых значений возникает не часто.

[Stitch_MS]

Цитата:

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

И если пользователю ну прямо очень нужен такой фильтр - приходится делать отдельную кнопку или как-то еще извращаться.

Как вариант, использовать QueryFilter вместо QueryBuildRange:
https://msdn.microsoft.com/en-us/library/gg881181.aspx

[Logger]

Цитата:

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

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

А как же отладчик ? Неудобно видеть везде recid значения.

Цитата:

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

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

Как-то легко вы идете на такие жертвы. Видимо проблемы с производительностью еще не допекали. Или вы придумали простой способ как их обойти ?


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

Если же поле было суррогатным ключом то так просто не получится. По крайней мере reference контрол такого не понимает и отобразить не может. Очень негибко.