- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Не думал что когда-либо создам такую тему =) Впервые за 2 года от хостера пришло письмо что движок слишком сильно нагружает их сервер, а я не вижу никакого способа его улучшить.
За хорошее решение этой задачи я готов дать немного денег. Скажем 500-1000 рублей.
Сформулирую задачу:
есть таблицы (id везде primary key), структура базы данных не обсуждается и изменению не подлежит
groups { #id, name } - группы товаров
products {#id, #type, name, price,#group_id, order, show}, group_id внешний ключ для groups.id (связь many-to-one), #type внешний для fields.type (many-to-one)
fields {#id,#type,name, order} #type группировочный ключ, т.е. неуникальный в рамках таблицы
values {#id,#field_id, #product_id, value } #field_id внешний ключ для fields.id (many-to-one), а #product_id (many-to-one) для products.id
Эти три образуют чуть измененную схему Entity-Attribute-Value
images {#id, path, desc, #product_id, order } #product_id внешний ключ для products.id, тоже many-to-one
Количество записей в этих таблицах в типичном сайте достигает примерно таких величин:
groups - 50-200
products 200-5000
fields 20-30
values 2000-25000
images 200-10000
Поле order везде используется для сортировки
Требуется заджойнить все эти таблицы с приоритетом на products, все джойны левые, т.е. получить список всех продуктов со всеми относящимися к нему полями и значениями (если таковые имеются), с именем группы, к которой он относится и с ОДНОЙ картинкой (Если таковые имеются). Правила такие:
* картинка выбирается как самая первая, относящаяся к данному продукту. т.е. images.product_id=product.id и с самым маленьким images.order (ASC LIMIT 1 по факту)
* товары сортируются по product.order
* выводятся только те товары, у которых show>0
* поля в рамках одного товара сортируются по fields.order всегда ASC
* в запросе так же присутствуют фильтры, т.е. выбираются только те товары, где поля или группы или тип удовлетворяют определенным критериям. Т.е. фильтр сделать после джойнов не вариант, т.к. если хотя бы одно из полей не подошло по значению, то выкинуть надо все строчки с этим product.id
Текущий запрос большой и страшный. Предложите что-нибудь. Вероятно вынести часть обработки в сторону php имеет смысл, если это ускорит работу.
дай дапмы нужных таблиц + запрос который сейчас хреново работает и получишь "красоту" (ну если все получится :) )
можно в личку чтобы не шарить
Все больше подтверждений тому, что использование баз для тех целей, где это ненужно, ведет только к головной боле и нагрузки на сервак.
PS я не злорадствую. И искренне сожалею, что в этом не могу помочь.
T.R.O.N, а что нужно для интернет магазина? давно заметил вашу тягу к файловым базам, но ведь преимущества этого метода проявляются на довольно редких задачах
T.R.O.N, а что нужно для интернет магазина? давно заметил вашу тягу к файловым базам, но ведь преимущества этого метода проявляются на довольно редких задачах
заметил что чаще, чем плюсы бд перед фс на стандартных задачах.
давно заметил вашу тягу к файловым базам, но ведь преимущества этого метода проявляются на довольно редких задачах
серьезные преимущества фалов перед мускулом при условии, что суммарный объем хранимых данных не превышает 3.5-4Мб (имеется ввиду именно тексты) (мало верю что кто-то разумный будет хранить картинки в БД). Если перевести на язык баз - это, порядка 3500 записей с хорошими описаниями.
Дальше, безусловно - есть смысл переходить на классические БД. Ну и конечно не стараться все что можно воткнуть в один запрос к базе. Ведь очень часто, несколько запросов последовательно исполняются быстрее чем один но более сложный.
T.R.O.N, bearman, я не понял, а почему акцент на интернет-магазин проигнорирован ? структура напоминает типичный магазин.
Я бы сказал, что с простыми базами даже неважно какой метод хранения данных использовать. SQL здесь все равно удобнее из-за универсальности.
я вообще жду дампы от единомышленника :)
устраивать холивар по теме файлов глупо, мы уже с троном это делали и не раз даже кажется))
ТС ты куда пропал? папочка хочет файлеги =)))
щас, я пока экспериментирую. Выберу наилучший вариант а потом уже представлю на суд.
Если надобность ещё есть - кинь в личку структуру с данными - поковыряю.