powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / За и против EAV в представленном варианте
1 сообщений из 1, страница 1 из 1
За и против EAV в представленном варианте
    #38952979
Alexander2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Приложение для ведения учета производства неких объектов изначально было сделано по модели EAV.

таблица-справочник объектов
CREATE TABLE [dbo].[Objects](
[RowID] [int] IDENTITY(1,1) NOT NULL,
[ID] [varchar](50) NOT NULL,
[Description] [varchar](50) NULL,
[Object_Series_Id] [int] NULL,
[TestVolume] [float] NULL,
[TestTime] [float] NULL,
[Active] [bit] NULL)

таблица-справочник параметров
CREATE TABLE [dbo].[Object_Parameter](
[Id] [int] IDENTITY(1,1) NOT NULL,
[ParameterName] [nvarchar](100) NULL,
[ParameterName_en] [nvarchar](100) NULL,
[ParameterName_ru] [nvarchar](100) NULL,
[ParameterName_de] [nvarchar](100) NULL,
[ParameterName_fr] [nvarchar](100) NULL,
[ParameterName_es] [nvarchar](100) NULL,
[Description] [varchar](255) NULL,
[Description_Alias] [varchar](50) NULL,
[Id_MetricUnits] [int] NULL,
[Id_ImperialUnits] [int] NULL,
[Report_Group_Id] [int] NULL,
[ParameterOrder] [float] NULL,
[ISO] [bit] NULL)
таблица носитель данных:
CREATE TABLE [dbo].[ObjectParameterValue](
[Object_Model_Id] [int] NULL,
[Object_Type_Id] [int] NULL,
[Object_Parameter_Id] [int] NULL,
[ParamValue] [varchar](100) NULL,
[usystem] [varchar](1) NULL,
[id] [int] IDENTITY(1,1) NOT NULL,
[Ver] [float] NULL,
[Status] [char](1) NULL
) ON [PRIMARY]

В описании параметров просто вбито 5 языков основных(Русский, Английский, Немецкий, Испанский, Французский, чисто и практических соображений что технологии, что промышленность, что интернет развит в странах, говорящих на этих языках, остальные подстраиваются.

На клиента выносил данные из последней таблицы транспонируя одномерную таблицу в классический вариант как в экселе: строки имена объектов, колонки имена параметров. Для этого использовалась хранимая процедура из 160 строк (если красиво отформатировать). В зависимости от выбора языка - перетранспонировал данные и брал название из соответствующей колонки.
Для отчетов-карточек объектов запрос получался еще проще - одномерная таблица со списком значений для соотвествующего объекта.

Почему я выбрал такую EAV модель?
Увидел, что появляются новые описательные параметры, не часто, но появляются.
Группы параметров тоже имеют место размножаться: типа «группа параметров для показа гостям -10 параметров», «группа для внутреннего пользования – 50 параметров» и т.д.
Если потребуется добавить новый язык, я просто добавлял новую колонку в таблицу описания параметров, поскольку в OPV все равно хранился INT указатель на параметр. Хоть на суахили, хоть на папуасском – добавляем новую колонку с 50 переводами.
Для отчетов нужны карточки объектов, которые удобно вытаскивать в одномерном виде, это классическая таблица пропертей как в любом объектно-ориентированном IDE.
Кроме того, мне надо было показывать карточку значений параметров в двух единицах измерения метрических и imperial, с соответствующими переводами этих единиц измерения на разных языках.
-----
Появилось новое требование - хранить таблицу-описание объектов в аналогичном экселу виде, строки - объекты, колонки имена параметров.
Начался тра...дром!
Поскольку имена параметров для простоты надо хранить в латинском спеллинге (можно, конечно, все в скобки обрамлять, но сложные названия, это пепец), то для отчета и показа на клиента требуется ТРАНСЛИРОВАТЬ латинскую аббревиацию имени параметра в название колонки на соответствующем языке, а для этого НАДО иметь эту самую таблицу перевода на разные языки. Пришлось сделать почти точно такую же таблицу как в случае EAV модели, только в этом случае natural key было мое латинское имя параметра. Ну и, соответственно, много-много кода для проверки языка 5 IF-groups по 50 параметров, итого уже 250 строк как минимум при выносе данных на клиента.
Короче, мое долгое повестование имеет целью вопрос - а н а х р е н а козе баян? В варианте EAV я ну запросто крутил данными, и даже если добавляется НОВЫЙ язык (что довольно редкое явление), всего несколько небольших изменений в коде, а в случае НОВОЙ парадигмы сверху - еще 50 проверок-трансляций как минимум и куча других изменений и на клиенте и на сервере.
Короче, я лично предпочитаю EAV первой реализации проекта. Но новое требование привело в совокупности к более чем 1000 строк уже T-SQL кода.
В атаче картинка того, что нужно юзерам. В зависимости от группы - меняется число строк в группах в карточке.
...
Рейтинг: 0 / 0
1 сообщений из 1, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / За и против EAV в представленном варианте
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]