Существует ли уникальный номер записи в таблице? - NAV: Программирование

Hub · 22.08.2007, 16:32

Существует ли уникальный номер записи в таблице? т.е. своеобразный внутренний счетчик записей, недоступный пользователю, разве только как read only mode. а вообще, необходимо во временную таблицу запихивать уникальные номера записей. если бы все key были integer и не составными, то проблем не было б.

Eugeny_F · 22.08.2007, 17:18

Вообще какого-то единого механизма с нумерацией записей в таблицах (типа как RecId в Axapta) в Navision не существует. Однако во многих таблицах есть такие уникальные поля-счетчики.
Пример поле Entry No. в таблицах G/L Entry, Cust. Ledger Entry, Vendor Ledger Entry и т.д.

NeNavision_imported · 22.08.2007, 17:37

А чем первичный ключ плох? зачем нужен "своеобразный внутренний счетчик записей"?

**Yoil** · 22.08.2007, 20:30

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

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

smoyk · 23.08.2007, 05:30

To salminenp
Сам навик его не делает, но его можете сделать вы, благо навик предостовляет возможности создания автоинкрементных полей. При необхонимости это поле можно сделать и ключевым.

To Дуд
Во-первых, значение автоинкриментного числового первичного ключа присваивается СУБД автоматически, что гарантирует уникальность каждой записи и отсутствие ошибки при добавлении записи типа "Запись уже существует".
Во-вторых, автоинкрементный первичный ключ занимает меньше места в БД, по сравнению с естественным.
В-третьих и главных, проблема связи таблиц при использовании естественных ключей. Т.к. в его состав входят поля, являющиеся реальными характеристиками обьектов, вполне реальна ситуация изменения значений таких полей. В худшем случае, это ведет к нарушению целостности БД т.к. нарушаются зависимости master-detail таблиц. Этого можно избежать, задав каскадное изменение значений (как и сделано в навижине), но при этом идет полная переиндексация всех связанных записей во всех связанных таблицах. Представляете временные и ресурсные затраты в БД размером, скажем, 100 ГБ (как у нас на фирме)? Для примера: справочник ОКСМ, первичное поле - код страны, у страны "Россия" вбили "RU", примерно через годик код "России" изменился на "RUS" и у вас появились проблемы. Или "RU" вбили по ошибке. Не важно. Этот пример просто для примера.

p.s. Сам я на естественные ключи не наезжаю, иногда можно (серия+ № паспорта к примеру), но у себя в таблицах всетаки предпочитаю и использую автоинкримент.

artkashin · 23.08.2007, 12:12

Естественный или суррогатный ключ Holy war... Smoyk. Можно долго по-этому поводу воевать, но факт в другом, НАВ использует Естественные ключи, и Entry No. для таблиц Ledger Entry - также естественный ключ :-))

smoyk · 23.08.2007, 13:05

Сам по себе нав ничо использовать не может. Это программа и не более того в конце концов. Естественные ключи использовали те ребята, что ваяли стандартную конфигурацию, вот с этим я согласен. Но это не озночает, что их обязан использовать и я. Собсно, как я уже говорил, я в своих таблицах использую автоинкримент.
Воевать... да. Воевать не буим, Дуд просто аргументов просил использования автоинкриментных ключей я их и привел почему я сам их использую. А так личное дело каждого...

**Yoil** · 23.08.2007, 16:10

Цитата:

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

To Дуд
Во-первых, значение автоинкриментного числового первичного ключа присваивается СУБД автоматически, что гарантирует уникальность каждой записи и отсутствие ошибки при добавлении записи типа "Запись уже существует".
Во-вторых, автоинкрементный первичный ключ занимает меньше места в БД, по сравнению с естественным.
В-третьих и главных, проблема связи таблиц при использовании естественных ключей. Т.к. в его состав входят поля, являющиеся реальными характеристиками обьектов, вполне реальна ситуация изменения значений таких полей. В худшем случае, это ведет к нарушению целостности БД т.к. нарушаются зависимости master-detail таблиц. Этого можно избежать, задав каскадное изменение значений (как и сделано в навижине), но при этом идет полная переиндексация всех связанных записей во всех связанных таблицах. Представляете временные и ресурсные затраты в БД размером, скажем, 100 ГБ (как у нас на фирме)? Для примера: справочник ОКСМ, первичное поле - код страны, у страны "Россия" вбили "RU", примерно через годик код "России" изменился на "RUS" и у вас появились проблемы. Или "RU" вбили по ошибке. Не важно. Этот пример просто для примера.

Насчет во-первых, не согласен. Вот как раз и получится в итоге, что вставили в документ две строки с одним номером, а автоинкремент увеличился, все в поряде, система не ругнулась.
Насчет во-вторых... Ну да, меньше занимает. Но это, имхо, мелочь.
Насчет в-третьих - согласен, тяжелая штука. С другой стороны, если бы это самое RU-RUS не являлось первичным ключом, руками бы писали изменение этого значения во всех связанныз таблицах? Ну тогда и вместо ренейма можно запись удалить, вставить новую и аналогично неким скриптом пробежаться по всем связанным табличкам.

SVG · 24.08.2007, 15:55

Всем здравствуйте

2smoyk - есть допустим необходимость сделать справочник автомобилей.
Там есть отличный естественный ключ - VIN
Объясните плиз, в чем будут преимущества автоинкремента перед естественным ключом?
Я их не вижу ни одного

Автомобиль
Ключ VIN Марка Дрыгатель ........
1829 AF019.. OPEL 1.8XER

Заказ
Номер Дата Автомобиль
ЗН0015 24.08.07 1829

Мало того, что надо каким-то доп.образом обеспечивать уникальность,
так еще и чтоб показать юзеру в формочке заказа выбранный VIN
надо лазить в таблицу Автомобиль и там по ключу 1829 искать запись и выводить
пользователю поле VIN из этой записи, так?

Зачем это все?

Иногда удобнее использовать автоинкремент, иногда - естественные ключи, иногда суррогатные.
Нельзя всегда использовать ключи только одного вида, мне кажется это как минимум неразумно

Подумал тут - преимущества искусственного ключа - легкое "переименование"
Ну и все в общем-то.
В приведенном примере с ВИН - если девочка вводящая ошибается постоянно - можно

А использовать его например в документах, где нумерация по сериям - вообще смысла нет.

ado · 24.08.2007, 16:30

ИМХО, использование везде искуственного автоинкрементного первичного ключа снижает зависимость информационной системы от изменчивости внешнего мира. А что до контроля уникальности, так она не только на уровне первичного ключа возможна, даже и на уровне СУБД.

SVG · 24.08.2007, 16:42

Категорически согласен

Но есть ли такие изменения в СУБД типа навижна (который внедряют разные торгаши и производственники) ?
Т.е. конкретно это - нумерация документов и коды справочников.

Другими словами - оправдано ли использование автоинка ВЕЗДЕ ?

ado · 24.08.2007, 17:01

Цитата:

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

Другими словами - оправдано ли использование автоинка ВЕЗДЕ ?

Думаю, да. Вот из каких соображений. При построении ИС это не потребует много лишних телодвижений, при этом может сильно сэкономить телодвижения при каких то резких изменениях в предметной области. И еще это принесет унификацию использования объектов ИС, что есть гуд. Пусть даже и ценой некоторого усложнения использования ОТДЕЛЬНЫХ объектов.

ado · 24.08.2007, 17:05

+ Но это, конечно, касается прежде всего систем, проектируемых с нуля. При доработке существуемых систем, если там автоинкремент везде не применялся, вышеприведенные аргументы не актуальны.

artkashin · 24.08.2007, 18:10

Цитата:

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

Сам по себе нав ничо использовать не может. Это программа и не более того в конце концов. Естественные ключи использовали те ребята, что ваяли стандартную конфигурацию, вот с этим я согласен. Но это не озночает, что их обязан использовать и я. Собсно, как я уже говорил, я в своих таблицах использую автоинкримент.
Воевать... да. Воевать не буим, Дуд просто аргументов просил использования автоинкриментных ключей я их и привел почему я сам их использую. А так личное дело каждого...

Ну если придираться к словам то можно сказать что сам винчестер ничего удалить не может, это просто ему комманда такую подали... и т.д. и т.п, ибо все есть инструмент. Просто существуют регламенты работы с инструментами, которые создали те самые ребята, что ваяли стандартную конфигурацию. Это относится к наименованиям ("No." но никак не "Номер", *Ledger Entry, но никак не Таблица Вхождений", это относится и к ключам). Личное дело каждого писать так как он хочет, только в системах, которые он сам и написал! В системах, где код написан множеством программистов такое свободомыслие приводит к большим неприятностям (собственный опыт).

rov_imported · 27.08.2007, 15:32

Внесу и я свои 5 копеек к рублю Дуда!

Цитата:

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

гарантирует уникальность каждой записи и отсутствие ошибки при добавлении записи типа "Запись уже существует".

А кто вам сказал, что такая ошибка должна отсутствовать? Простейший тупой пример из Навижн: есть табличка Общая настройка Учета - ее первичный ключ пересечение значений Общая бизнес группа и Общая товарная группа. Если пользователь создает запись, ошибочно указав уже имеющиеся значения бизнес и товарной группы - что будет при инкременте? Запись создастся, правда? А ничего, что система ЗАТОЧЕНА на отсутствие подобных повторений? Это - ее бизнес-логика.

Цитата:

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

Во-вторых, автоинкрементный первичный ключ занимает меньше места в БД, по сравнению с естественным.

Как вы думаете естественный ключ просто так создается их определенных полей? Наверное ведь нет? Наверное
эти поля потом буду использоваться: при фильтровке, сортировке и пр. Значит и при инкрементном ключе вам понадобится по-любому создать дополнительные ключи из "естественных" полей. То есть был один ключ(естественный)-а стало 2: автоинкрементный и естественный. Что то я не уловил - и в каком случае будет меньше места,а?

Цитата:

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

Для примера: справочник ОКСМ, первичное поле - код страны, у страны "Россия" вбили "RU", примерно через годик код "России" изменился на "RUS" и у вас появились проблемы. Или "RU" вбили по ошибке. Не важно. Этот пример просто для примера.

А вот здесь пожалуй да, соглашусь - случай тяжелый. Если бы вместо естественных полей везде стояли ссылки на инт-вые ключи - то не надо все везде переименовывать. Однако тут же в голове возникает образ подчиненной записи - набор инт-вых ссылок на мастер-таблицы. С такой базой будет невозможно работать.
Продали товар 1, клиенту 2, со склада 3, через журнал продаж 4, продал пользователь 5!

Офигенно информативно!