powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / наиболее подходящая структура БД для описания характеристик объетов
25 сообщений из 54, страница 2 из 3
наиболее подходящая структура БД для описания характеристик объетов
    #37849316
PG81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Извеняюсь за отсутсвие, считал дискуссию законченной.
Вообще-то не представляю, как можно релаизовать это все по другому, кроме как ЕАВ
в упрощенном виде БД должна иметь следующий вид
1)Object(ID,Name,TypeID)
2)Type(ID,Name)
3)Сharacteristic(ID,Name,Restrictions)
4)ObjectCharacteristic(ObjectID,СharacteristicID,Value)
5)TypeCharacteristic(ObjectID,СharacteristicID)

Реализовать добавление, удаление, поиск данных через хранимки.
Под полем Restrictions я подразумеваю совокупность полей для описания различных ограничений по вводу данных, на основании которрых можно реализовать ограничения при вводе на клиенте и может быть проверку при сохранении в БД в хранимках.
Характеристики типа объекта должны быть заполнены у каждого объекта данного типа
Ограничений на зависимсоти между характеристиками вводить не предполагается.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849543
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин Какую форму? какой кастомизатор? Вы вообще о чем?Данные в дополнительных полях вводить как? Проверять введеное, использовать в расчетах, фильтровать, выводить в отчетах... если это не код то что?
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849570
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2PG81 Чтоже всяк сам себе злобный буратино.
Хотите мрачных прогнозов?
Вы делаете свою систему - все работает, все довольны.
Вьюхи указанные в статье вы тоже делаете - без них отчеты будет лепить напряжно и люди лучше понимают.
Дальше вас ждет проблема производительности - чем шире таблицы тем дольше идет выборка каждой строки.
Дальше в чью-нибудь светлую голову приходит идея вьюхи материализовать и индексировать - проблемы производительности уходят, но легкость добавления новой характеристики ограничивается перелопачиванием всего кода, где используется вьюха.
Дальше в результате чьей-либо халатности происходит ошибка в ключах - строка плохо добавилась, удвоилась, или недоудалилась и т.д. Промучившись с чисткой возникает идея навернуть ограничения целостности на материализованные вьюхи чтобы отловить баг хотя бы на момент синхронизации.
Вуаля - имеем систему реализующую недостатки обоих подходов, занимающую вдвое больше места.
Возможно вы избежите указанных выше граблей, но чем нужнее система, чем больше народу с ней работает, тем тяжелее проблемы.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849580
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PG81,

Оценку реальную количества классов получили? Оценку количества свойств? Нет ли явного родства между классами (наследование)?

>Под полем Restrictions я подразумеваю совокупность полей для описания различных ограничений по вводу данных
плохое решение - в лучшем случае получится псевдореляционная недобаза внутри и так уже по определению нормальной реляционной БД
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849630
vst_guest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG12572PG81 Чтоже всяк сам себе злобный буратино.
Хотите мрачных прогнозов?


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

пруфы - откройте для себя plm-системы, step и прочую подобную в машиностроении.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849802
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Данные в дополнительных полях вводить как? Проверять введеное, использовать в расчетах, фильтровать, выводить в отчетах... если это не код то что?

Вроде БД обсуждалась, а не морды к ней...
Хотя даже в морде никакого кода для ввода/вывода/поиска сущностей не понадобится.
"использовать в расчетах" новые свойства без кода в общем случае не получится, конечно - ну так это и нельзя назвать "базовой обработкой", "использование в расчетах" нужно далеко не для всех атрибутов, очень часто атрибут нужно просто хранить, выводить, от силы - искать по нему.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849836
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я уже много раз писал
некоторые типы могут иметь динамическое расширение свойств (поставил галочку и все или убрал)
не надо все загонять туда, а только пользовательское расширение
надо иметь возможность к этим свойствам обращаться прозрачно, как и другим свойствам
надо иметь возможность перегнать эти свойства в статический набор свойств (часто требуется) и обратно (если разрежен или по каким еще причинам)
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37849850
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
можно и покрасившее сделать, но и так пока устравивает
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850171
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVКачественный ЕАВ можно сделать один раз и использовать всю жизнь.Видел три десятка EAV-реализаций от разных авторов. И ни одной качественной. У всех были проблемы с производительностью, с кривыми данными и невозможностью извлечь из базы то, что надо.

Кот Матроскин(включая и проблемы с проиводительностью, и с написанием дополнительных фич в дальнейшем, и т.п.)Это такой тонкий стеб? EAV снижает производительность на порядок, а уж написание дополнительных фич становится огромной головной болью.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850222
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov AndreyКот Матроскин(включая и проблемы с проиводительностью, и с написанием дополнительных фич в дальнейшем, и т.п.)Это такой тонкий стеб? EAV снижает производительность на порядок, а уж написание дополнительных фич становится огромной головной болью.

Расскажите про Ваш способ реализовать миллион типов обьектов с разными множествами атрибутов, с лучшей производительность и поддерживаемостью, чем EAV.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850231
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov AndreyEAV снижает производительность на порядок

За счёт чего, извините, оно вдруг - на порядок?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850511
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинРасскажите про Ваш способ реализовать миллион типов обьектов с разными множествами атрибутов, с лучшей производительность и поддерживаемостью, чем EAV.Создаем таблицу для каждого типа объекта и наслаждаемся производительностью и поддерживаемостью.

Dimitry SibiryakovЗа счёт чего, извините, оно вдруг - на порядок?Конкретные цифры без упоминания конкретных примеров обсуждать здесь нет смысла. Но на практике сталкивался с сокращением времени выполнения операций на три порядка после отказа от EAV в пользу простой таблицы.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850523
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 06/22/2012 02:44 PM, Dimitry Sibiryakov wrote:

> За счёт чего, извините, оно вдруг - на порядок?

Ну как за счёт чего ?
Они же думаю, если запрос в 10 раз сложнее, его производительность в 10 раз хуже.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850545
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

прально думают
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850597
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov Andrey,

Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта?
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850602
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivОни же думаю, если запрос в 10 раз сложнее, его производительность в 10
раз хуже.
Осталось только выяснить какой рабинович им насвистел, что запросы к EAV в 10 раз сложнее.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850642
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинBogdanov Andrey,

Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта?То есть на ваш взгляд миллион записей в словаре СУБД поддерживать сложнее, чем тот же миллион в вашем велосипеде? Ну а про автогенеренные процедуры я ничего не говорил - это уже ваши собственные фантазии.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850666
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vst_guest mssqlserver умеет файловые группы. материализация вьюх "не нужен",В огороде бузина, а в Киеве дядька
всё равно производительность упирается в storage, а не в вычисления
авторнужно грамотно разнести сущности и поля сущностей базы по группам, Какие группы? У вас в пределе только ТРИ таблицы
vst_guest а группы по разным винтам,группы на SAN. Какие там винты меня не трогает.
vst_guest и будет вам щасте. никаких просадок по производительности.Для получения строки в N столбцов придется делать N сканов (по индексу) причем никаких гарантий что они лежат в одном блоке, т.о. количество логических чтений будет минимум в N раз больше. Это только для одной таблицы, а если в джойне их M? плюс никаких намеков на оптимизацию плана.

Кот Матроскин Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта? В случае с EAV проект помрет раньше, ибо этот подход СЛОЖНЕЕ. Почему автогенереных, где такое требование? DDL скрипт на базу плюс патч на программу.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850697
PG81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сахават Юсифов,

я думаю, целую систему по схеме EAV делать нет смысла, нужно делать только определенные элемены, которые требуют такого подхода, а все остальное как обычно в реляционной БД.

Не думаю что така система способна к длительному существованию в условиях, когда требуется постоянная ее доработка и модернизация вселдствии изменения внешней конъюнктуры.
Обычно у такой системы есть один максимум несколько идеологов, которые досканально разбирается в этой системе, а все остальные разработчики только сипользуют функционал системы. Реализация бывает настолько сложной, что кроме этих людей внести изменения в ядро не может никто, по причине опасений все поломать, так не знает всех взаимосвязей. И если так получается, что ухоит главный идеолог системы, то система начинает медленно затухать, а потом ее просто заново переделывают, так ка проще снуля сделать чем разобраться в существующем. Даи обучение новых сотрудников оказывается достаточно продолжительным и требует большой квалификации.

Я за разумное сочетание.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850698
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov AndreyКот МатроскинBogdanov Andrey,

Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта?То есть на ваш взгляд миллион записей в словаре СУБД поддерживать сложнее, чем тот же миллион в вашем велосипеде? Ну а про автогенеренные процедуры я ничего не говорил - это уже ваши собственные фантазии.

миилион таблиц vs миллион записей - да, я думаю что миллион записей поддерживать проще. Например, решаем к 20% обьектов( по некоему критерию) добавить еще атрибут.
Мне надо будет вставить 200 000 записей (одним запросом), Вам - делать генерацию скрипта на 200 000 alter table. Как считаете, что потребует больше усилий разработчика
и будет быстрее работать?

Насчет хранимых процедур - а как Вы рассчитываете оперировать миллионом таблиц? с помощью динамического SQL?
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850706
PG81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин,

поддерживаю
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850741
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257 Для получения строки в N столбцов придется делать N сканов (по индексу) причем никаких гарантий что они лежат в одном блоке, т.о. количество логических чтений будет минимум в N раз больше.

Зачем?? при запросе вида "собрать атрибуты обьекта" используем индекс по ObjectID, все атрибуты берем за 1 скан.



Кот Матроскин Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта? В случае с EAV проект помрет раньше, ибо этот подход СЛОЖНЕЕ. Почему автогенереных, где такое требование? DDL скрипт на базу плюс патч на программу.[/quot]
С чего бы ему помереть - с точки зрения EAV-ядра вообще фиолетово, 10 типов обьектов у нас в базе или миллион. Ну запросы работают чуть медленнее, вот и все. Почему автогенеренные - потому что "добавление типа обьекта не требует ни единой строки кода".
мы обсуждали реализацию этого ограничения.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850742
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Создаем таблицу для каждого типа объекта и наслаждаемся производительностью и поддерживаемостью.
Ога... Дайтедве.....

Еще интересно, как будут выглядеть отчеты по таким табличкам. Феерическая картина.
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850773
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PG81Сахават Юсифов,

я думаю, целую систему по схеме EAV делать нет смысла, нужно делать только определенные элемены, которые требуют такого подхода, а все остальное как обычно в реляционной БД.

Не думаю что така система способна к длительному существованию в условиях, когда требуется постоянная ее доработка и модернизация вселдствии изменения внешней конъюнктуры.
Обычно у такой системы есть один максимум несколько идеологов, которые досканально разбирается в этой системе, а все остальные разработчики только сипользуют функционал системы. Реализация бывает настолько сложной, что кроме этих людей внести изменения в ядро не может никто, по причине опасений все поломать, так не знает всех взаимосвязей. И если так получается, что ухоит главный идеолог системы, то система начинает медленно затухать, а потом ее просто заново переделывают, так ка проще снуля сделать чем разобраться в существующем. Даи обучение новых сотрудников оказывается достаточно продолжительным и требует большой квалификации.

Я за разумное сочетание.

А я и не говорил что надо в ЕАВ, ЕАВ только для динамических свойств (и то до поры до времени, пока не перевели в статику)
вот лишь некоторые типы имеют галочку в "Динамические свойства", у них имеются и статические свойства и динамические
...
Рейтинг: 0 / 0
наиболее подходящая структура БД для описания характеристик объетов
    #37850798
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Динаичсекие свойства нужны когда экземпляр типа имеет особое свойств
например не все материалы нуждаются в цвете
а детали воще вроде бы не нуждаются (веренее могут быть много цветов их гамма и т.д.)
если заказывается деталь цвет = "белая"
мы находим ТП где а выходе имеется деталь (нет там воще свойство "цвет")
смотрим на входы ТП
ищем типы которые имеет свойство (дин или статик) "цвет" и выбираем ту которая имеет цвет="белая"
при выпуске детали ей присваиваем свойство "цвет" со значением "белая"


ну упрощенно все а так суть передан
...
Рейтинг: 0 / 0
25 сообщений из 54, страница 2 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / наиболее подходящая структура БД для описания характеристик объетов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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