|
|
|
За и против EAV в представленном варианте
|
|||
|---|---|---|---|
|
#18+
Приложение для ведения учета производства неких объектов изначально было сделано по модели 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 кода. В атаче картинка того, что нужно юзерам. В зависимости от группы - меняется число строк в группах в карточке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2015, 19:00 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38952979&tid=1540559]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 122ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...