Перечисления vis Справочники
Анализировал типовую конфигурацию УТ 11.4.6.188.
В ней 563 перечисления и 340 справочника.
Подыму тему, которую раньше не обсуждали — зачем в конфигурации нужны перечисления?
Ведь часто списки значений могут быть расширены и перечисление может превратиться в справочник.
Помимо этого, справочник проще параметризировать, т.е. указать для значений справочника опции, признаки.
Единственная причина, на мой взгляд, почему существуют перечисления, это то, что они не хранятся в базе данных.
Конечно, база данных из 340 справочников и 1000 справочников — немного разные базы. Особенно файловая база данных может и «устать» от такого количества справочников. Хотя тоже не факт, потому что места они много не занимают, а код оперирует ссылками.
Единственное место, где возможно замедление — это поиск ссылок на объект. Но там тоже анализируются реквизиты, то есть места, где может быть значение искомого типа.
Поэтому у меня есть большой соблазн в разработке F³ отказаться от перечислений в пользу простоты кода. Ну может быть за редким исключением технических перечислений, не описывающих реальную жизнь, а использующихся сугубо внутри конфигурации, например перечисление Булево. Хотя может и не откажусь, надо подумать.
Ты точно знаешь платформу, на которой решил «убивать» типовые?
Перечисления
Для каждого перечисления создается таблица (_Enum) с полями:
_ID — идентификатор элемента перечисления;
_EnumOrder — числовое значение элемента перечисления.
идентификатор таблицы, но не таблица в базе. открой SQL и проверь.
Я открыл с помощью Tool1CD базу с твоей F3 и вижу три таблицы _Enum: с 2 значениями, с 4-мя и с 7-ю. Это же Булево, тол_ТипыТО и ТипКонтактнойИнформации. Так ведь?
это плохо. хранить перечисления в БД не нужно, это статика, она должна храниться в одном месте метаданных.
А где хорошо хранить определнные пользователем перечисления?
в метаданных
Открыл. Все таблицы _Enum… присутствуют
Плохо. Это лишнее, 1с не смогла в оптимизацию.
Понятно. Платформу ты знаешь плохо
аргументы будут?
А где перечисления могут храниться?
они не хранятся.
Ну тут можно за базу поговорить. У нас есть что-то статическое и динамическое. Статическое — это в коде. Динамическое либо в памяти (и исчезнут, когда процесс закончится), либо на жестком диске (пока живет файл).
Сценарий. Я создаю в конфигураторе 10 перечислений, сохраняю их и перезапускаю конфигуратор. И вижу все мои 10 перечислений. Вопрос — где они хранятся?
Ну, в среднем у перечисления 10-20 значений. Это в БД 5000-10000 записей. Для СУБД типа MS sql или postgre это совсем не очень большой об,ем. По-моему, перечисления- излишняя сущность…
«в метаданных»
А они где хранятся? В другой БД? В XML или каком-то другом файле?
в памяти сервера, там же, где загружается весь код.
туда он попадает из конфигурации базы данных.
Ну в БД получается. Получается и перечисления, и справочники хранятся в БД. Потом когда запускается программа, то что-то загружается сразу в память (все перечисления), что-то только при необходимости (нужный для select или join справочник).
Тогда что плохого в хранении перечислений в БД? Они простые, изменить их может только программист, соотв-но заморочек на частое перестроение индексов нет. Да даже с lazy загрузкой так делают и не просто БД, а через отдельный serverless сервис.
в УТ это 500 лишних таблиц для базы данных. Просто потому, что программистам 1С было лень нормально сделать перечисления.
сделали бы хотя бы одну таблицу тогда уже.
«аргументы будут» — аргументы были. Ты все пропустил. Конкретно ты не знаешь что под перечисления выделяются таблицы.
это лишнее, таблицы для перечислений ненужны. это ненужная нагрузка на базу.
Тем не менее факт, что ее знаешь остается. По таблице перечисления кстати можно делать запрос
какой вопрос? Для 1сника гланое не знать, а знать где узнать, если что.
А не было вопроса. Была констатация факта. Ты утверждал заведомо ложные данные. Если не знал, то зачем пишешь о том, что даже проверить или прочитать не смог?
ого. вы не юрист ли случаем?