добрый вечер уважаемые
такая тема
есть таблицы
book_id
glava_id|book_id
paragraf_id|glava_id
все поля индексы -для быстроты поиска
корректирую условие задачи:
что бы не вводить людей в заблуждение
названия -параграфы, книги, и абзацы используются для понимания вложенности и группировки элементов!!!!!!!
количество строк в таблице параграфов будет выше 2000 000 000
есть идея добавить в эту таблицу поле book_id и осуществить по нему партиционированиние, это должно ускорить работу, но при этом приводит к денормализации бд, допустимо ли использовать такое решение, или есть иные варианты?
старое условие
и вроде бы это вполне правильная структура бд,и получается что бы найти параграфы конкретной книги достаточно создать запрос с 2 Left Join
и все вроде ничего, но вот есть параноя, что при очень большом количестве записей о параграфах понадобится добавить в последнюю табицу поле book_id для
разделения и как следствие более быстрой работы
и вот в чем возникает задача
по сути, и сейчас все меня будут ругать, приложение пишется под структру базы данных, т.е. решение на php лишьоболчка для данных в бд
т.е. если так изменить таблицу, то механизм приложения будет другим, и вот в чем вопрос как правильно спроектировать бд, что бы потом не переделывать логику приложения?
jetistyum
30.08.2016 - 11:42
Попробуй сделать View для выборки из join всех таблиц
и поработай с ним
jetistyum
ну а чем они помогут, здесь речь идет о оптимизации базы данных в условиях хранения большого количества информации, и как следствие торможение бд при выборках
Valick
30.08.2016 - 12:37
сильно смущает то, что вы номера глав и параграфов собрались автоинкрементить
_____________
Стимулятор ~yoomoney - 41001303250491
Valick
30.08.2016 - 12:39
| Цитата (hurt3 @ 30.08.2016 - 11:32) |
| здесь речь идет о оптимизации базы данных в условиях хранения большого количества информации |
убейте для начала медведя, прежде чем начинать делить его шкуру
_____________
Стимулятор ~yoomoney - 41001303250491
Valick
ну хорошо допустим, создадим по первому сценарию и через 3 года подойдем к тому что бд сильно тормозит, как переводить инфраструктуру и бизнес процессы такого приложения с такой бд к другому варианту? не проще ли изначально все продумать?
Valick
30.08.2016 - 13:34
| Цитата (hurt3 @ 30.08.2016 - 12:11) |
| не проще ли изначально все продумать? |
продумать нужно в обязательном порядке, но позвольте вас процитировать
| Цитата (hurt3 @ 30.08.2016 - 11:32) |
| здесь речь идет о оптимизации |
но вот беда, что бы продумывать нужна хорошая подготовка, а то что делаете вы - это называется "лепить горбатого к стенке"
вы даже моё сообщение
| Цитата (Valick @ 30.08.2016 - 11:37) |
| сильно смущает то, что вы номера глав и параграфов собрались автоинкрементить |
пропустили мимо ушей, а должно было ёкнуть, сильно так ёкнуть
_____________
Стимулятор ~yoomoney - 41001303250491
Valick
структура приведена общая для примера
но вот беда, что бы продумывать нужна хорошая подготовка
ну вот поэтой причине я и задаю вопрос на форуме
не нужно додумывать что либо задача поределна конкретно
дана структура для ее оптимизации при большом количестве данных потребуется ли добавлять роlительского id поле?
Valick
структура вложенности элементов уже продумана
выбрано наиболее просто решение вопрос лишь в том не понадобится ли при потом оптимизировать ее указанным способом для нормальной работы
Valick
30.08.2016 - 13:53
| Цитата (hurt3 @ 30.08.2016 - 12:42) |
структура вложенности элементов уже продумана
выбрано наиболее просто решение |
продумано на основании чего? я с удовольствием посмотрю на логическую цепочку умозаключений ведущую к такому решению
не люблю ругаться матом, но для красного словца
если сегодня не ёкнуло, то завтра ёбнет
может так понятнее
_____________
Стимулятор ~yoomoney - 41001303250491
jetistyum
30.08.2016 - 13:53
| Цитата (hurt3 @ 30.08.2016 - 11:32) |
jetistyum
ну а чем они помогут, здесь речь идет о оптимизации базы данных в условиях хранения большого количества информации, и как следствие торможение бд при выборках |
БД у тебя и так довольно оптимальна для хранения данных, а в качестве выборки данных как раз помогут View. По деталям не подскажу точно, не углублялся в изучении, однако выборка из view (select * from view_name) срабатывает в разы быстрее, чем запрос, по которому строится view.
Valick
30.08.2016 - 13:56
| Цитата (jetistyum @ 30.08.2016 - 12:53) |
| БД у тебя и так довольно оптимальна для хранения данных |
о как
назовите мне хоть один параграф который не принадлежит к главе и как следствие к самой книге
_____________
Стимулятор ~yoomoney - 41001303250491
S.Chushkin
30.08.2016 - 14:03
| Цитата (jetistyum @ 30.08.2016 - 13:53) |
| ..однако выборка из view (select * from view_name) срабатывает в разы быстрее, чем запрос, по которому строится view. |
Valick
бд, структурная еденица, параграфы названы для примера
S.Chushkin
30.08.2016 - 14:07
| Цитата (hurt3 @ 29.08.2016 - 23:37) |
| и все вроде ничего, но вот есть параноя, что при очень большом количестве записей... |
У Вас будут сотни миллионов записей?
Если нет - забудьте, всё будет работать достаточно быстро на Вашей структуре.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.