всем привет
извиняюсь за то что пропал на время с форума! виноват, каюсь!
вопрос. пишу приложение для страховой конторы, само по себе несложное, но через год в базе будет больше ста тысяч записей. где и как можно проверить как будут себя вести скрипты при таком огромном количестве записей?
еще вопрос: когда делаю запросы в базу использую JOINы? может стоит UNION использовать? что лучше? почем?
спасиб всем заранее
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Программирование → PHP для идиотов → нагрузка на базу данных
нагрузка на базу данных
Страницы: ← Следующая страница →
-
Сообщения:
217
Репутация:
N
Группа:
Адекваты
-
Сообщения:
11960
Репутация:
N
Группа:
в ухо
7 декабря 2010 г. 15:19, спустя 2 минуты 44 секунды
сто тысяч - это цифра непонятная
таблицы разные бываютвсе умрут, а я изумруд -
Сообщения:
217
Репутация:
N
Группа:
Адекваты
7 декабря 2010 г. 15:25, спустя 5 минут 58 секунд
как бы обьяснить то!
короче у меня там инфа о клиентах хранится!
всего 4 таблицы:customers, policies, transactions, accounting
в customers колонки: id, name, phone, address, city, zip, state
в policies колонки: id, customer_id, policy_number, policy_type, company_name, start_date, end_date
в transactions колонки: id, policy_id, accounting_id, agent_id, date, transaction_type
в accounting колонки: id, tasf, taobf, tsandbf, collecte_1, collected_2
все это я вытягиваю из базы JOINом.
вот =( может поможет структура! -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
-
Сообщения:
3244
Репутация:
N
Группа:
Джедаи
7 декабря 2010 г. 15:59, спустя 31 минуту 28 секунд
где и как можно проверить как будут себя вести скрипты при таком огромном количестве записей?
нормально будут себя вести, расслабься. индексов нахуячишь и океще вопрос: когда делаю запросы в базу использую JOINы? может стоит UNION использовать? что лучше? почем?
explain жене всё полезно, что в swap полезло -
Сообщения:
304
Репутация:
N
Группа:
Кто попало
7 декабря 2010 г. 23:51, спустя 7 часов 51 минуту 48 секунд
union будет медленнее, а join это основной оператор 3 нормальной формы так что тормозить не будет. Да хоть union, хоть join в принципе тормозить не должно - количество записей вроде как на нагрузку не сильно влияет, тут еще правда от типа таблиц зависитСпустя 60 сек.хуету пишу какую-тоСпустя 8 сек.ну и похуйСпустя 9 сек.извините за мат -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
8 декабря 2010 г. 0:05, спустя 14 минут 13 секунд
union будет медленнее, а join это основной оператор 3 нормальной формы так что тормозить не будет
ну и где такую хуету ты вычитал? больше пробуй, меньше говна всякого читайСпустя 38 сек.Да хоть union, хоть join в принципе тормозить не должно - количество записей вроде как на нагрузку не сильно влияет, тут еще правда от типа таблиц зависит
хуету пишу какую-то
прав на все 100 евроСапожник без сапог -
Сообщения:
4306
Репутация:
N
Группа:
в ухо
8 декабря 2010 г. 19:45, спустя 19 часов 39 минут 41 секунду
Все это реально хуета. Тормозят не джоины, юнионы, хуюнионы, количество записей и прочие общие понятия.
union будет медленнее, а join это основной оператор 3 нормальной формы так что тормозить не будет. Да хоть union, хоть join в принципе тормозить не должно - количество записей вроде как на нагрузку не сильно влияет, тут еще правда от типа таблиц зависитСпустя 60 сек.хуету пишу какую-то
Тормозят запросы у которых хуевый "план запроса". -
Сообщения:
3131
Репутация:
N
Группа:
в ухо
8 декабря 2010 г. 22:30, спустя 2 часа 45 минут 20 секунд
Mars, JOIN начнёт тормозить первым и так что пиздец. -
Сообщения:
5210
Репутация:
N
Группа:
Джедаи
9 декабря 2010 г. 1:55, спустя 3 часа 25 минут 14 секунд
да, пиздец… сначала спасают индексы, потом кеширование, потом мапперы… -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
9 декабря 2010 г. 8:49, спустя 6 часов 53 минуты 59 секунд
поподробнее про слово, про которое ты выебнулся? :)
да, пиздец… сначала спасают индексы, потом кеширование, потом мапперы…Сапожник без сапог -
Сообщения:
5210
Репутация:
N
Группа:
Джедаи
9 декабря 2010 г. 10:38, спустя 1 час 48 минут 46 секунд
надо будет скрыть по максимому источник данных и связи между элементами, вдруг прийдется переделывать таблицы или вставлят различные уровни и использовать разные инструменты кешировани… это всё необходимо скрыть в маппере(ах), чтобы код был эффективно разделён на работу и источником и работу с логикой приложения. Например надо вывести на страницу всех кастомеров с полисами у которых start_date равна какой-то. Не факт что тут надо один запрос или два или вообще данные выбирать из представления надо будет со временем, ведь в любом случае обращение к БД будут, или там часть данных их кеша, часть из БД. Для это мы можем иметь соответствующий метод в маппере, который скроет всю суету с нагрузкой:
<?php
public function someAction()
{
$mapper = new Mapper();
$date = $this->getRequest()->get('date', time());
$this->view->data = $mapper->findCustomersWithPoliciesForDate($date);
} -
Сообщения:
5210
Репутация:
N
Группа:
Джедаи
10 декабря 2010 г. 0:11, спустя 13 часов 33 минуты 7 секунд
ну чё там?Спустя 11 сек.помогли мои супер советы?
-
Сообщения:
1159
Репутация:
N
Группа:
Кто попало
10 декабря 2010 г. 0:21, спустя 10 минут 3 секунды
я тут копался в движке и раскопал охуенную вещь. не делайте так.
короче категория в item прописана так ;10; или так ;10;12;
а знаете как выбираются все item категории?
мегаахуенно - LIKE '%;$id;%'
про процедурный код с отсутствием глобальных переменных не упоминаю..Спустя 61 сек.и админка закрыта Ioncube. было бы что слизать.. -
Сообщения:
5210
Репутация:
N
Группа:
Джедаи
10 декабря 2010 г. 0:27, спустя 5 минут 24 секунды
Faster, по моему в мускуле это можно делать без like со списком, который через запятую in_set или ка кто так…
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!