Code&ID

[vavkin]

С чем связанно что в аксапте принято ссылаться по коду а не ID записи?

[George Nordic]

ID записи может и поменяться, допустим, при экспорте-импорте справочника. И вообще, ссылаться на служебную переменную, идентифицирующую запись - это ОЧЕНЬ ПЛОХОЙ ТОН!
В Аксе есть места, где есть связка по RecId, многие от этого страдают. Не делайте так.

С Уважением,
Георгий

[AndyD]

Посмотрите на EDT и его узел Relations - с помощью этого механизма обеспечивается логическая связь м-ду таблицами (а так же Relations на самих таблицах)

[vavkin]

Я не правильно сформулировал вопрос. Я хотел узнать почему вообще разработчики Аксапты решили делать ссылки по коду а не например по автоинкрементному ID или что нибудь в этом стиле. Я понимаю что это вопрос больше к разработчикам но все же

[AndyD]

В Axapta'е используется концепция естественных ключей, т.е. по самому ключу можно определить характер записи. По-этому и применяются символьные поля в качестве ключевых

[macklakov]

Импорт/экспорт данных гораздо удобнее становится. Есть вероятность, что в другой системе id окажется не числовым, и тогда загрузка связанных таблиц может превратиться в достаточно сложный процесс. Кроме того, есть такая удобная вещь, как "переход к основной таблице"

[George Nordic]

Цитата:

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

Я не правильно сформулировал вопрос. Я хотел узнать почему вообще разработчики Аксапты решили делать ссылки по коду а не например по автоинкрементному ID или что нибудь в этом стиле. Я понимаю что это вопрос больше к разработчикам но все же

Хм. А при переносе данных Вы сможете таким механизмом гарантировать целостность данных? Если да, то Вам впору писать собственную ERP
Кстати, этот вопрос очень часть встречается от людей, которые приходят на Axapta с 1С. 1С ники из-за ссылочных таблиц, кроме всего прочего, хлебнули и с производительностью

С Уважением,
Георгий

[macklakov]

Вообщем можно резюмировать следующим образом:
RecId следует использовать только совместно с TableId

[vavkin]

Цитата:

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

В Axapta'е используется концепция естественных ключей, т.е. по самому ключу можно определить характер записи. По-этому и применяются символьные поля в качестве ключевых

Не совсем понял что имеется ввиду под словом "характер записи", что это за поле клиент или договор видно из названия поля, а информацию о записи (номер, фамилию) ERP система могла бы получить join'ом или вложенным запросом

[vavkin]

Цитата:

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

Импорт/экспорт данных гораздо удобнее становится. Есть вероятность, что в другой системе id окажется не числовым, и тогда загрузка связанных таблиц может превратиться в достаточно сложный процесс. Кроме того, есть такая удобная вещь, как "переход к основной таблице"

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

[belugin]

Тема рассмотрена в
Естественные ключи против исскуственных ключей, Синтетические и естественные ключи. [обсуждение темы БП] .
Оба подхода имеют своих сторонников. Лично мне ближе прозрачное использование СК - абстрагирует механизм идентификации записей.

[macklakov]

Цитата:

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

ERP система могла бы получить join'ом или вложенным запросом

Пример: Форма Заказ, в ней указаны Клиент, Счет На, Валюта, Аналитика и еще десяток параметров. Все они допускают фильтрацию, сортировку и т.д. Представляете, во что превратится эта задача, если для получения этих значений будет использоваться join? Кроме того, усложняется механизм добавления записей/редактирования.
Для эксперимента попробуйте добавить хотя бы одно подобное поле. Засеките время которое потратите. Сравните быстродействие ;-)

Цитата:

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

Превратиться в сложный процесс в плане написания модификации или в плане производительности?

Обычно, модификации писать вообще не нужно, все делается стандартным импортом. В данном случае, придется заменять текстовые id, на числовые, а затем заменять их в связанных таблицах, что не тривилано. Производительность, в данном случае, особой роли не играет, т.к. импорт/экспорт обычно разовая операция
P.S. Кстати, проблемы с быстродействием возникают вовсе не из-за текстовых ключей ;-)

[vavkin]

Цитата:

Сообщение от George Nordic

Хм. А при переносе данных Вы сможете таким механизмом гарантировать целостность данных?

Если имеется ввиду полный перенос то да, при переносе не обязательно сразу пользоваться autoincrement, можно вначале просто копировать данные а потом включить уже включить autoincrement. Если имеется ввиду объединение баз то int могут совпасть ровно с таким же успехом как и Code. И у Code здесь нет преимуществ.
И вообще почему бы не использовать uniqueidentifier (GUID)

[AndyD]

Ну, во-первых, из названия поля видно только к какой таблице оно относится (да и то не факт), но не видно, что это за клиент или договор. Цифровой абстрактрый код здесь мало поможет

Во-вторых, из одного столбца разные записи одной и той-же таблицы могут ссылаться на разные связанные таблицы (как пример - поле Кор.счет в журналах Главной книги)

[vavkin]

Цитата:

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

Пример: Форма Заказ, в ней указаны Клиент, Счет На, Валюта, Аналитика и еще десяток параметров. Все они допускают фильтрацию, сортировку и т.д. Представляете, во что превратится эта задача, если для получения этих значений будет использоваться join? Кроме того, усложняется механизм добавления записей/редактирования.
Для эксперимента попробуйте добавить хотя бы одно подобное поле. Засеките время которое потратите. Сравните быстродействие ;-)

Дело в том что часто видеть просто код недостаточно, зачастую он мало о чем говорит. Получается что по любому надо выводить дополнительную информацию и тогда надо связывать с другой таблицей, и тогда join предпочтительнее чем display метод который будет вызываться на каждую запись и по которому нельзя сделать фильтр. Получается что код хорош только в том случае когда достаточно видеть только его и никакой дополнительной информации.

[George Nordic]

Цитата:

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

Если имеется ввиду объединение баз то int могут совпасть ровно с таким же успехом как и Code. И у Code здесь нет преимуществ.
И вообще почему бы не использовать uniqueidentifier (GUID)

Вам же сказали:
-Упрощение сопровождения
-Уменьшение размера БД
-Увеличение скорости выборки данных
-Увеличение скорости обновления данных
-В системе с ЕК меньше JOIN`ов, следовательно, запросы проще и разработка удобнее
-Введение СК нарушает третью нормальную форму
-Таблицы в системе с ЕК информативнее

Если есть контрпримереры - давай поспорим. Действительно, есть спорные моменты.
Ведь, как я понимаю, это чисто теоритический спор? Или Вы планируете использоватть GUIN в качестве ключа при разработке собственных таблиц?
Лично мне нравится в виде ключа видеть "МИ-АКС-НОГ(40) 100х20", чем 123579 или 1657-AB10-C548F-4564-BD20

С Уважением,
Георгий.

[sukhanchik]

Вообще сравнение архитектур баз данных с "естественными" ключами и "искусственными" - это вопрос большой полемики - это как Windows и Linux, Delphi/Basic/C++ и т.д. Каждый подход имеет свои преимущества и недостатки. У "естественных" ключей преимущество в первую очередь в простоте программирования. Ведь все-таки изначально - Axapta не среда разработки а ERP-система. Ведь достаточно в табличку напихать 3 поля - напр CustAccount, RContractAccount, RContractCode - и уже это будет осмысленная информация, от которой можно будет перейти к справочникам через основную таблицу. И к форме будет прилеплена только одна табличка. В "искусственных" ключах - для получения подобного эффекта - нужно будет прилепить 3 таблички к форме (тк в главной табличке будут только некие бессмысленные числовые коды). И сразу встает вопрос - что лучше - открыть форму и при открытии лезть в 3 таблички (чтобы имена получить), либо сделать 3 ключа текстовыми. С точки зрения пользователя - информация нагляднее выглядит когда используются "естественные" ключи. А производительность можно увеличить мощностью сервера.
В этом случае разработчики и предпочли одно из решений. 1С - выбрала другое решение. Каждая система заняла свою нишу.

[vavkin]

Цитата:

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

В этом случае разработчики и предпочли одно из решений. 1С - выбрала другое решение. Каждая система заняла свою нишу.

Я сомневаюсь что они заняли разные ниши именно из за выбора типа ключей.

[George Nordic]

Цитата:

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

Я сомневаюсь что они заняли разные ниши именно из за выбора типа ключей.

Тогда почему у 1С проблемы с производительностью именно Базы Данных? БД-то одно. А вот организация хранения данных - разная. Вы на 1С раньше программировали?

С Уважением,
Георгий

[vavkin]

Цитата:

Сообщение от George Nordic

-Упрощение сопровождения
-Уменьшение размера БД
-Увеличение скорости выборки данных
-Увеличение скорости обновления данных
-В системе с ЕК меньше JOIN`ов, следовательно, запросы проще и разработка удобнее
-Введение СК нарушает третью нормальную форму
-Таблицы в системе с ЕК информативнее

Если есть контрпримереры - давай поспорим. Действительно, есть спорные моменты.
Ведь, как я понимаю, это чисто теоритический спор? Или Вы планируете использоватть GUIN в качестве ключа при разработке собственных таблиц?
Лично мне нравится в виде ключа видеть "МИ-АКС-НОГ(40) 100х20", чем 123579 или 1657-AB10-C548F-4564-BD20

Это не теоретический спор. Практический, и для меня даже очень.
Теперь по пунктам.
"Упрощение сопровождения" - не вижу никаких преимуществ одного перед другим.
"Уменьшение размера БД" - за счет чего она уменьшится? если использовать int то при code размер будет больше, если GUID который 16 символов то тоже меньше чем если Code который 20, я могу ошибиться в кол-ве символов, да на самом деле не так уж это важно, будет на 2 % больше размер или меньше. У этого пункта нет преимуществ, точнее по этому пункту Code проигрывает
"Увеличение скорости выборки данных" за счет чего? При выводе связанной информации int по крайней мере не медленнее чем Code и я сильно сомневаюсь что GUID медленне чем Code. По этому пункту Code выигрывает только в том случае если он сам по себе достаточен и не нужен join, как только появляется связь (а она появится) то Code не выигрвает а скорее проигрывает.
"Увеличение скорости обновления данных" честно говоря вообще не понятно за счет чего, можно поподробнее?
"В системе с ЕК меньше JOIN`ов, следовательно, запросы проще и разработка удобнее" проще только разработка форм и то в том случае когда опять же коды самодостаточны. При разработке модификации как таковой вообще не вижу преимуществ у Code, ведь значения кодов не сипользуются в тексте модификации и значит мне как программеру все равно что там в нем ID или Code. В системе с ЕК меньше join'ов только при выводе формы, в отчетах все равно надо связываться со связынными таблицами.
"Введение СК нарушает третью нормальную форму" каким образом?
"Таблицы в системе с ЕК информативнее" они информативнее только в том случае если их смотреть через Enterprise manager, но как правило их смотрят через систему и система могла бы сама выполнить автоматически join и тогда пользователю становится все равно как хранятся данные внутри.
"Или Вы планируете использоватть GUIN в качестве ключа при разработке собственных таблиц?" По крайней мере вижу причин не использовать их
"Лично мне нравится в виде ключа видеть "МИ-АКС-НОГ(40) 100х20", чем 123579 или 1657-AB10-C548F-4564-BD20" это относится к информативности и я уже высказался выше.