Правильные справочники

[mazzy]

Цитата:

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

Есть устойчивая концептуальная проблема со справочниками.

Почему проблема?

Цитата:

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

Она исходит из двух посылок:
1. Аксапта практически не использует суррогатных ключей.

Да, и слава богу.

Цитата:

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

2. Аксапта не поддерживает вывод наименования рядом с кодом в ссылке на справоч8ник

Тогда уж дописывай: не занимается выводом наименования автоматически.
И слава богу, что не занимается.
Потому что простой select по одной таблице автоматически превратился в грандиозный запрос с кучей join'ов.
Кроме того, в Аксапте есть наименования на разных языках...

Ты видимо с 1Сv8 не работал и не видел ошибку "в запросе не может быть более 256 таблиц...". В последних релизах патч сделали - собирают несколько разных запросов.

И добавлю еще: там где это действительно нужно, Аксапта нисколько не мешает программисту добавить свои join'ы, чтобы показать наименование.

Цитата:

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

Во-вторых, для вывода описаний значений справочника надо делать дополнительный код (обычно, дисплей-методы)

Ай-ай-ай... Ну, не создает эта собака дополнительные запросы.
Оставляет на откуп программисту. Вот ведь сволочь то какая...

А ты считал сколько наименований надо приджойнить для того, чтобы показать например номенклатуру?
Нет? Посчитай.

Цитата:

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

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

Ай-ай-ай... А в запросе CTRL+F3 добавить таблицу руками и записать запрос никак?
Блин, ей богу не ожидал.

Ну, не делает она сама запросы. Не нагружает она сервер.
И слава богу.

Цитата:

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

Кто как решает эту проблему?

Ни в коем случае не программировать как говорят некоторые.
Или программировать в крайнем случае, когда клиент уж совсем уперся. Но четко осозновая, что для каждого наименования получится дополнительный join. Со всеми вытекающими последствиями для производительности.

Цитата:

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

Я встречал два противоположных способа и их горячих сторонников.

1. Идентификаторы делают длинными и осмысленными -- соотвественно они требуют переименования при изменении названия значения

2. Идентификаторы делают неосмысленными или они содержат небольшой условный префикс и номер типа спирт001.

см. http://axapta.mazzy.ru/lib/autonumber/
а также http://forum.mazzy.ru/index.php?showtopic=82

Цитата:

Какой по вашему должны быть структура справочника?

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

ты наверное спрашивал про структуру кода.

Цитата:

Есть ли у вас проблема того,что пользователи требуют фильтрацию по наименованию прямо в гриде?

Почему ты считаешь это проблемой?

Цитата:

Сообщение от Владимир Максимов

С чисто формальной стороны, то, что используется в AXAPTA и есть суррогатный ключ, поскольку это не есть информационное поле.

Почему это "суррогатный" и почему не информационное?

Цитата:

Сообщение от Владимир Максимов

А в AXAPTA пошли более простым путем - дали пользователю возможность напрямую как просматривать, так и вводить коды записей.

А также дали возможность и не вводить, если вы укажете нумератор.

Цитата:

Сообщение от Владимир Максимов

Поэтому возникла иллюзия того, что это "естесственные ключи". На самом деле это не так.

Почему?

Цитата:

Сообщение от Владимир Максимов

Где-то здесь была ссылка на статью Mazzy по поводу поиска по внешнему ключу в связанном справочнике. Не могу найти.

Привел чут выше.
Также сделайте поиск по слову суррогатный и естественный.

Цитата:

Сообщение от Владимир Максимов

Суть в том, что таблица-справочник цепляется по JOIN к основной таблице и в Grid отображаются напрямую поля из таблицы-справочника. Никаких дисплейных методов и дополнительных полей.

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

Да, но только вместо простого запроса получаем сложный.
Да, но вместо одной таблицы получаем кучу связанных таблиц.
Да, но никакого delayed join, только inner. Со всеми вытекающими проблемами произодительности при навигации стрелками.

Цитата:

Сообщение от Владимир Максимов

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

И это тоже

Цитата:

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

Мне нравится понятие искусственный ключ.

Почему?

См. также: http://sql.ru/forum/actualthread.aspx?tid=104535

И еще:
Нумератор строковый, а не числовой, чтобы можно было делать суффиксы-префиксы.
Числовой был раньше. Еще в конкорде.
Там приходилось выделять диапазоны чисел. Например, с 1000 по 3999 идут клиенты, а с 4000 по 6999 - поставщики.
В Аксапте 2.1 пошли на компромисс и снижение производительности ради наглядности кода. (но ради совместимости с Конкордом сохранили выравнивание вправо)
В Аксапте 4.0 наконец-то отказались от выравнивания вправо (по умолчани все коды выравняны влево)

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

Цитата:

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

Цитата:

Сообщение от Владимир Максимов

С чисто формальной стороны, то, что используется в AXAPTA и есть суррогатный ключ, поскольку это не есть информационное поле.

Почему это "суррогатный" и почему не информационное?

Когда начинается спор СК vs ЕК у меня возникает вопрос, а о чем собственно спорим? Т.е. где определения того, что понимать под термином "естесственный ключ", а что под термином "суррогатный ключ". Это понятия, которые все "интуитивно" понимают, но как только дело доходит до определений, все смешивается в жуткую кашу.

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

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

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

Меня не интересует ни способ формирования СК или ЕК, ни то, вкладывает ли в них пользователь какой-либо физический смысл или нет. Все это "вторично".

Собственно, в моем понимании СК и первичный ключ практически синонимы. Как именно они формируются: автоинкремент, GUID, номерная серия, ручной ввод - не имеет никакого значения. Если он предназначается и обеспечивает однозначную идентификацию записи всегда и при любых условиях, то для меня это "суррогатный ключ".

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

Используемые в AXAPTA ключи, с моей точки зрения, полностью соответсвуют моему пониманию того, что есть "суррогатные ключи". Служат только и исключительно для целей однозначной идентификации записи и не могут меняться на протяжении всего времени существования записи.

Теперь, почему "не информационные"?

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

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

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

Помнится, было бурное обсуждение по поводу древовидных справочников. Так вот, идентификатор записи - это то же самое. Удобно, но только для того человека, который точно знает, что "скрывается" за той или иной веткой или кодом записи.

Именно поэтому я и называю такие поля "не информационные". Они требуют "расшифровки". Сами по себе никакой информации, кроме однозначной идентификации записи не несут.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Именно поэтому я и называю такие поля "не информационные". Они требуют "расшифровки". Сами по себе никакой информации, кроме однозначной идентификации записи не несут.

"Светик" не несет никакой информации?
Склады с кодом Основной, Южный, Порт?
Город с кодом Мск, Спб и т.п.?
Группы VIP, Розн, Рынки, Школы, Прочие, Наши, Левые?

Не несет, значит никакой информации.
Как скажете...

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

Цитата:

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

"Светик" не несет никакой информации?
Склады с кодом Основной, Южный, Порт?
Город с кодом Мск, Спб и т.п.?
Группы VIP, Розн, Рынки, Школы, Прочие, Наши, Левые?

Не несет, значит никакой информации.
Как скажете...

Если на юге построили еще один склад, то Южный - это какой из них?

Красн - это Краснодар или Красноярск? АБВГ - это какой город?

Если после VIP появились VIP1 и VIP2?

Вы помните свою аргументацию, по поводу использования древовидных справочников? Ведь все понятно же! Кому понятно? Тому, кто сам эти обозначения и придумал! Сам их отслеживает.

Да, есть несколько "широко известных" (в узких кругах ) сокращений. Ну и что? Это все работает до тех пор, пока справочник именно в этих пределах и ведется. Т.е. небольшой справочник. Как только размер справочника превышает некоторый предел, использование таких сокращений теряет смысл. Просто все их не упомнишь!

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

Как скажете...

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Если на юге построили еще один склад, то Южный - это какой из них?

А что говорят пользователи?
Они как называют новый Южный склад?
То и будет в коде.

Цитата:

Сообщение от Владимир Максимов

Красн - это Краснодар или Красноярск? АБВГ - это какой город?

Если после VIP появились VIP1 и VIP2?

А что говорят пользователи?

Цитата:

Сообщение от Владимир Максимов

Да, есть несколько "широко известных" (в узких кругах ) сокращений. Ну и что? Это все работает до тех пор, пока справочник именно в этих пределах и ведется. Т.е. небольшой справочник. Как только размер справочника превышает некоторый предел, использование таких сокращений теряет смысл. Просто все их не упомнишь!

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

Цитата:

Сообщение от Владимир Максимов

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

Да, там была алтернатива - вытянуть дерево в линейный список и поискать.
Здесь я альтернативы не вижу.

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

В общем, имеющаяся альтернатива - подставлять наименования - не дешевле и не удобнее, нежели информативные коды.