Приветствую всех.

Может уже кто сталкивался с похожей проблемой, может кто и реализовал ее.
Но я на сегодняшний день не нашел ни платного ни безплатного решения данной темы.

Задача создать справочник ЭРИ (электрорадиоизделия), который был бы похож именно на справочник, а именно:

1. скорость выполнения любого запроса около 10 сек.

2. отображение всех ЭРИ сразу в одной таблице (во загнул-то, но уже нашел способ как это сделать), т.е.
клиент визуально работает с одной таблицей, но в зависимости от типа ЭРИ в этой таблице есть группы со своими псевдо-названиями столбцов.
в итоге имеем практически мгновенный доступ к поиску по всей базе

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

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

За основу берется "Перечень электронной компонентной базы, разрешенной для применения при разработке, модернизации, производстве и эксплуатации вооружения, военной и специальной техники" - перечень ЭКБ.

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

Жду все ваши комментарии и плохие и хорошие, только без мата....

Dimitry Sibiryakov,

Имея достаточный опыт общения с системами построеными на EAV, то применять эту технологию полностью в моем примере не получиться, иначе построение запросов будет очень дорого стоить по времени.

Я решил что EAV нужен на этапе администрирования и наполнения и редактирования справочника, а вот для клиента...

Иду на прямое нарушение нормализации и дублирую информацию в специальных таблицах в виде удобном для клиента )))

С чем столкнулся, так это с типами данных....

нужно ли использовать sql_variant?
или заложить заранее нужное количество типов?

... думаем...

вот набросал небольшую схему, это обобщенная логика.
см. приложение.

Да согласен, что это увеличит базу в двое как минимум, но ЭТО справочник.

И там объектов максимум до миллиона, а значит база с 2 или даже 5-ю миллионами никого сегодня не удивит.
да и железо все стерпит.

Зато клиент будет прыгать от счастья, что так все быстро.

Дедушка,

))) насмешил "с горящими глазами" ....
потухли глазки-то и уже давно... жизнь суровая штука...

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

а ты "горящие глаза" )))

Спасибо за ответы.

Но в том-то и дело. что я не знаю как хочу ))))).

Пробую и так и сяк.

Кстати с спасибо за напоминание про NoSQL (и что они opnesource)/

Изучаю схему совместного использования SQL и NoSQL ....

DirksDR,

Согласен со всеми вашими замечаниями.

Скорее всего они от того что я многое опустил и только наметил общую суть проблемы.

1. "тип_связи" - что же это за зверь такой?
Скорее всего это задел на будущее и дело в том что справочник это не простой, это больше будет напоминать некое хранилище объектов с возможностью отслеживания жизни этих объектов.
ЭРИ-шки имеют такое неприятное свойство как устаревать или быть "забанены" во времени и т.п. и т.д.
Т.е. анализируя перечень ЭКБ за 3-и года пришел к неприятному выводу: со временем атрибуты меняются.... я был немного удивлен.
Эти изменения скорее связаны с новыми технологиями или еще с чем, но получается так.

Еще планируется что атрибуты будут иметь некие состояния для конкретного типа, например
понятие "обязательности" или еще какое нибудь, но для разных объектов один и тот-же атрибут может быть в разных "состояниях"

2. "объект_полный" - тут все просто, моё видение денормализации, а именно
пользоватль-клиент хочет иметь возможность поиска по всей базе сразу, ну не знает он что ему искать, не может определиться диод-ли это или варикап (это все полупроводники) вот и выдает в одну единственную строку поиска запросец.
Ну а имея 1 монолитную таблицу - искать по ней не составит труда.

3. "parent-child" - тут опять же раскрою "туман войны" ))
У нас уже куплена и за немалые деньги MS SQL Server - что есть, то есть
а значит иерархия будет только в типе hierarchyid. Она будет в виде отдельной таблички связана с с типами объектов

4. насчет "EAV" изучил это механизм - он прекрасен спору нет, НО (учитываем то что атрибутов может быть до 100)

- пользователь у нас привередливый и хочет видеть все и сразу ( а я уже напел оду о всемогущности программирования), так что вот теперь хлебаю ))))
- EAV не даст построить статистику по все объектам, дело в том что ЭРИ имеют в арсенале своих атрибутов такое понятие как интервалы возможных характеристик - ИНТЕРВАЛЫ, т.е. номинал и возможные разбросы. (проблема, которую еще решаю)


Надеюсь немного раскрыл проблематику поставленного вопроса....

Жду камней в свой огород.... желательно драгоценных )))

Всем спасибо за ответы.

Анализирую их.

И вы в общем правы, от меня начальство хочет как я понимаю намного большего чем простой справочник )).

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