Цитата:
Сообщение от
mazzy
угу. а еще есть? а можно всех посмотреть?

Варианты хранения доп.признака в базе данных? Так вроде все перечислил. Ну, если не считать собственно поддержку NULL для поля. Или интересует вариант технической реализации? Так это у кого на что фантазии хватит. Например, для хранения признака создавать не по отдельному полю для каждого поля с возможным NULL, а одно общее поле, где хранить битовую маску...
Ну, и уже упоминались варианты, когда значение, эквивалентное NULL не надо прятать, а наоборот, выставить как одно из возможных значений.
Например, заменить CheckBox на ComboBox с 3 вариантами выбора (All / Yes / No). Для текста (кода справочника) создать специальный элемент справочника с пустым кодом.
Цитата:
Сообщение от
mazzy
Вот!
Для примера возьмем MS SQL и Аксапту 2012, которые умеют отображать null значение, полученное из базы. там в поле отображается специальное значение null, а поле становится недоступным для редактирования.
Как мне кажется, это не правильное решение разработчиков. Ведь получается, что если поле приняло значение null, то пользователь его не может изменить напрямую. Чтобы пользователь смог изменить это поле, его значение должно быть программно установлено в пустое значение. Фактически, создается доп.поле, содержащее признак необходимости изменить основное поле. Что возвращает к реализации с двумя полями.
Цитата:
Сообщение от
mazzy
другие реквизиты могут находится за тысячу километров таблиц от данного места и метода, где пара значений применяется. я уже приводил примеры
"если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит"
Опять я не в курсе "новых веяний" в Ax2012, но в младших версиях Axapta все ключевые реквизиты, необходимые для расчета копировались в подчиненные и связанные таблицы. Т.е. находится за тысячу
километров таблиц он не должен. Это ошибка проектирования (хотя и нарушает принципы нормализации)
В данном примере, где будет хранится сумма кредитного лимита? Ну, предположительно, либо в таблице клиента, либо в таблице договоров. В обоих случаях признак контроля кредитного лимита должен быть в той же таблице.
Цитата:
Сообщение от
mazzy
не совсем.
чтобы срабатывал prmIsDefault в вызывающем классе параметр не должен быть указан.
Угу. Так я так и написал "
очень ограниченно"

Т.е. в очень специфических ситуациях.
------------------
Если просто "перечислять варианты", то вот еще парочка идей
- Объект Map из одного элемента: ключ - признак NULL, значение - значение

- Объект Struct из одной "строки". Одно "поле" - признак NULL, другое - значение. Если добавить 3 поле-идентификатор, то можно в один объект Struct собрать все переменные для обработки, сделав несколько "строк". Аналог временной таблицы
- Объект Set или List из одного элемента. В случае, если значение эквивалентно NULL, то не создавать (или удалять) элемент. Нет элементов - значение NULL
Эти объекты позволяют сделать частичный контроль типов (правда, только на уровне базовых типов), а также имеют встроенные методы pack/create, что упрощает их передачу в pack/unpack