()(30)
Извиняюсь, что медленно отвечаю.
()
В составных полях плохо было не только, что много кривых индексов создавалось, но и то, что при потенциальном размере индекса больше 16 полей он
не будет уникальным. Он будет создан, но неуникальным. Как при этом будет работать "ОбменДанными.Загрузка = Истина" я не знаю (подозреваю, что будет грузить всё, что подсунут).
В архитектуре есть проблемы. Во-первых слишком много разных (принципиально разных) назначений у этого вида метаданных. Эти назначения конфликтуют в том смысле, что требуют разной реализации на нижнем уровне. Во-вторых, если говорить только о периодических РС, то главная беда - нельзя эффективно с точки зрения СУБД и при этом правильно с точки зрения платформы "прекратить" вхождение в срез. Третья проблема в том, что сам "срез" - это костыль (ниже чуть подробнее).
И, да, несмотря на это я считаю, что именно РС были самым большим прорывом 1С8.
Смотрите, наши РС, кроме "специальных" использований (типа адресации БП и подобных) нужны для примерно следующих задач:
- "Замена" периодических реквизитов.
- Цены номенклатуры и подобные структуры (котировки, ставки налогов, тарифы и т.п.)
- История статусов чего-бы то ни было (сотрудников, заявок)
- Связь многие ко многим (непериодические)
- Тупотаблица (логи, загруженные внешние данные, разные структуры для оптимизации)
- "Вынесенные" реквизиты объектов (например, непериодический регистр с большим набором ресурсов) - это может понадобиться для деления по блокам или правам или что-то подобное. Сюда же при всех отлиичиях в структуре можно отнести хранилища файлов и картинок.
- EAV или подобные "универсальные" фиговины. Я их не люблю, но это не значит, что их нет.
Есть и другие, но, пожалуй, что 90-99% описываются именно этим.
С непериодическими регистрами всё просто и почти понятно. Непонятно только зачем их смешали с периодическими, ну да ладно. Про периодические, что с ними не так?
1. Сам срез. У нас уже все СУБД в свежих версиях: SQL Server, Oracle, Postgres, и, кажется, даже DB2 - бодро освоили LAST_VALUE() из SQL2003, как впрочем, и другие оконные функции. 1С не использует LAST_VALUE(), хотя на больших запросах это могло бы дать прирост. Это, скорее всего без существенной доработки SDBL не реализовать. С другой стороны, если оконные функции запихнуть в SDBL и отдать в язык запросов, то на кой леший нам вообще срезы, если они без предрасчитанных итогов?
2. В кейсе "история цен" почти всегда возникает проблема, когда старые разрезы накапливаются. У одежды и обуви - каждый год новая коллекция. В котировках каждые три месяца новые фьючерсы и опционы. В электронике торговать ерундой двухлетней давности - тоже скорее исключение. Как "красиво" их исключить? Завести логический ресурс "я кончился"? По нему будет не очень эффективный отбор в срезе. Завести отдельный непериодический РС? Запаришься целостность обеспечивать. Сделать синтетический РН (сбрасывать остаток в 0)? Геморрно, хотя и работает, если пересчитывать, но ведь это явный костыль.
3. Еще хуже ситуация в задаче "статусы". Предположим У нас у заявки есть 3-5 статусов. 1С-ник не задумываясь создаёт РС "СтатусыЗаявок", измерение Заявка, ресурс Статус (даже в общем-то всё равно что за ссылки в заявках и статусах). Заявки обрабатываются за 1-2 дня. Мы хотим получать ответ на вопросы: а) "какие заявки были не в конечном статусе на дату ДД.ММ.ГГГГ" (
Всё просто подумал программист и написал СрезПоследних) и "Сколько заняла обработка заявок из статуса ЧешемЖёлуди до статуса ВаляемКоня" (
Тут программиист задумался и начал строчить нечитаемые запросы с джойном нескольких срезов. Ну по крайней мере так делает большинство 1Сников на этой задаче, хотя это и неправильно). В чем же проблема? А проблема в том, что наши статусы неселективны. Ужасно неселективны. При линейном прохождении их будет по 1/5-1/3 в нашем условии. А фильтр только уже в срезе и не работает (итоги и танцы с бубном чуть-чуть облегчат учесть, но лишь чуть-чуть).А теперь выясняем, что у нас заявок от 100000 в день и есть вероятность, что понадобится еще пара статусов. И эти два вопроса из ТЗ тоже задаются часто. Да, есть тот же трюк с РН и итогами, но это и в этом случае странный костыль (и последовательности документов).
Как эти задачи решить в SQL - я могу объяснить. Решения достаточно шаблонные, но впрямую их транслировать в РС 1С не получится (получится, но они будут сильно усложненные и шаблон "замылится"). На уровне платформы эта задача сейчас не решена.
