Узнал с удивлением, что перечисления хранятся в отдельных таблицах. Вопрос знатокам: нафига?

Допустим, чтобы можно было их джойнить. Тогда следующий вопрос: нафига джойнить?

Допустим, чтобы сортировать. Но для этого можно обойтись и одной таблицей на всех.

Какие версии?

(0) Предложи свою реализацию и давай сравним!

(0) Ладно. Что на счёт "ССЫЛКА" в запросе?

я слышал, что в реляционных БД чего только в таблицах не хранят

(2) Тоже можно обойтись одной таблицей.

См особенности блокировок в файловой версии. Имхо.

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

(5) А подробнее? Перечисления read-only, их не нужно блокировать.

(6) Тут надо взвешивать за и против. Мне кажется, что "против" у многих таблиц больше. Но возможно я чего-то не вижу. Представления их берутся из конфигурации. Если бы не сортировка по Порядку, их вообще незачем хранить IMHO. Где нибудь реально используется этот порядок?

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

(8)
Тебе никто не мешает создать справочник с названием "Перечисления" и пихать туда все, будет тебе одна таблица, в чем проблема то?

(8) Так то по сути и до чего угодно можно докапаться.
Зачем в Windows сделали 100500 файлов, надо было сделать один!

(7) Ты при проведении документа, чтобы не получилось грязного чтения накладываешь блокировку. И опаньки.
Например, запрос с Для изменения.

Пятнично... А ведь только среда.

(0) А зачем их хранить где-то еще? Чтобы в запросах нельзя было их задействовать никаким боком?

+(13) Имхо, если хранить их где-то еще, то работать с ними будет гораздо менее удобно.

(0) Ой. Не понял вопрос с ходу, пардон.

Еще вопрос: а почему-же платформа 1С не использует хранимые процедуры в MS SQL-версии (storage procedure)?

(16) ну это то просто: все, что можно, реализуется средствами программы, а не средствами БД, потому что 1С работает с разными БД, да.

(0) воу воу палехче ща на оптимизируешь

(17) А мне кажется, что просто до версии 8.2 еще не успели от логики 7.7 отойти.

(19) в 7.7 то как раз хранимки и использовались

(20) Прямо обработки проведения документов в ХП транслировались?

(21) нет, только всякие служебные действия, вроде получения итогов по регистрам, в которые ты не полезешь. а в 8-ке и от этого отказались.

(20) http://sysadmins.ru/topic88318.html

(0)
>>. Тогда следующий вопрос: нафига джойнить

Когда ты в запросе пишешь
Выбрать
СпрНоменклатура.СтавкаНДС
ИЗ
....

Как раз и происходит Join
Альтернативно - хранимая процедура - очень долго
Альтернативно - поместить во временную - нафига каждый раз помещать

Твоя реализация ?

(22) Вообще ХП должны дать хороший выигрыш по быстродействию. Даже в ВУЗе в рамках курсового проекта по МС СКЛ преподаватель заставлял писать запросы в виде ХП.

(8)
>> Представления их берутся из конфигурации

За такое направляют на курсы переобучения

(25) зато разработка дольше, сложнее и, как следствие, дороже. но тебе то лично ничего не мешает переписать все на прямые запросы, в 7-ке раньше некоторые так и делали.

(25) Как оно должно работать в файловой версии?

(25)
Это неправда. Хранимые процедуры в целом на порядки медленнее "групповых" операций

(29) что у нас есть "групповые операции"?

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

(27) >но тебе то лично ничего не мешает переписать все на прямые запросы
Не по фэншую это как-то :-)
(28) В файловой - по-старому. Там и блокировок-то нормальных нету.
(29) Что-то не пойму - за счет чего же тут может быть замедление?

(32)
За счет перебора элементов таблицы. Операции выборки/обновления/вставки  сильно оптимизированы

Конечно если в хранимой нет перебора, то и выполняться будет быстро

(19) В принципе, с появлением в восьмерке предопределенных данных в справочниках, необходимость в понятии "Перечисление" по сути отпала, можно было просто в справочнике сделать флажок "Неизменяемый в режиме Предприятия" и всё..

(22) Отказались и правильно сделали - это было необходимым шагом по пути к многоплатформенности. Использование хранимых процедур привязывает к конкретной СУБД, поскольку стандарта на них нет, в отличие от собственно SQL-запросов.

(33) ты наверное про курсоры говоришь, да? ну так да, наличие курсоров в хранимках - это отнюдь необязательно. но иногда без них не обойтись.

(8) А можно по первому пункту подробнее. Где их хранить, чтобы избежать лишнего соединения?

(33) Вот-вот - я и считаю нужным без перебора + в ХП все делать. А курсоры и прочее - конечно медленнее.

(36) Дык в метаданных, как в семерке.

(0) Не поверишь... Джойнил.. Действительно было нужно...

(34) > необходимым шагом по пути к многоплатформенности
Да уж... Тут в логике компиляторов прибавилось бы веток в зависимости от типа СУБД.

(38) Т.е. физически получается таже таблица вид сбоку?

(38) А где хранить метаданные?

Может потому и убрали что меаданные на 2-3 порядка больше стали и тормозять когда по метаданным лазишь

(43) метаданные то в памяти висят, что там может тормозить?

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

(0) А почему вопрос касается исключительно перечислений?

А константы Вас не беспокоят? Если мне не изменяет память, их значения тоже разложены по разным таблицам.

(46) че правда?

(47) Клиент-серверной базы под рукой нет, но, насколько помню, это так с какого-то из релизов 8.2. В 8.0 и 8.1 (как и в 7.7) константы лежали в одной таблице.

(47) Насколько я помню - в режиме совместимости с 8.1 - одна таблица.
После снятия - раскидывает по таблицам.

Было
>>Константы

Если в конфигурации определена хотя бы одна константа, то создается таблица констант (_Consts), содержащая поля:
_RecordKey - ключ записи, необходимый для правильной установки транзакционных блокировок;
_Fld<n> - поле, хранящее значение одной константы. Для константы составного типа создается несколько полей с одинаковыми префиксом и номером и различными суффиксами.
http://main.1c-ei.ru/Home/help/objectdb/dbschema#TOC--4

Сейчас разные ?

(11) >при проведении документа, чтобы не получилось грязного чтения
>Например, запрос с Для изменения.
Какое грязное чтение, какие изменения? :) R-e-a-d o-n-l-y. (24) >Когда ты в запросе пишешь
>Выбрать
> СпрНоменклатура.СтавкаНДС
>ИЗ
>....
>Как раз и происходит Join

Не-а, не происходит.

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

(26) А откуда же берутся представления, просвети?

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

Точно!

(39) Не поверишь... Джойнил.. Действительно было нужно...

Верю, но хочу конкретики. И джойнил именно сперечислением, или другие таблицы джойил по ссылке?

(51)
Тебе же написали при получении представления перечисления происходит джойн
Например если у справоника Номенклатура есть реквиз типа ПеречислениеСсылка например СтавкаНДС или ВидНоменклатуры

(47) Начиная с 8.2.14 - это было сделано потому, что при запросе значения конкретной константы блокировалась вся таблица констант, состоящая из единственной строки и количество колонок по количеству констант.
(48) Ага... А потом их решили разнести просто по разным таблицам.
Почему так было сделано?
1. Если сделать таблицу с 2-мя колонками (ИмяКонстанты, Значение), то 2-я колонка будет иметь составной тип данных - получаем соединение со всеми возможными типами константы, если что - не катит.
2. Если оставить так, как было до 8.2.14 - см. выше это же сообщение.
3. А вот если разнести константы по разным таблицам - тут убиваются одним выстрелом 2 зайца - нет составного типа данных и нет блокирования всей таблицы.

Мне кажется, что так

таблицы перечислений существуют для поля "Порядок", то есть сортировки. И не надо бояться кучи таблиц - это нормально, ничего тут страшного то нет.

(53) просто еще перед выходом 8.0 насколько я знаю собирались сделать именно так (разнести константы по разным таблицам, в которых 1 колонка и 1 строка), но потом отказались, как мы знаем. и вот снова чтоль вернулись к этой мысли.

(54) Как бы теория нормализации БД и подразумевает разнесение данных на максимум таблиц.

Т.е. для приведения БД к 3 НФ как раз константы и должны быть в отдельной таблице

(56) Нормализация тоже может быть избыточной)

(52) OK допустим происходит. Зачем?

(45) На всю конфигурацию одна таблица?
Как ты представляешь себе структуру этой таблицы?

(60) Как некий блоб, который парсится платформой)

Появилась мысль. Соединение с таблицей нужно для проверки, что ссылка не битая (значение не удалили из конфигуратора). Резон есть. НО. За представлением все равно лезем в кэш метаданных, можно тут и проверять.

Ну и (2) - ССЫЛКА(), тут уж без джойна никак. Но можно в одну таблицу все загнать.

(61) (45) А сейчас не так?

(63) Частично так, к сожалению.. но вот перечисления хранятся всё-таки в базе, а не в конфигурации)
Как я уже писал, было бы разумнее отказаться от хранения конфигурации в одной таблице, и хранить метаданные по частям, ассоциированно с данными. Скажем, есть справочник Сотрудники - есть для него основная таблица на sql-сервер, есть таблицы с табличными частями, и пусть будет еще одна с метаданными - описания реквизитов (синонимы, комментарии и т.п.), макеты, формы и тому подобное.

(64) > перечисления хранятся всё-таки в базе, а не в конфигурации
Я бы сказал, в конфигурации и частично в базе.

>было бы разумнее отказаться от хранения конфигурации в одной таблице, и хранить метаданные по частям
Почему? Целостность нужно как-то поддерживать.

(65) Для контроля целостности и простоты выборки метаданных ввести дополнительную служебную таблицу, где будут перечислены ссылки на все объекты метаданных с контрольными суммами.. ничего сложного. Эта служебная таблица места практически не будет занимать.

(66) И все же не понятно, зачем по частям.

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

(68) IMHO надумано.

(69) Неа. При такой схеме программа грузилась бы за секунды.

(59)
>> OK допустим происходит. Зачем?

Ндя.... (

Делаешь выборку по справочнику номенклатура
В поле СтавкаНДС у справочника Id перечисления
А пользователь видит "18%"

Вероятно можно обойти программно выборку из 20 000 элементов и подставить вместо Id 18% но разумные люди так не делают

(71) Ты бы в табличку заглянул, что ли... Нет там "18%", из метаданных берется.

declare @ПеречислениеВес as binary(16) =(Select _IDRREF From "+СтрПереч.ИмяТаблицыХранения+" Where _ENUMORDER="+Перечисления.акТипыЗначенийГруппНоменклатуры.Индекс(Перечисления.акТипыЗначенийГруппНоменклатуры.Вес)+");

(72) Берутся по индексу