имеет ли смысл добавить в
paragraf{
id
glava_id
title
}

book_id

paragraf{
id
glava_id
title
book_id
}

Что касается партицирования - читал когда-то, но не пользовался на практике, тут не скажу ничего.

jetistyum

все верно пишите,молодец -правильно выделил суть проблемы, добавление спец поля с родителем родителя -книга, денормализует структуру бд!

но

в этом и заключается вопрос можно ли в данном случае пожервтовать нормальной структурой для того что бы бд работала быстрее

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

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



Valick

вы не дело пишите перечитайте ветку с самого начала

hurt3

View придется пересоздавать если вы измените в исходных таблицах структуру (названия полей или их тип) либо поменяется алгоритм создания view. Если поля будут просто добавляться - view не изменится.
(!!! Я говорю именно о изменениях в стурукутре таблиц, а не о вставке новых записей в существующие)

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

Партицирование добавлять или нет - зависит от объема данных. Если хотите - добавляйте, это даст при огромном кол-ве данных доп. оптимизацию, не зависимо есть view или нет.

О каком кол-ве записей мы ведем речь? Ведь оптимизация нужна там, где начинаются затыки. А оптимизация может быть разной, как создание индексов, так и установка нового железа, так и выбор лучшего движка таблиц, или движка бд.

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

Объем строк если прикинуть чисто теоретически +-
2 000 000 000

но этот объем должен расти, если выстроить логику с завязкой на одних ключах, сдается мне искать будет долго ,м?

jetistyum

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

Поэтому получается что виевсы решают лишь 1 задачу

ну конечно еще действие добавление

Еще раз повторюсь книги параграфы и главы приведены лишь как пример для понимания логической структуры

jetistyum

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

jetistyum

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

ив ц елом хотелось бы услышать мнение так допустимо делать? может быть еще 3ий вариант какой есть?

jetistyum
спасибо, как думаешь объединение всех данных в одну таблицу, как Valick писал -не прокатит, слишком много информации будет дублироваться, м?