Code&ID

[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

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

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

Цитата:

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

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

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

[AndyD]

Цитата:

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

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

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

[Alex_K]

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

[George Nordic]

Цитата:

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

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

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

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

[Alex_K]

Цитата:

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

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

[vavkin]

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

[mazzy]

Цитата:

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

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

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

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

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

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

[Alex_K]

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

[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. Поправочка - Галактианца , сидящего на переходе к Аксапте

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

[twilight]

Цитата:

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

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

[George Nordic]

Цитата:

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

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

Сделайте импорт в другую базу и поймете. Да что там в другию базу - хотя бы в другую компанию. нумерация по RecId идет в каждой компании независимо, следовательно, если есть завязка по RecId в одной компании, то она будет бессильна в другой... то же самое с добавление таблиц в виртуальные компании... Импорт через cvs, насколько я понял, тереяет ссылки по RefRecId, которые умеет восстанавливать bin импорт... т.е. приходится парами импортировать таблицы. Дефрагментация RecId может убить связи, если они не унаследованы от RefRecId. Если Вы убили-завели заного, допустим, поставщика, то все данные связанные поедут (Альтернативный адрес, например). Да много примеров было - все не упомнить.

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

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

[mazzy]

оп, извини George Nordic