Вход • Регистрация

Всего найдено: 826

  • 30 октября 2014 г.
  • Василий, а зачем вы это сюда пишете? Если ошибка имеет место быть, то пишите в тех. поддержку или в багтрекер https://user.diafan.ru/wishlist/ так эта информация сразу попадет к разработчикам. А форум это не официальная поддержка и ваше сообщение тут может висеть не увиденным хоть до скончания времен.
  •
  • 27 октября 2014 г.
  • Да в сущности тут пока и продавать нечего
    Я вот лично не понимаю какова вообще задача этого модуля, как он вообще позиционируется? Как что? И для кого?
  •
  • 28 октября 2014 г.
  • Ну да не хочу Вы же его бесплатно выкладывали на форуме, тему потом удалили, а я его скачал, посмотрел, но за не надобностью тоже удалил. Потому что создать таблицы в БД я без проблем могу и в phpMyadmin

    Вот если бы вы его позиционировали как CCK (конструктор контента) и развивали бы в этом направлении, то это было бы еще может и интересно, потому что в Diafan полноценного CCK пока нет.

    А любой программист, если он действительно программист, структуру БД без проблем наваяет и без этого чудо модуля.
  •
  • 28 октября 2014 г.
  • Цитата
    За каждый строку кода человек тратит время. А время - деньги.

    Я вот на ответы вам, да и вообще на этом форуме (причем часто не бесполезные) тоже трачу время, но денег мне почему то за это никто не платит.

    Цитата
    А модуль нужен тем как я предполагаю

    То есть вы сначала его делаете, а потом начинаете предполагать для чего вы его сделали интересная концепция разработки продукта.
  •
  • 25 октября 2014 г.
  • Похоже что только путем написания своего шаблонного тега.

    Давно уже хочу, но никак руки не доходят, в раздел пожелания сделать предложение по шаблонному тегу который бы выводил всю структуру категорий интернет магазина. Может быть вы это сделаете ) Так как решения из коробки нет.
  •
  • 27 октября 2014 г.
  • Ну категории в магазине добавляются не каждый день, к тому же добавить категорию в меню не так и сложно - просто при создании категории поставить галочку не забыть.

    Как выводить количество товаров в меню я подробно описывал в этой теме: http://user.diafan.ru/forum/show1806/#14973
  •
  • 24 октября 2014 г. , редакция: 1414143974
  • Да, тоже сталкивался с этой проблемой и как раз тоже сайт был по недвижимости. Поиск по характеристикам спроектирован изначально не самым лучшим образом, поэтому сейчас когда в проектах необходимо организовать сложный фильтр, приходиться отказываться от Диафан в пользу других CMS.
  •
  • 24 октября 2014 г.
  • Пока не решали никак, судя по статистике использования данной формы, большим количеством характеристик при составлении запроса никто почти из посетителей сайта не пользуется, так что пока решили оставить как есть. Если ситуация измениться, то будем что то думать.
  •
  • 24 октября 2014 г.
  • Цитата
    Есть идея заменить часть характеристик на записи в таблице shop и сортировать напрямую по ней, тогда SQL должен получится легче, но занятие это уж больно долгое.
    - по итогу это получается самое правильное решения, для снижения ресурсоемкости фильтрации. Ну либо надо больше мощных серверов.

    Дело в том, что для хранения характеристик товара используется так называемая EAV-модель (Entity–attribute–value - сущность-атрибут-значение).

    Обычная реляционная модель данных подразумевает, что для каждой сущности заводится отдельная таблица, и для каждого атрибута в этой таблице создается столбец (в случае с магазином нам надо было бы в таблице "товар" (это сущность) создавать столбец для каждой характеристики (это атрибут) - "размер", "цвет" и т.д.) В EAV-модели все характеристики всех сущностей хранятся в одной таблице из трех столбцов - в первом ID (номер) сущности, во втором номер атрибута, в третьем - его значение. Получается "длинная и худая таблица". При фильтрации, когда мы хотим получить сущность (товар) с определенным атрибутом (характеристикой), то мы объединяем две таблицы - таблицу с товарами и EAV-таблицу, и задаем условие выбора на значение характеристики. Если же нам надо фильтровать по двум характеристикам, мы еще раз добавляем EAV-таблицу в наше объединение, и также задаем для нее условие выбора. Сколько характеристик участвует в выборке - столько раз EAV-таблица и будет добавлена в выборку. Проблема в том, что сложность запроса растет в геометрической прогрессии с каждой добавленной таблицей. Если у нас в таблице 100 строк, то при объединении двух таблиц по 100 строк их будет уже 10000, а при объединении трех - 1000000. Прикиньте, сколько строк в нашей "длинной и худой" таблице, и что случится, если мы фильтруем по пяти-семи характеристикам (и про таблицу с самими товарами не забудьте - она тоже участвует в запросе). Причем, если в других случаях ресурсоемкого запроса мы можем рассчитывать на кэш, поиск и фильтрацию кэшировать по понятным причинам не получится.
  •
  • 26 октября 2014 г.
  • Цитата
    И возникает вопрос сильно ли помогут при такой проблеме индексы и я правильно понимаю что индексировать следует SHOP_PARAM_ELEMENT и SHOP?

    Добавление индексов вам не поможет, потому что они уже добавлены. Таблица SHOP объединяется с таблицей SHOP_PARAM_ELEMENT с условием shop.id=shop_param_element.element_id, а оба эти поля индексы уже имеют. Если хотите попробовать заняться оптимизацией, то в shop.model в методе list_search_query допишите перед запросом DEV, чтобы увидеть запрос, выполняющийся при поиске, в браузере, а оттуда уже скопируйте его в phpMyAdmin, допишите перед ним EXPLAIN и смотрите, как идет выборка из таблиц, с какими индексами, и прочие подробности. Но вряд ли это спасет отца русской демократии.

    Цитата
    С простыми типами данных(числа, галочки, строки) всё просто. Вопрос как реализовать селекты и мультиселекты? Ведь именно они дают наибольшую нагрузку БД.

    Нет, нагрузку они дают точно такую же, как простые типы. Например, пользователю на сайте предлагается ввести строку, он вводит foo, и потом в запросе накладывается условие value='foo'. В случае с селектом ему будет показан список значений, каждое из которых имеет идентификатор, который и будет отправлен на сервер участвовать в запросе. Скажем, элементы списка 1:foo, 2:bar, пользователь выбирает первое значение, на сервер отправляется 1, в запросе появляется value=1. Ровно то же самое по сути. Кстати, если вы воспользовались первым советом и добавили перед запросом DEV, вы увидите значения, попадающие в запрос. Единственная дополнительная нагрузка - сформировать список и показать пользователю, но это сущие пустяки.
  •
  • 26 октября 2014 г.
  • Цитата
    Ну и возникает вопрос. Как выводить select? В документации не нашёл примеров.
    А хранить думаю можно в виде ENUM.

    Надо будет в shop.admin для каждого поля с селектом делать функцию edit_variable_названиеполя, и в ней формировать html для списка, а значения брать или из таблицы в бд, или руками перечислять, если хотите использовать enum
Показывать по:
... 15 16 17 18 19 20 21 22 23 24 ...

Новости

  • Вышла очередная сборка DIAFAN.CMS 7.2.2
  • 18 июня
  • В сборке большое обновление demo-шаблона, дополнительная защита от спама, улучшение YML-импорта и еще много важного и интересного.
  • Не пропустите сборку DIAFAN.CMS 7.1.4
  • 24 апреля
  • В новой сборке совершили революцию в структурировании кастомизированной информации в шаблонах, добавили авторегистрацию пользователей, усовершенствовали защиту от спама, актуализировали накопительную скидку, а также улучшили производительность и стабильность работы системы.
  • Сборка DIAFAN.CMS 7.1.3
  • 12 января
  • После выхода сборки 7.1 мы выпустили уже три патча, в каждом из которых улучшаем административную часть сайта. Сборка DIAFAN.CMS 7.1.3 уже доступна к установке. 
Все новости

Форум

Перейти на форум