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

[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 наконец-то отказались от выравнивания вправо (по умолчани все коды выравняны влево)