|
|
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
guest_20040621 И чем больше изменений, тем хуже качество данных. Не согласен. Особенностью EAV является неухудшение качества (хуже некуда) при изменениях. Ведь сам контейнер не меняется, меняется только начинка. Обычная рел. БД при изменениях становится хуже и требуется периодический реинженииринг. зы ессно новое заменяет старое , но это не зависит от EAV. В EAV даже можно как-то сохранить старую структуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 14:14 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
> сам контейнер не меняется, меняется только начинка Именно. И чем дальше, тем сильнее представление может отставать от реальности. > Обычная рел. БД при изменениях становится хуже и требуется периодический реинженииринг. Она не становится хуже, это естественный процесс, так и должно быть. Разница в том, что вы имеете штатную регулярную процедуру изменения структуры данных. Контролируемую. С предсказуемыми результатами. > это не зависит от EAV У меня нет необходимости убеждать вас в очевидных для меня вещах. Хотите ходить по граблям - на здоровье, меня это не беспокоит. Вы описываете достаточно широко распространённый подход, камуфлирующий криворукость разработчиков. Криворукость следует не маскировать, а выявлять и заставлять платить за неё баблом и/или репутацией. Никак иначе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 14:43 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
guest_20040621Именно. И чем дальше, тем сильнее представление может отставать от реальности. Оно не может отставать по определению - оно всегда соотв. текущим потребностям пользователя. guest_20040621Она не становится хуже, это естественный процесс, так и должно быть. А совместимость со старыми программами ? Процесс деградации БД - это действительно естественный процесс. guest_20040621Вы описываете достаточно широко распространённый подход, камуфлирующий криворукость разработчиков. Не очень уж распространенный. Для себя да, делают многие, а для конечного пользователя - нет. Для этого надо иметь очень прямые руки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 16:35 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
guest_20040621> сам контейнер не меняется, меняется только начинка Именно. И чем дальше, тем сильнее представление может отставать от реальности. > Обычная рел. БД при изменениях становится хуже и требуется периодический реинженииринг. Она не становится хуже, это естественный процесс, так и должно быть. Разница в том, что вы имеете штатную регулярную процедуру изменения структуры данных. Контролируемую. С предсказуемыми результатами. > это не зависит от EAV У меня нет необходимости убеждать вас в очевидных для меня вещах. Хотите ходить по граблям - на здоровье, меня это не беспокоит. Вы описываете достаточно широко распространённый подход, камуфлирующий криворукость разработчиков. Криворукость следует не маскировать, а выявлять и заставлять платить за неё баблом и/или репутацией. Никак иначе. Какой Вы, батенька, ... суровый. Только так, и никак иначе! Задачи разные бывают. И говорить, что EAV - это черное, а sparse columns - белое, неправильно. Есть масса оттенков. Взять систему АСУТП и Industrial SQL. На мой взгляд, чистое EAV. Все данные в одной таблице с колонками: - тэг (это одновременно идентификатор объекта и его конкретного атрибута); - время; - значение. И ничего, задачи АСУТП решаются быстро и красиво. А вот "штатная регулярная процедура изменения структуры данных" меня удивила. Я с таким не сталкивался. Интересно, для каких задач такой жизненный цикл применяется? к ТС: Ценность Вашего индекса авторcreate index (id_client, id_grp, id_row, id_attr, value_checksum) include(value), где value nvarchar(max) трудно оценить не зная, что означает id_client, id_grp, id_row. Может быть индекс авторcreate index (id_attr, value).... ускорит Ваши запросы, а может нет. Вам советовали использовать функцию типа Function GetValue(id_client, id_grp, id_row, id_attr) ... return value. Она действительно облегчит написание запросов, но только, если на value не накладывается условий. Т.е. select GetValue(1,2,3,4) as field1, GetValue(5,12,4,11) as field2, .... и т.д. Но не where GetValue(1,2,3,4) >100 and .... Хотел посоветовать написать генератор запросов :), но сам предпочитаю копи-паст в такой ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 21:29 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
Видите ли, DirksDR, в чём дело: у _мод была репутация, которая не позволила более определённо квалифицировать его точку зрения. Для того, чтобы иметь возможность изредка тупить, эту репутацию вам нужно сначала заработать. Про разные задачи вы будете рассказывать тем, кому это интересно. В данном случае - "...EAV - это черное, а sparse columns..." - вы даже не поняли предмета обсуждения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2014, 00:25 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
авторУ EAV есть своя ниша определяемых пользователям дополнительных свойств, в которой недостатки незаметны, а преимущества неоспоримы. Про АСУТП не зря припомнили. В точку. Все при деле, но АСУ сама по себе, а ТП, нередко даже без документации, само по себе. И все на зарплате и прибыль даже есть чтобы с банком рассчитаться и взять новый кредит. Ни при каких обстоятельствах пользователь не может добавить атрибут без согласования с инженером, а инженер не может добавить атрибут без согласования с начальством. Это в том числе входит в культуру пользования базами данных. Если каждая творческая единица начнет свои атрибуты плодить, инженер начнет вешаться на каждой осине по дороге на службу. Это вам не природа с четырьмя кислыми буквами. У нас столько времени нет чтобы миллиард лет забивать четыре столбца хламом в надежде что они когда-нибудь заговорят по-русски. Другими словами если вы хотите успешно скрывать от начальства свою бесполезность - EAV наилучшее решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 12:10 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
deblogger Ваши аргументы могут относиться к самым разным системам, EAV тут не виновато. EAV не предполагает, что "каждая творческая единица начнет свои атрибуты плодить", естественно, это делается централизовано службой сопровождения ИС. Так же, как и в любой другой ИС. Просто, в случае EAV это делается легче и быстрее. Об этом много говорилось на этом форуме, нет смысла повторяться. guest_20040621 Вы считаете, что Ваша черно-белая классификация есть истина в последней инстанции? Не вижу смысла спорить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 21:29 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
DDirks, EAV предполагает что не придется проектировать БД. Ради чего собственно весь сыр-бор. Кого вы хотите обмануть? Вы же все программисты. Вам в стопицот раз проще написать туеву хучу процедур чем ломать голову над отношениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 01:38 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
debloggerDDirks, EAV предполагает что не придется проектировать БД. Ради чего собственно весь сыр-бор. Кого вы хотите обмануть? ... Ну, почему не придется проектировать? Просто метаданные описываются не средствами СУБД, а в таблице(ах) базы ИС. Это так, к слову. Я не рассматриваю EAV как альтернативу традиционной структуре БД, а как дополнение. В нашей службе техподдержки производственных задач на обслуживании несколько программных комплексов, в каждом несколько сотен обычных таблиц и по 2-3, построенных по принципу EAV. Кроме того занимаюсь сбором информации с серверов АСУТП в единую базу диспетчерской системы. Системы АСУТП (около 40 шт) самые разные, но большинство построено по принципу EAV, потому что здесь это оправдано. Сотни разнообразных технолгических объектов, у каждого десятки атрибутов - эта задача как раз для EAV. Я никого не хочу обмануть, однако считаю, что уместное применение EAV полезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 19:30 |
|
||
|
EAV vs SQL Server Sparse columns
|
|||
|---|---|---|---|
|
#18+
debloggerDDirks, EAV предполагает что не придется проектировать БД. Ради чего собственно весь сыр-бор. Кого вы хотите обмануть? ... Ну, почему не придется проектировать? Просто метаданные описываются не средствами СУБД, а в таблице(ах) базы ИС. Это так, к слову. Я не рассматриваю EAV как альтернативу традиционной структуре БД, а как дополнение. В нашей службе техподдержки производственных задач на обслуживании несколько программных комплексов, в каждом несколько сотен обычных таблиц и по 2-3, построенных по принципу EAV. Кроме того занимаюсь сбором информации с серверов АСУТП в единую базу диспетчерской системы. Системы АСУТП (около 40 шт) самые разные, но большинство построено по принципу EAV, потому что здесь это оправдано. Сотни разнообразных технолгических объектов, у каждого десятки атрибутов - эта задача как раз для EAV. Я никого не хочу обмануть, однако считаю, что уместное применение EAV полезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 19:34 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1541005]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 378ms |

| 0 / 0 |

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