Избыточность в характеристиках в типе boolean

Интернет-магазины Пожелания и обратная связь
1

Здравствуйте. Прошу учесть очень важный момент который может существенно оптимизировать работу характеристик. С удивлением было обнаружено что boolean характеристики в статусе False хранятся в базе. Проконсультировался с рядом разработчиков никто не смог мне аргументировать зачем это нужно. Привожу пример:

  • 200 характеристик с возможностью отмечать характеристику, припустим “пульт управления”.
  • 10 000 товаров, из которых только 100 имеют вообще такую возможность иметь “пульт управления”, остальные 9900 просто хранят статус характеристики в False

Вроде бы как не очень страшно если это нужно вывести в карточке товара, но для фильтров это уже достаточно тяжелая выборка.

Сразу хочу отметить что варианты типа “нужно отметить что такой опции нету” не принимаются так как тогда должно быть 3 варианта None | True | False то есть это уже селект но ни разу не буль. Как пример не вижу такой возможности отметить товары без “пульта управления” так как вы не можете выбрать что такая опция отсутствует.

Исходя из этого я могу предположить что громадное количество опций просто болтаются в статусе False создавая огромные очереди при формировании тех же фильтров. Я уже молчу о всякого рода обновления при импорте и тд. тп. В общем на лицо явная избыточность которая создает крупные проблемы в работе характеристик.

5 лайков
2

более того, скажу, что именно так это и работает! У характеристики типа boolean у нас именно ТРИ значения! Сам с этим столкнулся при поиске или отборе для промоакции: если используется значение Y - true - оно устанавливается при установке флажка характеристики, если флажок был снят - то в значении стоит N - false. Но если значение не устанавливалось - оно пустое (нет записи в таблице) и соответственно поиск не находит товар выбери ты значение характеристики Y или N

Правильно было бы при создании характеристики выбрать значение по умолчанию (Y/N), и тогда отсутствие строки в базе для товара означало бы значение по умолчанию, наличие строки - отрицание значения по умолчанию.

3

Ну так штатная галочка в админке для буля сохраняет только статус Y/N , то есть статус отключенного гранится как N, я понимаю что те кто в курсе могут это оптимизировать но врядли особо кто-то вникает.

4

Да, статус отключенного хранится как N, но… все дело именно в том, что если ты еще не задавал значения для характеристики в конкретном товаре - для него нет записи в таблице, и когда я в промоакции выбираю в качестве условия: промо применяется только к товарам у которых эта характеристика выключена - к этому моему товару промоакция не применится! Вот в чем беда…

5

А это собственно и есть уже следствие того что не корректно проработана логика. Вашу проблему можно хотя бы логично понять и решить, но пока более ходовая скажем так проблема, в базах накапливается громадное количество не нужных записей, я уже молчу о крупных каталогах или маркетплейсах с сотнями и тысячами характеристик, мне трудно представить что там тогда творится. Выход один - хранить только True значения а по дефолту параметр имеет False. И что главное проблема сильно масштабируется с каждой новой характеристикой.

4 лайка
6

Так оно и есть, в маркетплейсе с характеристиками полный капец.

1 лайк
7

Юра, все там норм, просто при больших обьемах не нужно базу трогать, есть же более удобный эластик и сфинкс, если магазин дорос до большой посещалки или обьемов - ну найдет он 300-500к что бы реализовать свои хотелки.

8

то есть…
например любимые Бендером стулья. Есть просто стулья, а есть комплекты из 2, 3, 12-и… Завожу характеристику комплект типа bool. Там где из по 2-3 итп - ставлю галочку. В одном стуле X который не комплект а сам по себе ошибся и случайно поставил галочку, заметил ошибку и снял галочку.
Иду в промоакции, создаю промо для каталога:
Условия: в катагории Стулья, Характеристика Комплект = Нет
Бонус - скидка 90%

Заходит покупатель, и видит 90% скидки только на том товаре, на котором я сначала ошибочно поставил характеристику, а потом снял, то есть промо выходит в итоге не на все одиночные стулья, а только на Х.

То есть это “всё там норм”?

Все верно вы скажете, я могу ведь в условии поставить Характеристика Комплект НЕ РАВНО Да
Но есть ведь и сложные условия, когда такой изподвыверт не получится. И кроме того, система, которая позволяет совершать действия приводящие к неопределенным результатам при этом никак это не отслеживая…

Да в конце концов, почему я должен тратить хренову тучу времени, выискивая ту комбинацию условий, при которых акция, возможно!, заработает именно так как мне надо?

Высказанное здесь предложение - наипростейшее решение вопроса, не надо ничего отслеживать, просто если ставится галочка - пишется строка в базу со значением Y, снимается галочка - не надо писать N, надо просто удалить саму запись, и тогда поиск по условию характеристика равна N - будет искать товары для которых просто нет записи для этой характеристики

1 лайк
9

Те же аргументы, только в профиль. Суть остается та же, при создании характеристики не устанавливается значение по умолчанию. Просто Вы предлагаете для всех установить N (приравнивание к NULL или N не принципиально). Но это тоже может вызывать ошибки. Ведь в таком случае акция применится к товару с комплектом (в Вашем примере) до которого просто не дошли руки проставить характеристику, что тоже не совсем корректно.

Думаю, правильным решением будет всё же использовать 3 варианта Y, N, NULL ( можно приравнять к отсутствию записи). Но при создании характеристики позволить указывать значение по умолчанию, которое будет применено ко всем товарам (которым доступна эта характеристика) сразу при создании. Так функционал получится наиболее широкий и корректный. Вы сможете проставить для всех N и получить свою акцию, а кто-то сможет постепенно заполнять товары, добавляя их в эту самую акцию (или фильтр).

10

О чем я собственно сразу и написал выше :slight_smile:

А здесь скорее некорректно - выставлять в продажу незаполненный товар, и все претензии уже к контенщику, а движок как раз отрабатывает свою задачу по полной

1 лайк