Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование большого колличества связанных one-to-many таблиц / 19 сообщений из 19, страница 1 из 1
08.02.2020, 18:52
    #39924252
cherepica
cherepica
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование большого колличества связанных one-to-many таблиц
Всем привет! Есть пример вот с такой структурой бд: 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, 19:05
    #39924254
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование большого колличества связанных one-to-many таблиц
cherepicaВопрос в том, есть ли какие-то обходные решения двух описанных выше проблем?

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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


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


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