ReSQL.ru
     
powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование большого колличества связанных one-to-many таблиц
19 сообщений из 19, страница 1 из 1
Проектирование большого колличества связанных one-to-many таблиц
    #39924252
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
Всем привет! Есть пример вот с такой структурой бд: https://dbdiagram.io/d/5e3ed10a9e76504e0ef13332

И есть вопрос по проектированию бд, в которой есть н-ное колличество таблиц, связанных между собой one-to-many. В примере к одной записи из таблицы bace_part относятся несколько записей из таблицы sub_part_1, к одной записи из которой относится несколько записей из sub_part_2, и т.д. до таблицы end_part. В примере между bace_part и end_part 3 таблицы. Это значит, что для фрмирования выборки всех end_part, которые относятся к bace_part нужно будет написать 3 join-а, или 3 вложенных select-а, что:
1. Не очень удобно
2. Не супер по производительности

Вопрос в том, есть ли какие-то обходные решения двух описанных выше проблем? Есть мысль, насчет создания смежной таблицы, которая будет отвечать за связь всех элементов внутри bace_part, но это решение мне кажется далеко не самым лучшим.

Подскажите, как лучше всего решить эти проблемы. Заранее спасибо :)
...
Рейтинг: 0 / 0
08.02.2020, 18:52
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924254
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
cherepicaВопрос в том, есть ли какие-то обходные решения двух описанных выше проблем?

Уволить того, кто считает проблемой первое. Нанять того, кто способен решить второе.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.02.2020, 19:05
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924260
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
Dimitry Sibiryakov, хорошо, какими путями можно решить второе?
...
Рейтинг: 0 / 0
08.02.2020, 19:25
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924261
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
cherepicaкакими путями можно решить второе?

Да как обычно: анализ плана, построение недостающих индексов или удаление лишних.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.02.2020, 19:26
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924262
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
Dimitry Sibiryakov, я, это, просто новичек в dba. Т.е. никакая смежная таблиц для связи всех элементов не нужна? Надо просто проиндексировать?
...
Рейтинг: 0 / 0
08.02.2020, 19:30
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924269
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
При чём тут DBA? Знание того как сервер выполняет запросы - базовое для каждого
проектировщика БД и разработчика приложений, с ними работающих. Короче, для любого, кто
пишет запросы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.02.2020, 19:53
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924273
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
Dimitry Sibiryakov, хорошо, переформулирую вопрос:
Как эффективней всего получать даные по последней таблице, имея на руках id записи из первой таблицы? Первичные ключи уже проиндексированны - значи ли это, что использование LEFT JOIN при выборке на каждую подтаблицу не будет плохим по производительности решением?

п.с. что бы вы посоветовали для начинающего? (курсы/книги)
...
Рейтинг: 0 / 0
08.02.2020, 20:11
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924274
ёёёёё
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ёёёёё
Участник
cherepica
Dimitry Sibiryakov, хорошо, переформулирую вопрос:
Как эффективней всего получать даные по последней таблице, имея на руках id записи из первой таблицы? Первичные ключи уже проиндексированны - значи ли это, что использование LEFT JOIN при выборке на каждую подтаблицу не будет плохим по производительности решением?

п.с. что бы вы посоветовали для начинающего? (курсы/книги)

Инсталлируй сервер БД на свой пк, нагенери побольше тестовых данных и тупо щупай руками. Все так и делают.
...
Рейтинг: 0 / 0
08.02.2020, 20:18
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924285
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Dimitry SibiryakovДа как обычно: анализ плана, построение недостающих индексов или удаление лишних.Это решит проблему на 0..5% , т.е. не решит.

Варианты решения зависят от поставленной задачи.
Возможно переделать на одну таблицу с древовидной структурой и парой-тройкой вспомогательных таблиц.
...
Рейтинг: 0 / 0
08.02.2020, 21:11
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924287
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
cherepica
Как эффективней всего получать даные по последней таблице, имея на руках id записи из первой таблицы? Первичные ключи уже проиндексированны - значи ли это, что использование LEFT JOIN при выборке на каждую подтаблицу не будет плохим по производительности решением?

Это зависит от количества записей в таблицах, обычно чем ниже уровень - тем больше записей в таблице. Как уже сказали передо мной нужно тестировать на реальных объемах. Как правило нормальные субд при нормальной индексации справляются с джоинами на ура...
Ну а с точки зрения решения в лоб именно вашего вопроса
cherepica
Как эффективней всего получать даные по последней таблице, имея на руках id записи из первой таблицы?

Тут нужна не смежная таблица, а дополнительные поля и связи, например: если в end_part добавить дополнительный вторичный ключ на bace_part (такой же как в sub_part1) тогда для поиска в end_part по id из bace_part промежуточные таблицы не нужны...
Палка о двух концах - выигрываем в быстродействии, проигрываем в объемах...
Можно вторичными ключами связать вообще все промежуточные таблицы со всеми вышестоящими, но имеет ли это смысл
...
Рейтинг: 0 / 0
08.02.2020, 21:20
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924292
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
L_argo, даже не был в курсе о реализации дерева в табличном виде. Спасибо большое!
...
Рейтинг: 0 / 0
08.02.2020, 21:41
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924294
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
vmag, спасибо. Надо выделить, по каким параметрам будет чаще всего происходить запрос, и добавить дополнительные ключи только в нужные места. Пока это решение кажется самым правильным
...
Рейтинг: 0 / 0
08.02.2020, 21:42
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924295
ёёёёё
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ёёёёё
Участник
cherepica
vmag, спасибо. Надо выделить, по каким параметрам будет чаще всего происходить запрос, и добавить дополнительные ключи только в нужные места. Пока это решение кажется самым правильным

Не надо ничего. Наличие ключа - это не просто дилемма "большой объем против скорости". Наличие ключа запросто может быть причиной торможения при доступе к данным.
Пока не началось реальной работы на реальных данных - ограничься ключами пк/фк.
Потом, по мере накопления статистики, станет ясно, что и где крутить.
Лучше, конечно, нанять разработчика.
...
Рейтинг: 0 / 0
08.02.2020, 21:53
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924296
cherepica
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cherepica
Гость
ёёёёё
cherepica
vmag, спасибо. Надо выделить, по каким параметрам будет чаще всего происходить запрос, и добавить дополнительные ключи только в нужные места. Пока это решение кажется самым правильным

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


Иными словами: оставить все как есть?
...
Рейтинг: 0 / 0
08.02.2020, 21:59
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924298
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
cherepicaзначи ли это, что использование LEFT JOIN при выборке на каждую подтаблицу не будет плохим
по производительности решением?

Оно будет плохим решением потому, что написавший такой запрос не ведает что творит.
Внешнее соединение в данном случае совершенно бессмысленно. Ну а производительность будет
нормальная.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.02.2020, 22:12
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924311
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
ёёёёё
Не надо ничего. Наличие ключа - это не просто дилемма "большой объем против скорости". Наличие ключа запросто может быть причиной торможения при доступе к данным.


Да ну прям... Наличие Ключей и связи между первой и последней таблицей - тормоза ?
Это как утверждать что ключи и связи вообще не нужны...
Предложите еще удалить те 4 что уже есть для ускорения...
...
Рейтинг: 0 / 0
08.02.2020, 23:53
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924312
ёёёёё
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ёёёёё
Участник
cherepica
ёёёёё
пропущено...

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


Иными словами: оставить все как есть?

Что я непонятного написал, чтобы нужно было "иными"? Нет никакого скрытого смысла.

Читай Мартина Грабера и руководства к своей СУБД, и начинай работать с данными, чтобы джойны не казались "неудобными".
...
Рейтинг: 0 / 0
09.02.2020, 00:15
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39924991
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
cherepica
Dimitry Sibiryakov, хорошо, переформулирую вопрос:
Как эффективней всего получать даные по последней таблице, имея на руках id записи из первой таблицы?


Либо джойнить, либо иметь денормализированную таблицу.
В зависимости от...
...
Рейтинг: 0 / 0
11.02.2020, 01:15
| Ответить | Цитировать | Написать  
Проектирование большого колличества связанных one-to-many таблиц
    #39930363
Sergei.Agalakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei.Agalakov
Участник
У вас подозрительный пример. Очень плохо, когда таблицы называются подсущность_номер_3. Реляционные базы прекрасно работают с хорошо определенными сущностями типа person, contract, car, room... Если есть реальная необходимость работать с деревьями и бесконечно все разбирать по кусочкам, то есть если это вообще основное назначение базы, то поглядите на graph databases
Еслт вы в состоянии определить сущности и их отношения друг с другом, то реляционные базы - то, что вам нужно. Не надо бояться джойнов.
...
Рейтинг: 0 / 0
24.02.2020, 23:42
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование большого колличества связанных one-to-many таблиц
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=3&tid=1539872]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 34ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 235ms
total:  373ms
созд. / загр.: 373ms
x
x
Закрыть


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