Code&ID

[vavkin]

Цитата:

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

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

Это всего лишь предположение, мне кажется что она менее производительнее не из за этого.

Цитата:

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

Вы на 1С раньше программировали?

Нет, я 5 лет назад программировал на Аксапте (и немного на Attain), сейчас уже все подзабыл и пытаюсь понять почему в Аксапте сделано именно так. Сейчас для меня важно определиться как делать дальше, на кодах или на ID. Можно конечно на этот вопрос ответить "Как вам удобнее так и делайте", но вот именно это я и пытаюсь понять

[vavkin]

Цитата:

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

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

За ссылки спасибо

[Alex_K]

2George Nordic
Георгий, как Вам такое значение естественного ключа (абсолютно реальное, из справочника номенклатуры одного крупного предприятия): "Гов.нов.коп.нар.т/у"? Можно понять без перевода, что это значит?

[AndyD]

Цитата:

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

Сейчас для меня важно определиться как делать дальше, на кодах или на ID.

Извините, а делать что? Программировать в Axapta'e?

[macklakov]

Цитата:

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

Дело в том что часто видеть просто код недостаточно, зачастую он мало о чем говорит.

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

Цитата:

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

Получается что по любому надо выводить дополнительную информацию .

Не полюбому, а только тогда, когда идентификаторы синтетические. А это скорее исключение, чем правило

Цитата:

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

Получается что код хорош только в том случае когда достаточно видеть только его и никакой дополнительной информации.

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

Цитата:

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

В системе с ЕК меньше join'ов только при выводе формы, в отчетах все равно надо связываться со связынными таблицами.

Да, но основная нагрузка на базу идет не от отчетов, а именно от форм и обработок. И быстродействие отчетов обычно не критично(за исключением печатных форм), чего нельзя сказать про формы.

[George Nordic]

Цитата:

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

2George Nordic
Георгий, как Вам такое значение естественного ключа (абсолютно реальное, из справочника номенклатуры одного крупного предприятия): "Гов.нов.коп.нар.т/у"? Можно понять без перевода, что это значит?

Хотя, если знать, что означают сокращения, то все довольно просто окажется. "МИ-АКС-НОГ(40) 100х20"
Это - Материалы Илкон, Аксесуары, Нога д/мебелили шагрень орех,
метр длиной.
Это уже вопрос, как закодировали.
Попробуйте расшифровать 135487

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

[belugin]

Цитата:

Можно конечно на этот вопрос ответить "Как вам удобнее так и делайте", но вот именно это я и пытаюсь понять

Делайте ЕК -- под него всё в Аксапте заточено.
Если не подходит, то Номерные Серии, а если уж и с ними не получается, то RecId

[Alex_K]

Цитата:

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

Хотя, если знать, что означают сокращения, то все довольно просто окажется...
Это уже вопрос, как закодировали.

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

Цитата:

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

Попробуйте расшифровать 135487

Даже и пытаться не буду. Но в справочнике номенклатуры с числом позиций более 1000, предпочту просто запомнить что это такое

[vavkin]

Цитата:

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

Извините, а делать что? Программировать в Axapta'e?

Если б в Аксапте то честно говоря сама концепция Аксапты предполагает коды и я бы сильно не размышлял. Мне именно интересно почему разработчики Аксапты решили завязаться на коды.

[vavkin]

Еще вот такой минус в сторону Code, если вдруг человек поймет что код он придумал неправильно то исправить его уже будет проблематично

[Alex_K]

Или "вдруг" оказалось, что некогда казавшаяся безупречной система кодирования "жмет" во всех направлениях...
IMHO, естественные ключи хороши для относительно небольших и/или хорошо структурированных "по жизни" справочников (например, номенклатура в электронике). В остальных случаях лично я предпочту сквозную нумерацию.

[mazzy]

Цитата:

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

Дело в том что часто видеть просто код недостаточно, зачастую он мало о чем говорит.

http://axapta.mazzy.ru/lib/autonumber/

[mazzy]

Цитата:

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

Еще вот такой минус в сторону Code, если вдруг человек поймет что код он придумал неправильно то исправить его уже будет проблематично

В Аксапте есть renamePrimaryKey
Эта функция доступна и пользователю с соответствующими правами.

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

Бороться с естественными ключами в Аксапте - все равно, что бороться против ветряных мельниц. Можно, но реузльтат сомнительный.

Кстати, поищите на этом форуме про естественные и искусственные ключи. Тема всплывает не в первый и даже не во второй раз.

[sukhanchik]

Если задаться целью ответить на поставленный вопрос - так почему же были выбраны ЕК (без сильного вдавания в подробности что лучше и что хуже) - то (как мне кажется), необходимо учесть, что ЕК хороши для нумерации справочников (CustTable, VendTable, BankGroup и т.д.), а ИК - нумерации документов, проводок (CustTrans, LedgerTrans, InventTrans и т.д.). Безусловно, с точки зрения сложности разработки некоего интерпретатора, коим является ax32.exe - лучше остановить выбор либо на ИК, либо на ЕК, причем обработка ЕК проще, чем ИК. Программно проще (не надо лишний раз заморачиваться на join-ы).
Учитывая некий экономический эффект (все-таки систему надо раскрутить и продать) - возможно и было принято решение в сторону упрощения разработки интерпретатора (еще ж слой sys писать надо) для получения максимально быстрой отдачи. А потом уже наследство легло тяжким бременем

Кстати, внесу еще один аргумент в пользу ЕК, про который в данной дискуссии забыли. В любой БД существует задачка восстановления/исправления данных (когда необходимо обратиться напрямую к СУБД, минуя систему). Уверяю, что восстанавливать данные в системе с ЕК ГОРАЗДО проще, при условии, что не используются средства Аксапты. В 1С например в лоб - вообще не залезть, чего не скажешь про Аксапту. Ну и как следствие - всевозможные экспорты/импорты данных из сторонних программ

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

[macklakov]

Цитата:

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

функция renamePrimaryKey - весьма порочная....

У меня всегда корректно отрабатывала.И проводки хорошо перебивались. Хотя и долго это происходит.

[TasmanianDevil]

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

Диалог в офисе с утра :
-Здраствуйте , 215-ый !
-Доброго утра 145-ый !
- Вы авансовый отчет сдали 755-ой, нашей новой кассирше ?
- Нет, еще, не успел - со вчерашнего утра разбирали пришедший заказ по 10902983823-ой номенклатуре от 12835 поставщика и не могли понять, на какую статью бюдежтирования ее отнести , на I1234 или на M3238.



P.S. Картинка - реальное приложение , рабочая база ...

[mazzy]

Про renamePrimaryKey - нормально работает. Просто вы готовить не умеете.

Цитата:

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

Диалог в офисе с утра :
-Здраствуйте , 215-ый !
-Доброго утра 145-ый !
- Вы авансовый отчет сдали 755-ой, нашей новой кассирше ?
- Нет, еще, не успел - со вчерашнего утра разбирали пришедший заказ по 10902983823-ой номенклатуре от 12835 поставщика и не могли понять, на какую статью бюдежтирования ее отнести , на I1234 или на M3238.

Типичный взгляд приверженцев ИК.
Типичный взгляд 1Сника.

А ведь проблема решается. Ведь обсуждалось тысячу раз... Говорю же - поищите на этом форуме. На форуме у маззи.
http://axapta.mazzy.ru/lib/autonumber/
http://forum.mazzy.ru/index.php?showtopic=82

[TasmanianDevil]

Цитата:

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

Типичный взгляд приверженцев ИК.
Типичный взгляд 1Сника.

1. Не отрицаю, ибо скрытый от пользователя ИК и наименование из справочника променять на код/всплывающий хинт с наименованием , при возможности выбора из этих вариантов, не согласился бы ни за какие коврижки.
2. Поправочка - Галактианца , сидящего на переходе к Аксапте

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

[mazzy]

Цитата:

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

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

Вам не кажется, что вы сами себе противоречите?
Вы сейчас фразу про код сказали?

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

Чем отличается мнемонический код от наименования?
Я знаю ваш первый ответ. Подумайте дальше, пожалуйста.

[twilight]

Цитата:

Изначально опубликовано George Nordic
В Аксе есть места, где есть связка по RecId, многие от этого страдают. Не делайте так.

А можете объяснить на примере, какие проблемы могут возникнуть при использовании для связи RecID?
Я сейчас разрабатываю одну доработку со связью по RecID, хочу узнать, какие проблемы могут при этом возникнуть?
Например, как использование RecID может помешать импорту?