- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
приветствую коллеги.
подскажите, как лучше поступить.
есть задача сделать хранение большого количества товаров. структурировано.
каждый товар имеет порядка 50 свойств
каждое свойство имеет 3-10 вариаций (единиц измерения)
к примеру размеры. пользователь может завести в мм, см, мм итд
почти все они могут пересчитаны.
вопрос в хранении и поиске.
поиск может осуществляться по 1 единице измерения, а сохранено в другой.
база данных ожидается большая.
1. преобразовывать построчно не вариант
- долгий поиск. мало места в БД
2. хранить все варианты не выход (ибо при добавлении новой будет долгий пересчет)
- зато поиск очень быстрый
3. хранить 1 единицу (наименьшую) видится наиболее рационально
при поиск преобразовывать в неё, а в интерфейсе показывать разные варианты
-быстрый поиск, мало места
но есть характеристики, у которых нет формулы. к примеру, это стоимость. сохранили в CNY, а юзер ищет в usd. она меняется (тоже найти 1 валюту универсальную?)
как вообще поступить?
размер базы не критичен. есть шардирование.
критичен поиск. его скорость
критично добавление новых вариантов
Все кроме валют - приведением к стандартной единице измерения.
Валюты - если валют много, то тоже только приведением к стандартной единице. Если не очень много то предусмотреть внутренний компилятор поискового запроса учитывающий все валюты. Сам SQL-запрос будет длинным но работать медленнее он от этого не станет т.к. индекс по цене все равно скорее всего не будет задействован.
имхо 2ой вариант ок. лучше 1 пересчет при записи в БД, чем при каждом запросе
А в чём проблема пересчитывать цену при поиске?
Храните цену в одной (основной) валюте, и курсы других валют к основной.
При формировании запроса цену пересчитали в основной валюте.
Результаты поиска опять пересчитали в валюте, в которой ищут.
к примеру размеры. пользователь может завести в мм, см, мм итд
Возможно, имеет смысл привязывать свойства к категориям..
Вес ювелирки в каратах, вес приправ-сыпучек в граммах, вес гантелей в кигограммах и вес машин-прицепов в тоннах.. по сути - это разные веса (массы.. но не суть)..
Заведённые пользователем - пересчитывать к основной (хранить оба - "реально используемое" значение и значение "от пользователя") .. и при поиске "поисковое" занчение приводить к "основной" и искать по нему.. Результаты можно выводить удобно "для пользователя" (как вариант - уже при выводе характеристики пересчитывать её значение.. )
Вес ювелирки в каратах, вес приправ-сыпучек в граммах, вес гантелей в кигограммах и вес машин-прицепов в тоннах.. по сути - это разные веса (массы.. но не суть)..
Массу понятийно более удобно перевести всю в кгс·с²/м - так уж никто не запутается :)
Всё что можно хранят в одних единицах и для целей использования переводят в необходимые.