ненормализованные таблицы в 1С

В 1с не соблюдаются правила нормализации баз данных как на уровне системных таблиц платформы, так и на уровне таблиц типовых конфигураций. Это может приводить к известным проблемам с быстродействием, масштабируемостью, блокировками и пр.

Требования нормализации не соблюдаются в критически важных таблицах 1с – бухгалтерских итогов, проводок. Бухгалтерские итоги по всем счетам хранятся в одной таблице, без разбиения на разные таблицы в зависимости от типа аналитики счета, а ведь разные счета хранят разные по структуре данные! Например на счетах взаиморасчетов (60, 62, 76 бух. счета) хранится информация по следующим измерениям (субконто): контрагенты, договора, документы. А на счетах учета материалов (10 счет) – по номенклатуре и складам. Как следствие в таблицу итогов кроме полей «субконто», вводятся поля «тип субконто» (??? А может и не вводятся, а если и вводятся только для неопределенных полей. Нужно проверять таблицы в MS SQL, в 8 версии вроде переделали). Соответственно к индексам введенным для субконто, вводятся еще индексы для полей «тип субконто». В случае плана счетов с максимальным количеством субконто к счету равным 3, количество индексов в таблице бух. итогов вместо 4 (3 для трех субконто и 1 для счета) становится 7 (дополнительно еще 3 для типа субконто). Это может существенно влиять на производительность, с учетом того что все документы формирующие бух. проводки будут формировать записи в данной таблице. Также существенным минусом является то, что количество полей-субконто одинаково для всех счетов, ведь как уже было сказано остатки по всем счетам хранятся в одной таблице. Считается нежелательным добавлять больше 3 субконто к счету, а в 7.7 вообще невозможно было больше 5 создать, это было ограничение платформы. Кроме того, по сути невозможно добавить поля в таблицу движений конкретного счета (она ведь одна на все счета). Также невозможно сделать RLS (ограничение доступа к данным на уровне конкретных записей а не всей таблицы) по бухгалтерским остаткам и движениям. Данные ограничения, возможно, привели к созданию множества различных дополнительных регистров другого типа - не бухгалтерских (не использующих корреспонденцию), например, для учета операций по НДС. Эти регистры независимы друг от друга, и в них можно создавать необходимое количество измерений, полей.

- Сомнительно использование механизма характеристик для торговой и прочей деятельности. Смысл характеристики в том, что в поле документа или регистра остатков хранится не ссылка на справочник например размеров одежды или цветов одежды или страны-производителя и пр., а ссылка на запись другой таблицы (назовем ее ТаблицаХарактеристика), к которой подчинены несколько записей другой вспомогательной таблицы, где и хранятся типы и значения разных атрибутов – размеры, цвета, страны-производители, веса, габариты, по сути что угодно. В этой вспомогательной таблице есть поле «Вид свойства» (ссылка на справочник свойств, значения данного справочника – цвет, размер, страна и т.п., их можно сколько угодно создавать) и поле «Значение свойства» (например красный, синий, зеленый для цветов; 40, 41, 42 – для размеров и т.п.). Но для того чтобы хранить данные например о двух цветах и трех размерах нужно завести все возможные комбинации используемых цветов и размеров. Например Белый 42 размер, Белый 43 размер, Белый 44 размер, Синий 42 размер, Синий 43 размер, Синий 44 размер. Т.е. вводится большее количество записей в таблицы, чем есть в реальности – на два цвета и три размера (итого 5 записей) вводится 6 записей! Для трех цветов соотношение будет уже 6 к 9.
По-видимому данный механизм 1С придумала для того, чтобы пользователь при отсутствии программиста мог сам добавлять произвольные характеристики (например товаров) используемые в данной организации или для того чтобы не вносить изменения в конфигурации из-за дополнительных свойств. Но во-первых обычный пользователь вряд ли сможет самостоятельно заполнить характеристики (скорее всего он про них и не знает), а во-вторых если приглашается программист, то ему по сути проще и правильнее добавить несколько колонок (в нашем примере цвет, размер) в несколько таблиц (приход, расход, остатки) и прописать их в движениях, чем использовать характеристики, а потом доделывать отчеты чтобы характеристики показывались в удобной форме и в-третьих программисты 1с уже есть во всех городах страны, возможно уже в деревнях есть, так что нет никакой проблемы вызвать программиста и доработать конфигурацию. И самое главное, очевидно характеристики ведут к проблемам с производительностью, удобством выбора значений (автопоиск значения по первым введенным символам не работает), а также усложнению конфигураций, т.к. приходится дорабатывать отчеты и различные модули под характеристики. Характеристики можно рассматривать как пример антипаттерна из классических трудов по программированию, где рассматривается ошибочное решение и к каким проблемам данное решение приводит. В данном случае возникающие проблемы – существенны, а заявленные плюсы – сомнительны.

- Ошибки есть не только на уровне платформы, множество сомнительных решений допускается при проектировании типовых конфигураций. Например таблица адресов – поля нессылочные, просто записывают текст "г. Москва", вместо ссылки на справочник городов. То же самое с областями, улицами. Очевидно это нарушение принципа реляционности. К тому же нарушаются принципы нормализации, т.к. поле город однозначно идентифицирует регион, следовательно поле регион избыточно в таблице адресов (конечно в случае хранения ссылочного поля «город»). Ссылочный тип дал бы возможность простого анализа продаж по типам регионов, городов и т.д. Но и это еще не все. В таблице адресов хранятся не только адреса, но и телефоны, e-mail, по сути там мешанина данных как и в таблице бухгалтерских остатков. Аналогичные проблемы с адресами физлиц, т.к. они хранятся в той же таблице что и адреса контрагентов. Вся эта мешанина привела к созданию целого модуля для работы с контактной информацией, по сути ненужного. При этом рекомендую всем посмотреть данный модуль для работы с адресами. Сложность его не соответствует решаемой задаче (см. пункт 1). Можно конечно попробовать возразить, что соединения таблиц может быть ресурсоемким в случае больших таблиц и поэтому хранится не ссылка, а текст "г. Москва", но в данном случае скорее всего данные таблицы не настолько велики. Также нужна история адресов, ведь адреса могут меняться. Возможно не нужно поле контрагент в различных таблицах, если есть поле договор в той же таблице, ведь договор однозначно идентифицирует контрагента (это спорное утверждение).
- Во все справочники ТК добавлен автоматически нумеруемый реквизит «Код» (причем не всегда уникальный), при создании нового справочника в конфигураторе также по умолчанию создается данный реквизит. Хотя для большинства справочников он не нужен. Он может понадобиться разве что для справочника Основных средств, Номенклатуры, да и то только под названием «Инвентарный номер», а также справочника «Сотрудники» под названием «Табельный номер». Интересно, какой процент программистов 1с задумывался над данным вопросом? Конечно вряд ли данный реквизит существенно влияет на производительность, но определенные неудобства может создавать когда сбивается нумерация (как правило 1с контролирует уникальность данного реквизита). Непонятно зачем в ТК при нумерации кодов в справочниках и номеров в документах к числу добавляются нули, например 000245. Это приводит к определенным проблемам при штрих-кодировании, когда появляются разные номенклатуры с кодами различающимися только ведущими нулями, ведь при печати штрих-кода нули удаляются, а при сканировании соответственно уже невозможно правильно идентифицировать номенклатуру отличающуюся только количеством ведущих нулей.

- В качестве ключевого поля (уникального идентификатора) для таблиц используется поле типа GUID, хотя в 7.7 версии хватало поля числового типа. Очевидно в большинстве случаев хватит числового идентификатора. Вероятно использование GUID отрицательно влияет на быстродействие соединения таблиц в запросах, на создание, запись и проведение справочников, документов. С данным полем достаточно неудобно работать в 1с. К тому же вряд ли получится использовать GUID-поле для штрих-кодирования например номенклатуры или основных средств. Полагаю это достаточно редкое решение при построении баз данных – использовать GUID-поле в качестве ключевого поля.