Нет, проблема, что не сможете построить нужное количество индексов, если только это не статические запросы которые никогда не меняются.

Они точно будут изменяться.... Вариантов много. Я понял, в общем только по индексам.

Кажется что "моветон"..  можно использовать более гибкий подходи. Ладно пойду думать, по индексам я на самом деле уже задала наводящий вопрос, ответа пока не было.

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

Всем привет.
Редко вопросы задают, но вот появился. Используется СУБД MS Sql Server 2019 Ent.

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

Суть:

Имеется таблица
В которой содержатся данные о химических элементах по атрибутам, Id статьи, наименование статьи, Id отчёта, 116 атрибутов по содержанию и массе элементов(Decimal(38,18) - проблему расчётов с максимальным decimal удалось донести - должны изменить). Из этой таблицы происходит выборка в отчёт (SSRS), ед. измерения некоторых элементов могут различаться, поэтому для каждого из 116 атрибутов добавят ещё атрибут UOM, так же элементы могут иметь разные правила округления - для каждого из 116 атрибутов будет добавлен столбец roundRule... Так-же присутствуют атрибуты dateCreate, dateDelete, dateUpdate хотя  заявляют использование CDC, поэтому думаю что их уберут. Но на данный момент в одной таблице будет 362 атрибута. Конечно атрибуты будут разряженными.

Было предложено 2 альтернативы:

1. Структура на  базе справочников, сократить объем до 20 атрибутов в основной таблице  и пары справочников (наименованием столбца, наменование ед.изм, правила округления) .  Выбирать данные для отчёта из view и использовать PIVOT. Или выбирать из процедуры используя динам.sql.

2. Хранить все в одной сущности структуры :
"ключ", "наименование атрибута", "тип", "значение"... Т. е перевернутвя структура.

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

Есть мысли как аргументировать почему создание таблицы с таким набором атрибутов не очень хорошая идея ?

2 по моему EAV я б делал так

Всем привет.
Редко вопросы задают, но вот появился. Используется СУБД MS Sql Server 2019 Ent.

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

Суть:

Имеется таблица
В которой содержатся данные о химических элементах по атрибутам, Id статьи, наименование статьи, Id отчёта, 116 атрибутов по содержанию и массе элементов(Decimal(38,18) - проблему расчётов с максимальным decimal удалось донести - должны изменить). Из этой таблицы происходит выборка в отчёт (SSRS), ед. измерения некоторых элементов могут различаться, поэтому для каждого из 116 атрибутов добавят ещё атрибут UOM, так же элементы могут иметь разные правила округления - для каждого из 116 атрибутов будет добавлен столбец roundRule... Так-же присутствуют атрибуты dateCreate, dateDelete, dateUpdate хотя  заявляют использование CDC, поэтому думаю что их уберут. Но на данный момент в одной таблице будет 362 атрибута. Конечно атрибуты будут разряженными.

Было предложено 2 альтернативы:

1. Структура на  базе справочников, сократить объем до 20 атрибутов в основной таблице  и пары справочников (наименованием столбца, наменование ед.изм, правила округления) .  Выбирать данные для отчёта из view и использовать PIVOT. Или выбирать из процедуры используя динам.sql.

2. Хранить все в одной сущности структуры :
"ключ", "наименование атрибута", "тип", "значение"... Т. е перевернутвя структура.

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

Есть мысли как аргументировать почему создание таблицы с таким набором атрибутов не очень хорошая идея ?

не так давно пришлось переделывать БД в которой было несколько  таблиц с большим количеством колонок  с именами attrib_entity1, attrib_entity2, и т.п.
А подключили меня потому, что разработчики запутались в этих именах и завалили все сроки.
На вопрос почему не привели к нормальным формам ответили: "Что это такое?"
Может у вас то же такой же случай.

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

Чё еще вспомнил: https://docs.microsoft.com/ru-ru/sql/relational-databases/tables/use-sparse-columns?view=sql-server-ver15

Здравствуйте подскажите как решить. Есть столбец с 0 и 1, необходимо посчитать  длинну каждой серии из 0 после которой следует 1