ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД с созданием кучи таблиц
25 сообщений из 195, страница 1 из 8
  1  все
Проектирование БД с созданием кучи таблиц
    #38184335
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Есть задача хранить в базе объекты с различными атрибутами, причем будут добавляться новые типы объектов. Мне привычнее создать таблицу с id и типом объекта и таблицу с атрибутами и через таблицу связей связывать объект и его атрибуты. Мой руководитель говорит что так будет тормозить и предлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов). Разных типов объектов может доходить до тысячи, то есть база будет состоять из тысячи таблиц и они будут постоянно добавляться . Вряд ли будут запросы по склеиванию таблиц, но точно будут запросы которые нужно будет прогнать по всем таблицам сразу.

В общем кол-во объектов теоретически может достигать несколько десятков миллионов. Количество типов объектов несколько тысяч. Используемая СУБД Postgresql.

Какой способ будет более правильным и быстрым?
...
Рейтинг: 0 / 0
14.03.2013, 17:15
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184368
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
"серебряной пули нет"(с)
В одних случаях лучше первый способ, в других - второй. у каждого из них есть недостатки.
Если интересно почитать подробнее про преимущества и недостатки - сделайте поиск по
EAV на форуме, будете обеспечены материалом на пару месяцев чтения :)
...
Рейтинг: 0 / 0
14.03.2013, 17:29
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184381
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Спасибо за ответ. А можно вкратце плюсы и минусы обоих способов по вашему мнению. Надо уже срочно определиться с БД.
...
Рейтинг: 0 / 0
14.03.2013, 17:36
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184393
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Злой Бобр
Участник
progand,

Вы ТЗ озвучьте, может что и подскажем. А стрелять по воробьям лично у меня нет желания.
...
Рейтинг: 0 / 0
14.03.2013, 17:39
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184401
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
за вашего руководителя
divide et impera

Пишите (моделируете) приложение под руководством этого мудрого латинского изречения, затем смотрите в каких местах употребляете union all. это будут кандидаты на объединение.
...
Рейтинг: 0 / 0
14.03.2013, 17:45
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184410
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Постараюсь объяснить вкратце. Есть карта на которую пользователи могут добавлять объекты разных типов с атрибутами (например объект дом с атрибутами имя, граница, этажность, кол-во жильцов, адрес и т.д ), так же пользователь может создавать свои пользовательские типы. Так как пользователей может быть много, типов объектов тоже может быть очень много. Будут возможности выбора объектов определенного типа с различными фильтрами, а также возможность выбора объектов всех типов по определенным условиям (на пример выбрать все объекты находящиеся в определенной зоне).

И у меня встал вопрос, какая архитектура БД наиболее выгодна?
...
Рейтинг: 0 / 0
14.03.2013, 17:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184483
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
progandкакая архитектура БД наиболее выгодна?
В данном случае EAV рулит однозначно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 18:17
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184498
progand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
progand
Гость
Dimitry Sibiryakov, не будет ли запрос, всех объектов определенного типа с атрибутами, очень затратным по производительности в архитектуре EAV, ведь в другой архитектуре запрос будет намного быстрее, но создания для меня тысячи таблиц как-то дико.
...
Рейтинг: 0 / 0
14.03.2013, 18:29
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184501
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Злой Бобр
Участник
SERG1257,

Ну я понимаю что у вас в итоге получается многомерный массив. Но это ничего не значит. Оба подхода имеют право на существование. Другое дело что если вы упретесь по количеству запросов в производительность, то вашу схему придется полностью или частично переделывать в то что вам говорит руководитель. Поэтому смотрите на объем данных и количество запросов. Если изначально нет даже приблизительного понятия что будет, то я б строил по схеме руководителя.
...
Рейтинг: 0 / 0
14.03.2013, 18:30
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184515
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Думаете за пользователя, допрашиваете аналитиков, строите модель, обкатываете модель, но заполняете свойства определяемые пользователем нормальными таблицами. Затем добавляете EAV как дополнительные свойства.
Если вам повезет то этих дополнительных свойств, забытых в первой итерации будет немного. Если много, то следующая итерация делает их обычными полями обычных таблиц вынося из EAV.
...
Рейтинг: 0 / 0
14.03.2013, 18:39
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184574
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
progandРазных типов объектов может доходить до тысячиИ набор атрибутов у каждого уникален?
...
Рейтинг: 0 / 0
14.03.2013, 19:07
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184586
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
progandDimitry Sibiryakov, не будет ли запрос, всех объектов определенного типа с атрибутами, очень затратным по производительности в архитектуре EAV, ведь в другой архитектуре запрос будет намного быстрееСудя по описанию, запросы предполагаются несложные...

В любом случае выгоднее сделать таблицу объект с общими стрибутами, а вот для пользовательских атрибутов выбирать - EAV или таблицы. Зависит от требований к производительности (как я понимаю, это стартап, и в перспективе, буквально через полгода, так инвесторам и сказали, каждый житель земли должен занести туда все объекты реального мира, которые он когда либо видел?)

ИМХО можно делать EAV, потом пользовательские атрибуты всегда в таблицы вынести можно, когда "взлетит".
...
Рейтинг: 0 / 0
14.03.2013, 19:14
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184602
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
progandне будет ли запрос, всех объектов определенного типа с атрибутами, очень
затратным по производительности в архитектуре EAV, ведь в другой архитектуре запрос будет
намного быстрее
Код: sql
1.
select * from t where t.typ=XXX


против
Код: sql
1.
select * from t left join attr on t.id=attr.id where t.typ=XXX


при наличии индекса на attr.id будет, конечно быстрее, но эту разницу придётся
разглядывать с микроскопом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 19:23
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184724
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry Sibiryakovпри наличии индекса на attr.id будет, конечно быстрее, но эту разницу придётся
разглядывать с микроскопом.Зависит от запросов.

Если в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F
То в EAV это уже будет не очень быстро :-( Наверное, начальник это и имел в виду, а не простые выборки вида "получить один объект с всеми его атрибутами", иначе бы так не говорил.
...
Рейтинг: 0 / 0
14.03.2013, 21:04
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184726
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
alexeyvgЕсли в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F То
в EAV это уже будет не очень быстро :-(
Да неужели? С EAV это будет выглядеть примерно так же:
Код: sql
1.
2.
3.
4.
5.
(AttrType='attr1' and AttrValue = xxx) or
(AttrType='attr2' and AttrValue between M and K) or
(AttrType='attr3' and AttrValue < F)
group by id
having count(*) = 3


Индекс по AttrType,AttrValue сильно поможет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 21:12
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184751
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry SibiryakovalexeyvgЕсли в запросе пишут attr1 = xxx and attr2 between M and K or attr2 < F То
в EAV это уже будет не очень быстро :-(
Да неужели? С EAV это будет выглядеть примерно так же:
Код: sql
1.
2.
3.
4.
5.
(AttrType='attr1' and AttrValue = xxx) or
(AttrType='attr2' and AttrValue between M and K) or
(AttrType='attr3' and AttrValue < F)
group by id
having count(*) = 3



Индекс по AttrType,AttrValue сильно поможет.Да, неужели :-)

Индекс не поможет, потому что вот эти условия: "AttrType='attr1' and AttrValue = xxx" будут для трёх разных таблиц (трёх экземпляров таблицы атрибутов), и серверу нужно найти результат пересечения выборки.
Если есть 100 объектов с указанными пересечениями значений атрибутов, и по милиону объектов с этими значениями, но без пересечений, то представьте, насколько будет эффективнее составной индекс на атрибуты по сравнению с пересечением результата для каждого фильтра.
...
Рейтинг: 0 / 0
14.03.2013, 21:50
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184756
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
alexeyvgИндекс не поможет, потому что вот эти условия: "AttrType='attr1' and
AttrValue = xxx" будут для трёх разных таблиц (трёх экземпляров таблицы атрибутов)

Какой идиот разнесёт атрибуты по трём таблицам?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 21:57
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184769
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
progandЕсть задача хранить в базе объекты с различными атрибутами, причем будут добавляться новые типы объектов. Мне привычнее создать таблицу с id и типом объекта и таблицу с атрибутами и через таблицу связей связывать объект и его атрибуты. Мой руководитель говорит что так будет тормозить и предлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов). Разных типов объектов может доходить до тысячи, то есть база будет состоять из тысячи таблиц и они будут постоянно добавляться . Вряд ли будут запросы по склеиванию таблиц, но точно будут запросы которые нужно будет прогнать по всем таблицам сразу.

В общем кол-во объектов теоретически может достигать несколько десятков миллионов. Количество типов объектов несколько тысяч. Используемая СУБД Postgresql.

Какой способ будет более правильным и быстрым?
Третий способ: использовать СУБД и хранить в одной "таблице".
...
Рейтинг: 0 / 0
14.03.2013, 22:14
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184776
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry SibiryakovalexeyvgИндекс не поможет, потому что вот эти условия: "AttrType='attr1' and
AttrValue = xxx" будут для трёх разных таблиц (трёх экземпляров таблицы атрибутов)

Какой идиот разнесёт атрибуты по трём таблицам?.. Спросите у специалиста по СУБД, как написать такой запрос, про который шла речь, ну и вообще про модель EAV. Только свой не показывайте, а то он тоже сделает предположение про идиота :-)
...
Рейтинг: 0 / 0
14.03.2013, 22:27
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184784
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
alexeyvgDimitry Sibiryakovпропущено...

Какой идиот разнесёт атрибуты по трём таблицам?.. Спросите у специалиста по СУБД, как написать такой запрос, про который шла речь, ну и вообще про модель EAV. Только свой не показывайте, а то он тоже сделает предположение про идиота :-)А, с having будет одна таблица, но суть от этого не меняется - всё равно будет пересечение 3-х рогромных выборок, какая разница.
...
Рейтинг: 0 / 0
14.03.2013, 22:31
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184801
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
alexeyvgбудет пересечение 3-х рогромных выборок
Это будет пересечение трёх индексных битмапов. Что гораздо меньше чем выборка.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.03.2013, 22:47
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184814
Фотография Шайтан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Шайтан
Участник
progand,

погугли Тенцер БД хранилище объектов

а здесь сравнение различных подходов http://www.inf.tsu.ru/library/Publications/2004/33.pdf
...
Рейтинг: 0 / 0
14.03.2013, 23:00
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38184994
пролетевший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
пролетевший
Участник
Запрос с фильтрацией по атрибутам из "широкой" таблицы будет проще и быстрее чем для EAV. Хотя для UNION из 1000 таблиц да еще если с группировкой да сортировкой - это как фишка ляжет. Проблемы будут в другом:
1. Объекты определяются пользователями системы. То есть приложению нужны права на модификацию схемы, хотя бы частично. Любая дырка в безопасности типа SQL INJECTION даст полный контроль над базой. И админ нужен весьма опытный. Есть кто сумеет грамотно права распредилить ?
2. Пользователи будут создавать объекты, менять, ошибаться, переделывать. ALTER TABLE требует эксклюзивной блокировки (даже чтение блокируется ), и обычно довольно медленная, так как операция обычно редкая оптимизацией в последнюю очередь заморачиваются. То есть на редактирование система будет почти однопользовательской, пока один меняет все ждут. Несмотря на быстрое выполнение запросов.
3. На каком языке клиент ? большинство фреймворков : Java, Ruby/Rails, Django ... довольно хорошо работают с EAV, а вот для работы с редактируемыми пользователем широкими таблицами на ум ничего не приходит. Возможно весь стек доступа к базе придется писать с нуля, а это человеко-месяцы а то и годы. Ресурсы на это есть ?
4. Насколько хорошо переменная схема для бэкапов, репликации/standby ?
5. Средства ETL/отчеты - что может поддерживать динамическую схему ? И сколько придется допиливать напильником даже если есть возможность ?
6. Разработка, как такую схему данных держать в системе контроля версий, как переносить от разработчика к QA и в production ?
...
Рейтинг: 0 / 0
15.03.2013, 08:13
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38185021
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Dimitry Sibiryakovalexeyvgбудет пересечение 3-х огромных выборок
Это будет пересечение трёх индексных битмапов. Что гораздо меньше чем выборка.Понятно, не полноценная выборка, но это всё таки больше, чем поиск по индексу, причём намного, разница же в сотни, тысячи раз.
пролетевшийХотя для UNION из 1000 таблиц да еще если с группировкой да сортировкой - это как фишка ляжет.Как я понял ТС, наиболее типичными будут запросы поиска объектов одного типа по каким то условиям с аттрибутами. Ну и конечно получение одного объекта с аттрибутами по ИД.
...
Рейтинг: 0 / 0
15.03.2013, 08:49
| Ответить | Цитировать | Написать  
Проектирование БД с созданием кучи таблиц
    #38185132
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
progandпредлагает при каждом создании новых типов объектов создавать новую таблицу (объектов и его атрибутов).
А кто сказал что одной таблицы будет достаточно. Объекты бывают сложные.
...
Рейтинг: 0 / 0
15.03.2013, 10:19
| Ответить | Цитировать | Написать  
25 сообщений из 195, страница 1 из 8
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД с созданием кучи таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&startmsg=38184335&tid=1541100]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 150ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 51ms
get tp. blocked users:
 1ms
others: 230ms
total:  473ms
созд. / загр.: 473ms
x
x
Закрыть


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