|
|
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Извеняюсь за отсутсвие, считал дискуссию законченной. Вообще-то не представляю, как можно релаизовать это все по другому, кроме как ЕАВ в упрощенном виде БД должна иметь следующий вид 1)Object(ID,Name,TypeID) 2)Type(ID,Name) 3)Сharacteristic(ID,Name,Restrictions) 4)ObjectCharacteristic(ObjectID,СharacteristicID,Value) 5)TypeCharacteristic(ObjectID,СharacteristicID) Реализовать добавление, удаление, поиск данных через хранимки. Под полем Restrictions я подразумеваю совокупность полей для описания различных ограничений по вводу данных, на основании которрых можно реализовать ограничения при вводе на клиенте и может быть проверку при сохранении в БД в хранимках. Характеристики типа объекта должны быть заполнены у каждого объекта данного типа Ограничений на зависимсоти между характеристиками вводить не предполагается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2012, 22:02 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин Какую форму? какой кастомизатор? Вы вообще о чем?Данные в дополнительных полях вводить как? Проверять введеное, использовать в расчетах, фильтровать, выводить в отчетах... если это не код то что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 05:55 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
2PG81 Чтоже всяк сам себе злобный буратино. Хотите мрачных прогнозов? Вы делаете свою систему - все работает, все довольны. Вьюхи указанные в статье вы тоже делаете - без них отчеты будет лепить напряжно и люди лучше понимают. Дальше вас ждет проблема производительности - чем шире таблицы тем дольше идет выборка каждой строки. Дальше в чью-нибудь светлую голову приходит идея вьюхи материализовать и индексировать - проблемы производительности уходят, но легкость добавления новой характеристики ограничивается перелопачиванием всего кода, где используется вьюха. Дальше в результате чьей-либо халатности происходит ошибка в ключах - строка плохо добавилась, удвоилась, или недоудалилась и т.д. Промучившись с чисткой возникает идея навернуть ограничения целостности на материализованные вьюхи чтобы отловить баг хотя бы на момент синхронизации. Вуаля - имеем систему реализующую недостатки обоих подходов, занимающую вдвое больше места. Возможно вы избежите указанных выше граблей, но чем нужнее система, чем больше народу с ней работает, тем тяжелее проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 07:09 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
PG81, Оценку реальную количества классов получили? Оценку количества свойств? Нет ли явного родства между классами (наследование)? >Под полем Restrictions я подразумеваю совокупность полей для описания различных ограничений по вводу данных плохое решение - в лучшем случае получится псевдореляционная недобаза внутри и так уже по определению нормальной реляционной БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 07:40 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
SERG12572PG81 Чтоже всяк сам себе злобный буратино. Хотите мрачных прогнозов? не надо мыслить только в рамках программного решения проблемы. до вьюх всё праильно написали, а вот дальше... mssqlserver умеет файловые группы. материализация вьюх "не нужен", всё равно производительность упирается в storage, а не в вычисления нужно грамотно разнести сущности и поля сущностей базы по группам, а группы по разным винтам, и будет вам щасте. никаких просадок по производительности. пруфы - откройте для себя plm-системы, step и прочую подобную в машиностроении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 08:52 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
SERG1257Данные в дополнительных полях вводить как? Проверять введеное, использовать в расчетах, фильтровать, выводить в отчетах... если это не код то что? Вроде БД обсуждалась, а не морды к ней... Хотя даже в морде никакого кода для ввода/вывода/поиска сущностей не понадобится. "использовать в расчетах" новые свойства без кода в общем случае не получится, конечно - ну так это и нельзя назвать "базовой обработкой", "использование в расчетах" нужно далеко не для всех атрибутов, очень часто атрибут нужно просто хранить, выводить, от силы - искать по нему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 10:35 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
я уже много раз писал некоторые типы могут иметь динамическое расширение свойств (поставил галочку и все или убрал) не надо все загонять туда, а только пользовательское расширение надо иметь возможность к этим свойствам обращаться прозрачно, как и другим свойствам надо иметь возможность перегнать эти свойства в статический набор свойств (часто требуется) и обратно (если разрежен или по каким еще причинам) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 10:57 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
можно и покрасившее сделать, но и так пока устравивает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 11:04 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
LSVКачественный ЕАВ можно сделать один раз и использовать всю жизнь.Видел три десятка EAV-реализаций от разных авторов. И ни одной качественной. У всех были проблемы с производительностью, с кривыми данными и невозможностью извлечь из базы то, что надо. Кот Матроскин(включая и проблемы с проиводительностью, и с написанием дополнительных фич в дальнейшем, и т.п.)Это такой тонкий стеб? EAV снижает производительность на порядок, а уж написание дополнительных фич становится огромной головной болью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 13:11 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyКот Матроскин(включая и проблемы с проиводительностью, и с написанием дополнительных фич в дальнейшем, и т.п.)Это такой тонкий стеб? EAV снижает производительность на порядок, а уж написание дополнительных фич становится огромной головной болью. Расскажите про Ваш способ реализовать миллион типов обьектов с разными множествами атрибутов, с лучшей производительность и поддерживаемостью, чем EAV. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 13:38 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyEAV снижает производительность на порядок За счёт чего, извините, оно вдруг - на порядок? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 13:44 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинРасскажите про Ваш способ реализовать миллион типов обьектов с разными множествами атрибутов, с лучшей производительность и поддерживаемостью, чем EAV.Создаем таблицу для каждого типа объекта и наслаждаемся производительностью и поддерживаемостью. Dimitry SibiryakovЗа счёт чего, извините, оно вдруг - на порядок?Конкретные цифры без упоминания конкретных примеров обсуждать здесь нет смысла. Но на практике сталкивался с сокращением времени выполнения операций на три порядка после отказа от EAV в пользу простой таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 15:40 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
On 06/22/2012 02:44 PM, Dimitry Sibiryakov wrote: > За счёт чего, извините, оно вдруг - на порядок? Ну как за счёт чего ? Они же думаю, если запрос в 10 раз сложнее, его производительность в 10 раз хуже. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 15:43 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
MasterZiv, прально думают ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 15:48 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey, Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:06 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
MasterZivОни же думаю, если запрос в 10 раз сложнее, его производительность в 10 раз хуже. Осталось только выяснить какой рабинович им насвистел, что запросы к EAV в 10 раз сложнее. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:08 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинBogdanov Andrey, Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта?То есть на ваш взгляд миллион записей в словаре СУБД поддерживать сложнее, чем тот же миллион в вашем велосипеде? Ну а про автогенеренные процедуры я ничего не говорил - это уже ваши собственные фантазии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:26 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
vst_guest mssqlserver умеет файловые группы. материализация вьюх "не нужен",В огороде бузина, а в Киеве дядька всё равно производительность упирается в storage, а не в вычисления авторнужно грамотно разнести сущности и поля сущностей базы по группам, Какие группы? У вас в пределе только ТРИ таблицы vst_guest а группы по разным винтам,группы на SAN. Какие там винты меня не трогает. vst_guest и будет вам щасте. никаких просадок по производительности.Для получения строки в N столбцов придется делать N сканов (по индексу) причем никаких гарантий что они лежат в одном блоке, т.о. количество логических чтений будет минимум в N раз больше. Это только для одной таблицы, а если в джойне их M? плюс никаких намеков на оптимизацию плана. Кот Матроскин Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта? В случае с EAV проект помрет раньше, ибо этот подход СЛОЖНЕЕ. Почему автогенереных, где такое требование? DDL скрипт на базу плюс патч на программу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:39 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов, я думаю, целую систему по схеме EAV делать нет смысла, нужно делать только определенные элемены, которые требуют такого подхода, а все остальное как обычно в реляционной БД. Не думаю что така система способна к длительному существованию в условиях, когда требуется постоянная ее доработка и модернизация вселдствии изменения внешней конъюнктуры. Обычно у такой системы есть один максимум несколько идеологов, которые досканально разбирается в этой системе, а все остальные разработчики только сипользуют функционал системы. Реализация бывает настолько сложной, что кроме этих людей внести изменения в ядро не может никто, по причине опасений все поломать, так не знает всех взаимосвязей. И если так получается, что ухоит главный идеолог системы, то система начинает медленно затухать, а потом ее просто заново переделывают, так ка проще снуля сделать чем разобраться в существующем. Даи обучение новых сотрудников оказывается достаточно продолжительным и требует большой квалификации. Я за разумное сочетание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:51 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyКот МатроскинBogdanov Andrey, Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта?То есть на ваш взгляд миллион записей в словаре СУБД поддерживать сложнее, чем тот же миллион в вашем велосипеде? Ну а про автогенеренные процедуры я ничего не говорил - это уже ваши собственные фантазии. миилион таблиц vs миллион записей - да, я думаю что миллион записей поддерживать проще. Например, решаем к 20% обьектов( по некоему критерию) добавить еще атрибут. Мне надо будет вставить 200 000 записей (одним запросом), Вам - делать генерацию скрипта на 200 000 alter table. Как считаете, что потребует больше усилий разработчика и будет быстрее работать? Насчет хранимых процедур - а как Вы рассчитываете оперировать миллионом таблиц? с помощью динамического SQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:51 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, поддерживаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 16:53 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
SERG1257 Для получения строки в N столбцов придется делать N сканов (по индексу) причем никаких гарантий что они лежат в одном блоке, т.о. количество логических чтений будет минимум в N раз больше. Зачем?? при запросе вида "собрать атрибуты обьекта" используем индекс по ObjectID, все атрибуты берем за 1 скан. Кот Матроскин Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта? В случае с EAV проект помрет раньше, ибо этот подход СЛОЖНЕЕ. Почему автогенереных, где такое требование? DDL скрипт на базу плюс патч на программу.[/quot] С чего бы ему помереть - с точки зрения EAV-ядра вообще фиолетово, 10 типов обьектов у нас в базе или миллион. Ну запросы работают чуть медленнее, вот и все. Почему автогенеренные - потому что "добавление типа обьекта не требует ни единой строки кода". мы обсуждали реализацию этого ограничения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 17:06 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Создаем таблицу для каждого типа объекта и наслаждаемся производительностью и поддерживаемостью. Ога... Дайтедве..... Еще интересно, как будут выглядеть отчеты по таким табличкам. Феерическая картина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 17:07 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
PG81Сахават Юсифов, я думаю, целую систему по схеме EAV делать нет смысла, нужно делать только определенные элемены, которые требуют такого подхода, а все остальное как обычно в реляционной БД. Не думаю что така система способна к длительному существованию в условиях, когда требуется постоянная ее доработка и модернизация вселдствии изменения внешней конъюнктуры. Обычно у такой системы есть один максимум несколько идеологов, которые досканально разбирается в этой системе, а все остальные разработчики только сипользуют функционал системы. Реализация бывает настолько сложной, что кроме этих людей внести изменения в ядро не может никто, по причине опасений все поломать, так не знает всех взаимосвязей. И если так получается, что ухоит главный идеолог системы, то система начинает медленно затухать, а потом ее просто заново переделывают, так ка проще снуля сделать чем разобраться в существующем. Даи обучение новых сотрудников оказывается достаточно продолжительным и требует большой квалификации. Я за разумное сочетание. А я и не говорил что надо в ЕАВ, ЕАВ только для динамических свойств (и то до поры до времени, пока не перевели в статику) вот лишь некоторые типы имеют галочку в "Динамические свойства", у них имеются и статические свойства и динамические ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 17:20 |
|
||
|
наиболее подходящая структура БД для описания характеристик объетов
|
|||
|---|---|---|---|
|
#18+
Динаичсекие свойства нужны когда экземпляр типа имеет особое свойств например не все материалы нуждаются в цвете а детали воще вроде бы не нуждаются (веренее могут быть много цветов их гамма и т.д.) если заказывается деталь цвет = "белая" мы находим ТП где а выходе имеется деталь (нет там воще свойство "цвет") смотрим на входы ТП ищем типы которые имеет свойство (дин или статик) "цвет" и выбираем ту которая имеет цвет="белая" при выпуске детали ей присваиваем свойство "цвет" со значением "белая" ну упрощенно все а так суть передан ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2012, 17:33 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37849850&tid=1541631]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
80ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 397ms |

| 0 / 0 |
