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

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

Цитата:

Сообщение от 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

[CDR]

Цитата:

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

Как вариант, использовать 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 контрол такого не понимает и отобразить не может. Очень негибко.

[CDR]

Цитата:

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

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

Это был сарказм, если что.