22.06.2017, 11:25
|
|
Профессор
|
|
Регистрация: 17.06.2016
Сообщений: 509
|
|
|
laimas,
Встречный вопрос. Если держать все в одной таблице, не будет нагрузка на проц и на дыцк?
|
|
22.06.2017, 12:13
|
|
Аспирант
|
|
Регистрация: 28.05.2012
Сообщений: 85
|
|
|
Rasy, а нет ли более-менее похожих примеров изложенного регламента действий, особенно для "получаешь из бд по 50 картинок и рисуешь подчищая дом дерево от старых картинок присваивая атрибуту стайл отступ от начало страницы равный высоте выборки"?
|
|
22.06.2017, 12:17
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Rasy,
Процессору не ведомо, с чем ему придется разбираться, он всегда нагружен. А вот 30 тыс. записей для СУБД, это пустяк, она не посчитает это нагрузкой. Но вот если разбить на части, а работа с данными далеко не банальное "взять часть", то нагрузка на СУБД может возрасти и очень.
|
|
22.06.2017, 13:52
|
|
Аспирант
|
|
Регистрация: 28.05.2012
Сообщений: 85
|
|
Вроде подошел бы следующий пример на несколько мегабайт http://dabblet.com/gist/1528281 — но с кнопкой "Найти" и подгрузкой соответствующих запросу результатов. |
|
22.06.2017, 14:38
|
|
Профессор
|
|
Регистрация: 17.06.2016
Сообщений: 509
|
|
|
hdma, алгоритм написан. Дело за малым - написать код.
laimas,
Если обратиться к таблице 5/2017 и выбрать строки, то никакой нагрузки не будет. А если придется выбирать полностью все, то да, придется все таблицы джоинить. Если будет много джоинов, то и скажеться на произвоидетьности. Ты про это нагрузку на СУБД говоришь? Ну ок, пусть создает одну таблицу.
|
|
22.06.2017, 14:49
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Сообщение от Rasy
|
|
Если обратиться к таблице 5/2017 и выбрать строки, то никакой нагрузки не будет.
|
Думаю вам известно, что такое нормализация БД, основываясь на которой и проектируется база. То что вы предлагаете, создавать за каждый месяц свою таблицу, никак не вписывается в принципы нормализации. И да, "если придется выбирать полностью все, то да, придется все таблицы джоинить", это нагрузка, а ведь не только "все", но и "периоды", "новые", "владельцы", и многое другое, что обязательно потребует объединений и подзапросов. В таком подходе больше проигрываем, чем выигрываем. |
|
22.06.2017, 15:05
|
|
Профессор
|
|
Регистрация: 17.06.2016
Сообщений: 509
|
|
laimas,
Если опровергаешь, то предлагай.  Мне принципы не интересны, главное чтобы не было большой нагрузки на серв. То что плодить таблицы плохая идея я понял. Не надо повторять.
|
|
22.06.2017, 15:12
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Сообщение от Rasy
|
|
Если опровергаешь, то предлагай.
|
А чего предлагать, структуру базы? Вы считаете, что автор сам хоть понимает чего хочет, чтобы можно было определиться с предложением? Я думаю, что нет. )
Но то что это должна быть одна таблица, это "однозначно" - Жириновский ©. |
|
22.06.2017, 15:27
|
|
Профессор
|
|
Регистрация: 17.06.2016
Сообщений: 509
|
|
|
Сообщение от laimas
|
|
Вы считаете, что автор сам хоть понимает чего хочет, чтобы можно было определиться с предложением? Я думаю, что нет. )
|
Это бесспорно. Так и есть, но я предложил алгоритм в соответствии со своими догадками.
|
Сообщение от laimas
|
|
Но то что это должна быть одна таблица, это "однозначно" - Жириновский ©.
|
Давай только без сарказма. Раз уже социализируешься на форумах, то с такими высказываниями никто с тобой не захочет контрибьютить |
|
22.06.2017, 15:27
|
|
Аспирант
|
|
Регистрация: 28.05.2012
Сообщений: 85
|
|
|
Сообщение от laimas
|
|
Вы считаете, что автор сам хоть понимает чего хочет
|
Отлично понимает и даже не раз это пояснил)) Нужен пример кода, который будет искать по множеству подгружаемых строк с несколькими параметрами (как по ссылкам). Алгоритмы дело нехитрое, нужны примеры, потому что в том, что пока что нахожу — то одно есть, то второго нет)) |
|
|
|
