Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: EAV зло  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Mnior,

автор
Это почему?


Дык, в той "портянке" я пытался объяснить "почему". Потому что это решает туеву хучу проблем, в случае отсутствия единого Object, шипко сильно ускоряя выдачу прикладной функциональности "на гора".

автор
Так вот, в Entuty пахают Property, Reference, Деревья, и всё для общего Object.


Гм... В этом есть доля правды, практически 100%, ибо свойство объекта, которое можно добавить без кодирования серверной части и клиента - это тоже объект, при сохранении реляционной модели на стороне сервера.

автор
И не надо заострять вопрос только на вашей ссылке.


Даже мыслей не было заострять. Но, почему то Ваш стартовый пост заставил меня превратиться в некроманта.
30 авг 12, 23:34    [13092138]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
locky
уж лефт-анти-семи-джойн (или как он там?) я слава богу увидеть могу!
Да, именно.
Для ТМ (Третий манифест) нехватает механизмов фул-скана.
Т.е. да, отдельная табла будет работать также как и индекс. Но не всегда индекс хорошо.
Поэтому не стоит языку гнаться за физикой и вообще он должен быть более абстрактным.
Пусть физикой занимается отдельная часть языка (индексы и т.п.).

locky
а потом приходится проектор покупать
И не говори.
Но в основном расхлёбывают не те которые кашу заварили.
И прикол в том, что до них не доходит ни до, аргументами, ни после, через опыт.
30 авг 12, 23:41    [13092158]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Mnior
И не говори.
Но в основном расхлёбывают не те которые кашу заварили.
И прикол в том, что до них не доходит ни до, аргументами, ни после, через опыт


Я не слепой. И как раз я из ряда расхлёбывателей, а не теоретиков...
30 авг 12, 23:47    [13092186]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Mnior
Т.е. да, отдельная табла будет работать также как и индекс.


Ну да... бессрочные документы...
30 авг 12, 23:48    [13092191]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
pkarklin
Потому что это решает туеву хучу проблем, в случае отсутствия единого Object, шипко сильно ускоряя выдачу прикладной функциональности "на гора".
Вот как раз я и затрагиваю тему "туеву хучу проблем":
Mnior
но приемуществ на приктике не на столько много сколько кажется, а недостатков достаточно
Поэтому, если не трудно, скинте линк на "тот" пост.

автор
свойство объекта, которое можно добавить без кодирования серверной части и клиента - это тоже объект, при сохранении реляционной модели на стороне сервера.
Вот я о том же. И часто на практике, имея это "универсальность" можно было обойтись без единой строчки кода?
То что освящён только Entity подход, это не значит что он лучше. То что он иногда не создаёт лишние объекты в базе, это не значит что он лучше и быстрее.
Если есть "тулза", не в виде таблы утопленные в JOIN, а VIEWхи на системных таблах, ну и триггера/код. То в скорости разворота ровно тоже самое. О чём я и толкую.

Нужно видеть причины. Причины существования Entity. Что проблема именно в "тулзе разворота системы" и только.
И становится понятно, что он не есть единственный и праведный подход.

То что кто-то не понимает (или боится) что DDL это такойже язык системы, что и DML.
Просто он не так притёрт и не так разжёван на примерах.
Возможно напишут и аналог ORM на DDL, и не нужно будет такого монструозного кода с которого я начат тред (он будет монструозным на C# ).
31 авг 12, 00:08    [13092256]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
pkarklin
Mnior
И не говори.
Но в основном расхлёбывают не те которые кашу заварили.
И прикол в том, что до них не доходит ни до, аргументами, ни после, через опыт


Я не слепой. И как раз я из ряда расхлёбывателей, а не теоретиков...

Зато вот джойны уходят - а проектор то остаётся!!!!
31 авг 12, 00:21    [13092299]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
locky
Зато вот джойны уходят - а проектор то остаётся!!!!
Если бы только проектор. Простаивающий сервер. :)
Хотя это всё временно, пока его не загрузит какой нидь другой ушлёпок. И так по кругу. :(
31 авг 12, 00:36    [13092318]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
ViPRos
Member

Откуда:
Сообщений: 9883
ООП, РМД и т.д. оперируют типами (т.е. какой то козел должен заранее знать все значимые свойства объектов и их классифицировать по совпадении свойств в типы). Рождается мертвая модель предметней области и мертвая прога интерпретирующая эту модель.
А в жизни все течт и все меняется (гвоздь после термообработки ПРИОБРЕТАЕТ свойство "закаленнности" и т.д.).
Т.е. Объект живет.
Потому классифицирующая и интерпретирующая система тоже должна быть живой.
Это можно достичь (в РМД) путем построение гибридной схемы, где в таблицах хранятся регулярные (общеизвестные(в узком кругу свойства объектов (при этом объект может быть классифицирован в нескольких таблицах (т.е. может иметь несколько групп свойств в отношении 1:1). Нерегулярные совйства объекта хранятся в универсальной модели (Объект, ОбъектСвойствТипа***,,.). Имеется спецмеханизм оценивающий мощность нерегулярных и регулярных свойств, который периодически по достижению заданных параметров переструктурирует модель (из нерегулярного в регулярный и обратно, новый реуглярный массив(таблица) и т.д.).
Т.е. - Объект сначала попадает в отстойник, потом растекается по регулярным таблицам, а нерегулярная часть остается в отстойнике (Объект, ОбъектСвойствТипа***,,.).
31 авг 12, 10:02    [13092972]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
ViPRos
ООП, РМД и т.д. оперируют типами (т.е. какой то козел должен заранее знать все значимые свойства объектов и их классифицировать по совпадении свойств в типы). Рождается мертвая модель предметней области и мертвая прога интерпретирующая эту модель.
Потому классифицирующая и интерпретирующая система тоже должна быть живой.
Почему мёртвая? Живая, на тот момент времени. А что бы не стала мёртвой, да, её нужно менять по мере изменения реальной жизни.

ViPRos
Нерегулярные совйства объекта хранятся в универсальной модели (Объект, ОбъектСвойствТипа***,,.)
Т.е. - Объект сначала попадает в отстойник, потом растекается по регулярным таблицам, а нерегулярная часть остается в отстойнике (Объект, ОбъектСвойствТипа***,,.).
EAV не отменяет необходимости менять модель, просто использует для этого другой язык, а не DDL.

Всё равно в EAV нужно описывать модель, типы, констрейны, связи и т.п., никуда от этого не уйти.
А так как разработчики со своей наколенной EAV не дейты с коддами, и ресурсы у них поменьше, чем у микрософтов с ораклами, то язык они придумывают сильно упрощённый и реализацию помедленнее по сравнению с DDL и DML в распространенных СУБД.
Соответственно, EAV имеет смысл использовать для совсем уж примитивных случаев - там его простота будет к месту.
31 авг 12, 10:17    [13093079]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
ViPRos
Member

Откуда:
Сообщений: 9883
alexeyvg
Всё равно в EAV нужно описывать модель, типы, констрейны, связи и т.п., никуда от этого не уйти.

везде надо это описывать, метаописание часть системы динамической классификации, так что пофиг ЕАВ не ЕАВ
система должна дать возможность работать в разных режимах - токо регулярные (нет еав), нерегулярные (токо еав), гибрид
31 авг 12, 10:31    [13093147]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
ViPRos
Имеется спецмеханизм оценивающий мощность нерегулярных и регулярных свойств, который периодически по достижению заданных параметров переструктурирует модель (из нерегулярного в регулярный и обратно, новый реуглярный массив(таблица) и т.д.).
Ща тут ИИ прикрутим
ViPRos
(Объект, ОбъектСвойствТипа***,,.).
Тема топика именно вид этого EAV.
Т.к. "стандартный" EAV не очень то удобен для администрирования.
А тот который было предложено ТС (в первом посте) легче в администрировании, IMXO
И когда ВНЕЗАПНО "нерегулярные" свойство оказалось "регулярным", тогда это не накладывает лишних расходов, ибо грань между ними почти нулевая. И вью данного объекта будет вести себя практически также как и табла и т.п. ...
31 авг 12, 12:51    [13094203]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Ну т.е. легче как в администрировании так и в разработке.
31 авг 12, 12:54    [13094228]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3328
pkarklin
Ну...
Ставка на ВЕРО


Блин. Вот откуда в ядре нашей СРМ понятия "object", "link", "double_link"!
Правда размазанное с помощью включения типовых полей (состояние, логирование, архивирование, модерация, блокировка событиями, права доступа, иерархия в дерево) в каждую табличку конечной сущности и кучи хранимок с перекрытием адаптера БД из ZF, которые это всё обрабатывают... есть даже целая инструкция прогеру "как добавлять новые сущности в ядро"... кто бы её придерживался из последователей!

Пасибки за ссылки. А то я уж решил, что это наш "велосипед". ;)
1 сен 12, 11:51    [13099028]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Я в целом сторонник EAV, точнее "статически структур БД".
Понятное дело что они "условно статические в пределах задачи/проекта".

Я встречал реальные извращения в таких примерах (таблица с 20 заведом созданными столбцами value1...value20 строкового типа, типы связей написанные строками и т. п.). Действительно если были проблемы с быстродействием запросы - это ошибки конкретных людей.

При правильной и некриворукой работе - проблем не было.

Я не за "фанатичное примерение статических структур". Обычно существует некая "точка принятия решения", когда правильнее выбрать такой подход и влияют на это не только первичные "что надо сделать", а так же "за сколько надо сделать", "какой -контингент будет делать". Масштабно я применял подобную структуру крайний раз в 2007-8 годах. До сих пор считаю что там это решение было абсолютно правильное. На данный момент просто работа другая и задачи другие, но "наработки" применяю до сих пор.

Если нет и нельзя получить внятного ТЗ, если нет опытного контингента (а вчерашние студенты или ещё студенты), если надо написать быстро большую систему и заведомо не знаешь какие будут появляться атрибуты/сущности, если система должна быть гибкой и настраиваемой... , то лучше всего использовать этот подход.

Часто такие структуру обвиняют в "тормознутости запросов и загруженности сервера". Чаще виноваты как раз разработчики конкртеной реализации. Это "больше" не в 10ки и 100ни раз. Тем более при правильно написанных системах база часто и 20% ресурсов не занимает. Обычные причины тормозов, которые я видел на продакшен БД - написание запросов с кривыми подзапросами, циклы/курсоры (циклы часто со стороны клиента и каждый раз вызов процедуры для каждой строчки БД, особенно при кривом использовании Linq2SQL будь он проклят вместе с потомком Entity framework и особенно NHibernate). Но даже в них проблема "в кривом использовании", а не в изначальной идеи. Когда мне говорят что "структура базы плохая - поэтому всё тормозит" - зла не хватате, когда смотришь на количество запросов (и вызова процедур) на загруку одной страницы или при нажатии одной кнопки.

Сервера могли вытянуть статическую структуру базы ещё 10ть лет назад, особенно при том что часто функциональный объём системы большой, а пользователей сравнительно не много, тем более не много одновременно работающих.

В принципе, применение и сам холивар о том использовать или нет статическую структуру аналогичен автомобильным
- автомат или механика
- какое масло лить
- шипы или липучка.

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

Далее,
на подобных базах значительно легче делать всякие "ЦМС аналоги", когда саму форму контента можно настраивать и при этом не банально добавлять колонки. Действия сводятся к
1) добавить через системные модули атрибут к сущности (или создать новую сущность и добавить к ней атрибут) с нужным типом, устнавить параметры его а-ля "обязательный"
2) отредактировать существующую или создать новую форму в упрощённой версии Делфи/VS, кинув на неё нужный контрол (мемку, текстЭдит, дейтЭдит, ....) и связав с нужной сущностью/атрибутом
3) вывести поле в нужных таблицах, вызвав построитель запросов, опять же самописном, но довольно простом. Сам построитель может выглядить как дерево, в корне которого "стартовая сущность", а потом выбираются атрибуты или родительские/дочерние сущности на новом уровне дерева и отображаются их атрибуты (далее функциональность с дополнительными условиями).

По факту получается "матрёшка", т. е. БД в БД. Только лазить надо не по системынм вьюхам как information_schema.columns .... или sys. ..., а по своим табличкам.
Понятно что можно хранить и метаданные со ссылкой на обычные физически таблицы, это один из способов.

На этапах пока "построителя запросов нет или вообще не предвидится в проекте", действительно прийдётся писать запросы вида

select en_person.pk as pkPerson,
       en_personalData.pk as fkCurrentPersonalData,
       eds_surname.stringValue as surname,
	   edd_dob.dateValue as birthDate

        
  from dbo.tEntity en_person
 --Выбор текущих паспортных данных
 inner
  join dbo.tEntityDataEntity ede_personalData
 inner
  join dbo.tEntity en_personalData
  
  inner
   join dbo.tEntityDataString eds_surname
     on eds_surname.fkEntity = en_personalData.pk
    and eds_surname.fkAttribute = @surname
  
    on en_personalData.pk = ede_personalData.fkValueEntity
   and en_personalData.deleted = 0

    on ede_personalData.fkEntity = en_person.pk
   and ede_personalData.fkAttribute = @currentPersonalData
   and ede_personalData.deleted = 0

  left
  join dbo.tEntityDataDate edd_dob
    on edd_bod.fkEntity = en_person.pk
   and edd_bod.fkAttribute = @birthDate
   --and edd_bod.deleted = 0


только не надо называть эти запросы "сложными", по факту они однотипные, а три строчки на каждый джойн - это моё форматирование. Я бы не сказал что считаю джойн при наличии правильных индексов очень медленной и сложной операцией для MSSQL Server.
Если учтиывать что такие запросы только "в печатании и копи-пасте отнимают время", которая на фоне остальных затрат времени (подумать и придумать) не такое большое, то я вообще никаких проблем не вижу в написании хранимых процедур с такими запросами когда такая структура используется с обычным фронтэндом (а не спецально написаной системой).

Более того, та же самая "матрёшка" применяется не только в БД. Тот же "браузер", такая же матрёшка. Можно говорить про то что вэб тормознутый и т. п., там ещё больше "накручено", но при этом мы с вами сидим сейчас на формуе через браузер (а не через специальный клиент для SQL.RU) часто барузер ещё запускает java, часто до этого нужен какой-нить silverlight, .net framework (и на сервере), web-сервер и т. п. виртуальные машины и "прослойки". О какой "производительности" мы говорим?!
Мы давно в большенстве не пишем толстый клиент скопилированный крутым компилятором под конкретную ОС (тем более без ОС, которая прослойка такая же). Все помнят времена когда Делфи был популярнее всего ВЭБа вместе взятого? А теперь иногда браузер на можном компе виснет с 5тью вкладками.

Если зашевелить извилинами можно писать очень интересные которые массово работают с данными (через ХМЛ), естественно не надо работать по одному атрибуту и получать значение каждой ячейки отедельно. Часто можно орграничится столькоими ДМЛ операциями - сколько типов данных используется при редактировании (и соответственно таблиц для хранения значений).
Важно правильно определять "что это за атрибут". Если это "стркоа", то надо поинмать "какая", если это "фамилия", то это скорее всего какая-то короткая, но индексированная строка, а если это "аннотация или биография", то скорее всего это большой текст какой-то...

Принимать решение "как делать проект с нуля" каждый раз надо принимать индивидуально. Статическую структуру всегда можно использовать как часть проекта, хотя я не люблю половинчатых решений.
Главное "правильно рассматривать моменты когда её нужно применять, какие они есть, как правильно это делать". А говорить о том что "статическая структура - зло" - всё равно что говоить "секс без призерватива фигня".

Так же я любитель "единого справочника" в любых системах для "атомарных значений", с один раз написанными функциями.
Я НЕ любитель копи-пастной рутинной работы, а особенно её потом изменения после каких-то "хотелок".
Одно дело БД где 10ки или чуть больше сотни таблиц, другое дело реально большое количество сущностей со всей оперы (медицина, склад, питание, ....) и задача "автоматизировать каждую меловь, даже которую ты не видел и не в состоянии всё в голове удержать "как стишок", а когда начинаешь задавать вопросы "а нахрен это в таком количестве надо" понимаешь что "надо так надо...".

Вот примеры "что я использую в такиж стркутурах"

1) общий справочник
Используется просто в большом количестве проектов.

CREATE TABLE [dbo].[tCommonDictionary](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkOwner] [uniqueidentifier] NULL,
	[fkMainOwner] [uniqueidentifier] NULL,
	[name] [nvarchar](255) NULL,
	[synonym] [nvarchar](255) NULL,
	[description] [nvarchar](450) NULL,
	[sequence] [decimal](9, 2) NULL,
	[deleted] [bit] NOT NULL,
	[fkType] [uniqueidentifier] NULL,
	[hrchID] [hierarchyid] NULL,
	[hrchLevel]  AS ([hrchID].[GetLevel]()) PERSISTED,
	[childCount] [int] NOT NULL,
 CONSTRAINT [pk_tCommonDictionary_pk] PRIMARY KEY CLUSTERED 
(
	[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO



2) Сама табличка хранения экземпляров сущностей нужного типа.
CREATE TABLE [dbo].[tEntity](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkType] [uniqueidentifier] NOT NULL,
	[deleted] [bit] NOT NULL,
 CONSTRAINT [PK_tEntity] PRIMARY KEY CLUSTERED 
(
	[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]


3) Таблица для связей между экземплярами сущности
CREATE TABLE [dbo].[tEntityDataEntity](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkEntity] [uniqueidentifier] NOT NULL,
	[fkAttribute] [uniqueidentifier] NOT NULL,
	[fkValueEntity] [uniqueidentifier] NOT NULL,
	[deleted] [bit] NOT NULL,
 CONSTRAINT [PK_tEntityDataEntity] PRIMARY KEY CLUSTERED 
(
	[fkEntity] ASC,
	[fkAttribute] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO



4) таблица для атрибутов ссылающихся на общий справочник
CREATE TABLE [dbo].[tEntityDataKeys](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkEntity] [uniqueidentifier] NOT NULL,
	[fkAttribute] [uniqueidentifier] NOT NULL,
	[fkValue] [uniqueidentifier] NOT NULL,
	[deleted] [bit] NOT NULL,
 CONSTRAINT [PK_tEntityDataKeys_fkEntity_fkAttribute] PRIMARY KEY CLUSTERED 
(
	[fkEntity] ASC,
	[fkAttribute] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
 CONSTRAINT [uk_tEntityDataKeys_pk] UNIQUE NONCLUSTERED 
(
	[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]


5) Таблицы для типов данных "число", "строка", и т. д.
CREATE TABLE [dbo].[tEntityDataDate](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkEntity] [uniqueidentifier] NOT NULL,
	[fkAttribute] [uniqueidentifier] NOT NULL,
	[dateValue] [datetime] NOT NULL,
	[deleted] [bit] NOT NULL,
 CONSTRAINT [pk_tEntityDataDate] PRIMARY KEY CLUSTERED 
(
	[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
 CONSTRAINT [uk_tEntityDataDate_fkEntity_fkAttribute] UNIQUE NONCLUSTERED 
(
	[fkEntity] ASC,
	[fkAttribute] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO


6) Таблиц для связи "Тип сущности - Атрибут" (оба лежат в общем справочнике)
CREATE TABLE [dbo].[tEntityAttr](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkOwner] [uniqueidentifier] NULL,
	[fkAttribute] [uniqueidentifier] NOT NULL,
	[fkGroup] [uniqueidentifier] NULL,
	[fnOrder] [decimal](3, 1) NULL,
	[deleted] [bit] NOT NULL,
 CONSTRAINT [pk_tEntityAttr] PRIMARY KEY CLUSTERED 
(
	[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
 CONSTRAINT [uk_tEntityAttr_fkAttribute_fkOwner] UNIQUE NONCLUSTERED 
(
	[fkAttribute] ASC,
	[fkOwner] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO


7) Таблица для объединения атомарных значений в группы (например, в атомарном справочнике лежат какие-то диагнозы из справочника МКБ, а в этой таблице "группы диагнозов" или "строчки отчётов по заболеваемости", которые на хардкодятся на уровне формы).

CREATE TABLE [dbo].[tGroup](
	[pk] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
	[fkOwner] [uniqueidentifier] NULL,
	[fkCommonDictionary] [uniqueidentifier] NOT NULL,
	[deleted] [bit] NOT NULL,
 CONSTRAINT [PK_tGroup] PRIMARY KEY CLUSTERED 
(
	[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO


Нет "абсолютных вещей", это действительно так. Точно так же как нельзя сказать "надо везде использовать статическую структуру", потому что где-то и смысла нет показывать что ты её знаешь (разве что у тебя уже есть готовое и можно поставить и забыть), потому что в этом случае часто надо сделать "начальные вложения" что бы "окупить", часто нет смысла её использовать по каким-то техническим причинам. Так же нельзя говорить что "абсолютно нельзя её использовать". Я был в проектах где без неё "никак". Ситауация часто напоминает момент когда надо сделать разово "высокую ставку" или "сильно выложиться в начале, что бы потом можно было реализовать".

Такие структуры есть, от них не спрячемся. Лучше думать о том как "секционировать таблицы", как "оптимизировать и улучшать".
Бывают случае когда "транспонировать стркои в столбцы и не надо", могут вполне оказаться какие-то компоненты "умные" которые это делают на клиенте, может быть окажется какой-то "хитрый pivot/unpivot в СУБД, а не то что есть сейчас аналог group by + max(case .... ).

Заранее спасибо если прочитали )
18 сен 12, 16:10    [13183550]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
NIIIK, заранее простите. И без обид.

Немного отдаёт запашком детского лепета. Не можете вы ключевые вещи описывать.
Несколько логических ошибок. Некоторые "аргументы" не доказывают предпосылок.
Приведение аналогий - моветон. Многое вообще зомбирование.
Кое что выражено слишком многими буквами, хотя сводится к одному "аргументу". К примеру - "Подход просто существует, поэтому и пользуют", "Так написано, ну и ладно" (типа "кто сказал что не кошерно", т.е. утеряли первоисточник аргументов).
Много лирики выходящих за тематику. Типа "А я делаю так" (хотя там сверх базовые вещи и ничего нового).
Затронуто очень много что гарантирует холливар в OffTop. Что практически сводится к троллингу.
Понятия которые использовались не коррелируют с понятиями темы (хотя подразумевается автором). И поэтому дискутировать нет смысла. К примеру "статическая структура".
Есть подозрение что вы кое-что не поняли (не в давались в детали) из выше сказанного.

Намного проще считать, что вы ничего не писали вообще и рассматривать всё с начала по кусочкам.
У вас есть элементы интуитивного подхода, но применено неправильно. Интуитивный подход как доказательство - нет, как эвристика поиск ответа, да (но это сугубо личное).

Поймите, чтобы просто начать говорить, что оно хорошо или нет. То говорится всегда по сравнению с чем-то, т.е. необходим опыт с разными подходами. А то что "Я пользовался X - у меня получалось" это дет сад, простите.
Вы как буд-то пытаетесь защитить что-то личным примером ("А я пользуюсь!"). А нужно доказать аргументами (сравнить непредвзято и тщательно проанализировать все детали).

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

Это всё к стратегии разговора.
===================================================================================
То что у вас приемлемо работает и это устраивает и должно устраивать всех. Это ерунда.
Другое дело если вы потратили время и реализовали задачу минимум 3мя подходами и могли понять что к чему, то уверяю, многое вами выше-сказаное для вам потеряло бы смысл.

В больших проектах EAV сводится к нескольким сотням соединений. И при этом на больше чем лимонных таблАХ.
Поэтому о чистом EAV даже нет смысла говорить. И тогда вскрывается почему EAV зло (философия) и что есть альтернативы, которые не хуже даже на простых проектах.
Но главное другое. Вы должны честно сравнить все проекты, написанные совсем на статике (полный натив), на EAV и на всевдо EAV (при который я поднял тему).

PS: Серьёзно, хочется ответить практически на каждое предложение.
Да, я представил примерно как у вас оно происходит и как реализовано.
18 сен 12, 22:25    [13185377]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
PS: Во надо же какую бомбу поткинули.
Отвечать это тотальнейший холивар, там одно предложение можно раскурочивать, но глваное совергенно не по теме.
Но чтобы не быть голословным надо отвечать. NIIIK - это подло. Вы меня подловили.

Давайте так, NIIIK.
Вы читали всю тему внимательно?
18 сен 12, 22:51    [13185509]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Mnior,

Какие обиды?! Тем более вы много раз помогли слишком адекватными ответами до этого на мои вопросы в отличие от того кто тут накручивает счётчик постов.
Я и не ожидал изначльно что мой подход будет вами "принят". Это скорее "можно ещё вот так делать". Какие минусы у подхода я знаю совсем не плохо и "на своей шкуре".
Если я попытаюсь в подробностях перечислять на конкретных примера - я просто неделю вылазить из-за компа не буду. (но самые яркие воспоминани о Китайсом и о Казахском проектах). И самое что я хочу донести, то что у ЕАV ограничение ресурсов часто лежит на много дальше чем многие думают.
Подход "гибрибный" с динамичеси изменяемыми таблицами я тоже понимаю хорошо и с динамическим СКЛ работать тоже могу. Хотя я бы очень не хотел позволять пользователю влиять DDL-операциями на базу, пусть и косвенно. Сделать так, что всё работало "чётко и точно" с учётом внешних ключей и т. п. не думаю что легко.

По сути в моём случае можно убрать все таблицы tEntity*
и заменить в метаданных на ссылки на реальные таблицы/колонки далее прийду к аналогу вашего примера.
18 сен 12, 23:01    [13185536]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Mnior,

Да никто не подлавливал, тема то давненько была создана, просто "руки не доходили ответить". Сегодня, когда "холивар подтих" я просто выразил свои мысли по поводу EAV и подходов "когда уже все замолчали". А то быть частью белого шума совсем не хочется.

Я в целом и ответа не ждал, сам прекрасно понимаю что тема вечная и холиварная из разряда "шипы или липучка для зимней резины".
18 сен 12, 23:05    [13185558]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
NIIIK
Подход "гибрибный" с динамичеси изменяемыми таблицами


Ох и в большую пичальку выливается такой подход на продакшене, работающем 24х7х365. У Вас много технологических окон?
18 сен 12, 23:09    [13185572]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
pkarklin,

ни одного, я его просто "понимаю как работает".
18 сен 12, 23:11    [13185580]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
NIIIK
ни одного, я его просто "понимаю как работает".


Отлично! Ибо в таком окружении даже форин проблематично наложить при миграции первичного ключа. Уж куда тут динамические таблицы.
18 сен 12, 23:17    [13185596]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
pkarklin,

вы главное "не закрывайте разум" иногда самые глупые решения вначале будут оказываться самыми гениальными в конце )
а то часто происходит удивление "нифига себе, оказыватеся вот оно чё..." :)
18 сен 12, 23:21    [13185608]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
NIIIK
вы главное "не закрывайте разум"


Я всегда открыт для всего нового. В пределах SLA...
18 сен 12, 23:23    [13185619]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
NIIIK
Да никто не подлавливал, тема то давненько была создана, просто "руки не доходили ответить". Сегодня, когда "холивар подтих" я просто выразил свои мысли по поводу EAV и подходов "когда уже все замолчали".
Но вы точно тему прочитали, не только заголовок?
19 сен 12, 00:23    [13185785]     Ответить | Цитировать Сообщить модератору
 Re: EAV зло  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg
Но вы точно тему прочитали, не только заголовок?
А вот и явно булыжник в мою сторону.
Шо посеешь ... ну ожидаемо, естественно.
19 сен 12, 00:51    [13185827]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить