powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Выбор структуры!!!
23 сообщений из 23, страница 1 из 1
Выбор структуры!!!
    #37086425
student42
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте! Недавно был на собеседовании (на позицию разработчика Oracle) в одной ИТ конторе. Собеседование у них было достаточно интересное (впервые был с таким подходом). Суть заключалась в том что тебе предлагают 30 вопросов и варианты ответа. но при выборе ответа необходимо сказать почему. Был там один вопрос мне он показался интересным...думаю относится к проектированию БД.

Вопрос (привожу описание максимально точно): Вам поставлена задача разработать иерархическую структуру учета объектов системы ( объем вновь вводимых объектов в систему = 10000 за 1 рабочий день). на текущий момент количество зарегистрированных объектов системе = 7 000 000. Какая структура будет наиболее выгодна, т.е. позволит оптимально извлеч информацию об объекте и о всех его предках?

Придложено 2 варианта ....прям картинками!

Не смог выбрать и аргументировать.....думаю надо почитать книжек..предлагаю подумать ВАМ! очень интересно какой вариант выберите ВЫ! А или Б!
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37086427
student42
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
уточнение: ОПТИМАЛЬНО ИЗВЛЕЧ.......т.е. наиболее быстро!
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37086649
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
student42,

может, я не понял нотации, но в варианте Б у второй таблицы 2 PK... это как? И зачем?

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

По сабжу - я с Ораклом не работал, но думаю так: если вам только ид-шники надо, то никакой разницы. А если все св-ва, то:
в 1 варианте рекурсивный запрос выбирает из таблицы сразу всё - ид,имя, описание;

во 2 варианте сначала рек.запрос ко 2-й таблице, + его результаты джойнить с 1-й таблицей, чтоб получить имя+описание - итого как будто бы должно быть медленнее.

Но если я неправ, то меня уж тут поправят, будьте уверены :)
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37086772
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglirможет, я не понял нотации, но в варианте Б у второй таблицы 2 PK... это как? И зачем?это PK из двух полей.

А выбор схемы данных зависит, в первую очередь, от того, какая именно иерархия используется.
Если возможно наличие двух и более вышестоящих объектов (overlapping hierarchy), то нужна вторая схема.
Если нет - достаточно и первой. Можно использовать и вторую, но ее придется модифицировать, сократив PK до поля ОБЪЕКТ_ИД.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37086837
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft, действительно, как же я сам не понял про PK :) Но вопрос у ТСа был немного другой - сферический в вакууме запрос на выборку к какой из схем будет работать быстрее.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37086899
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
student42, постановка задачи достаточно расплывчата: оптимально - это по времени? по количеству чтений? а индексы дополнительные типа на А(id, parent_id) есть? а информация про родителей требуется полная или только перечень идентификаторов?
а нам требуется оптимизировать только этот запрос или работу системы в целом? а какого рода ещё запросы и в каких объёмах предполагаются?

идеальные решения в жизни не встречаются :)

теперь по делу:
нужно учитывать один маленький нюанс - когда ты пытаешься выбрать поле записи:
1) если это поле включено в индекс, который сервер уже использует - сервер в запись не полезет,
2) если поля в индексе нет - сервер будет читать запись, при этом будет читаться вся запись. для примера в варианте A даже если тебе нужно только поле parent_id, будут прочитаны все ~5 КБ записи.

НО для варианта А можно создать дополнительный индекс на 2 поля (id, parent_id) и тогда сервер для запросе ид родителей будет читать только данные индекса.

есть подозрения, что правильного ответа нет - важны только твои рассуждения...
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087017
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
student42Недавно был на собеседовании (на позицию разработчика Oracle) в одной ИТ конторе. ... Вам поставлена задача разработать иерархическую структуру учета объектов системы ( объем вновь вводимых объектов в систему = 10000 за 1 рабочий день). на текущий момент количество зарегистрированных объектов системе = 7 000 000. Какая структура будет наиболее выгодна, т.е. позволит оптимально извлечь информацию об объекте и о всех его предках?

Придложено 2 варианта ....прям картинками!
Слышал мнение, что стандартный именно в Oracle способ построения иерархии - CONNECT BY - на озвученных работает плохо, т.е. тормозит. Не скажу за второй предложенный вариант, но есть способы хранения дерева, требующие хранения дополнительной информации и ее обновления при появлении новых узлов, зато работающих на больших таблицах. Случайно речь не шла о хранилище, к которое эти самые 10000 записей загружаются единовременно и потом не меняются?
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087214
Фотография pilot911
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
второй вариант самый лучший - самое простое перемещение веток дерева, вставка новых веток, удаление и тп
плюс возможность иметь нескольких родителей для одной ветки
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087226
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pilot911второй вариант самый лучший - самое простое перемещение веток дерева, вставка новых веток, удаление и тп

??
а в первой схеме, ну "жутко сложно" переместить "и тп"
update T set parent_id=2 where id=3
pilot911плюс возможность иметь нескольких родителей для одной ветки
это уже граф будет, а не "Вам поставлена задача разработать иерархическую структуру"
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087338
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
student42,

Вообще-то надо ни то, и ни другое, а гибрид. И то, и другое, вместе.
Дерево хранится в виде варианта А, а результат транзитивного замыкания --
в виде варианта Б.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087339
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> может, я не понял нотации, но в варианте Б у второй таблицы 2 PK... это как?

Один PK из двух полей.

> И зачем?

Чтобы был PK, в каждой таблице должен быть PK.


> Во втором варианте надо ещё на 2 таблицу накладывать ограничения, чтобы нельзя было одному объекту приписать 2+ родителей

Там не один родитель хранится, а ВСЕ. Как непосредственный, так и опосредованные.

Но либо я что-то не понимаю в задании, либо они неверно дали условие.
Только вариантом Б хранить дерево нельзя, туда как минимум нужно добавить
поле distance, расстояние между узлами в дереве.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087559
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я тоже думау, что если иерархия, то второй вариант нуждается в дополнитьельнвых ограничениях целостности. Посоку иначе там возможно более одного предка у одного потомка, что нарушает иерархия. Еслм же у одного потомка может быть ненсколько предков, то первая схема структурно не подходит. Т.е. в таком виде схемы логически не эквивалентны: не одно и то же.
В случае иерархии первая,все еще кажется, луче.
Мало того, что во второй ОЦ не хватает, а для реализции понадобится триггер, скорее всего, так еще:
1. и таперь кол-во ОЦ во втором случае больше (два внешних ключа против одного), а их при вставках нужно проверять.
2. объем выглядит болше: пять колонок протв четыре, две таблы против одной. В общем случае болеков считывать больше.
Что касается медленности CONNECT BY, так он буит во всех запросах показывающих всех потомков или предков. Но во втором еще и соединение, что дорого стоит.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087568
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoболее одного предка у одного потомка, что нарушает иерархияНе нарушает. В своем посте выше я специально термин привел для дальнейшего гугления.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087571
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотя мож тоже не до конца понял идею второй схемы и там предполагается всез предков хранть. Тада CONNECT BY не нужен. Но тада объем может возрасти.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087581
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftvadiminfoболее одного предка у одного потомка, что нарушает иерархияНе нарушает. В своем посте выше я специально термин привел для дальнейшего гугления.
ну во второй можно написать
<1,2>
<1,3>?
Если это истолковывается как 2 и 3 непосредственные предки 1, то, возможно, есть екоея нарушения иерархии.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37087590
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
student42... оптимально извлеч информацию об объекте и о всех его предках?
Что понимается под оптимально и какую именно информацию?
Если брать общепринятые понятия то вариант А.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37088328
Злой Бобрstudent42... оптимально извлеч информацию об объекте и о всех его предках?
Что понимается под оптимально и какую именно информацию?
Если брать общепринятые понятия то вариант А.
student42уточнение: ОПТИМАЛЬНО ИЗВЛЕЧ.......т.е. наиболее быстро!
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37088983
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тогда вариант А.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37089411
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
student42Не смог выбрать и аргументировать.....думаю надо почитать книжек..предлагаю подумать ВАМ! очень интересно какой вариант выберите ВЫ! А или Б!
Именно для задачи "извлечь информацию об объекте и его предках", если рассматривать её как одиночный запрос, при разумной глубине дерева обе структуры в общем отработают быстро, вторая будет избыточной и более медленной.

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

Для некоторых запросов первая структура просто умрёт, поскольку будет вынуждена ворочать примерно 30Гб данных. Вторая структура в той же ситуации в принципе сможет быстро построить дерево и потом подгрузить только нужные "широкие" данные. Однако, для этого в деревянной таблице кроме иерархии следовало бы ожидать наличия критериев фильтрации. Также в принципе такая ситуация может быть при запросе полной развёртки дерева с /*+ FIRST_ROWS */.

В любом случае, индекс по (id, parent_id) справится с задачей оптимизации лучше, нежели эта отдельная таблица. То есть при текущей структуре вторая схема может быть лучше, если разрешено создавать индексы, то пожалуй примера, где бы стоило применить вторую, я не придумаю.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37089737
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Очень многие задачи поиска по дереву и работы с его веткаим и узлами удобно решать если для каждого узла хранить его полную адресную строку из ID всех узлов до самого верха, разделенных каким-либо символом. Типа '1.12.34.5'
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37089754
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-Любитель удобно решать если для каждого узла хранить его полную адресную строку
Замечательный метод для дерева из нескольких десятков или сотен узлов.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37089761
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ваше замечание справедливо. Еще один минус - его надо как-то обновлять и поддерживать при перестроении веток.

На миллионах записей не гонял. Пользовался только на десятках тысяч. Уж больно привлекательно вместо длинных SQL конструкций написать один LIKE.
...
Рейтинг: 0 / 0
Выбор структуры!!!
    #37090791
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для выборки данных вариант Б плох тем, что нужно соединять две большие таблицы, потом строить иерархическое соединение/сортировку. А в былые времена иерархические запросы в оракле только по одной таблице работали. В общем много лишних движений, много затрат времени.

Вариант А позволяет сразу выполнять иерархический запрос.

Наличие индекса большой роли не играет, оракл умеет и без индекса быстро упорядочивать иерархически подчинёные записи - грузит их в память и сортирует хитрым способом.
...
Рейтинг: 0 / 0
23 сообщений из 23, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Выбор структуры!!!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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