Никто не заставляет покупать убитое УГ неактуальных стандартов. Вел выезжая из магазина сразу теряет 30% стоимости, как минимум на этом уже можно сэкономить. Можно взять вел с небольшим пробегом, но классом повыше. Я так взял свои велы, они стоили около 600-700$ в магазине, мне при продаже вместе с документами отдали чек, в котором написана сумма, что их по скидке купили за 540$ примерно. Я заплатил около 250$, на одном пробег около 2к км., на другом вообще смешной, даже наклейки на спицах были. За эти же деньги в магазине я бы взял какой-то мусор на Shimano SIS. Тот рокрайдер что вы скинули, он на актуальных стандартах? Не вижу там буст и конусную рулевую.
Вот например вариант из белгорода: https://www.avito.ru/belgorod/velosipedy/velosiped_ghost_se_2920_sostoyanie_novogo_probeg_1896844728
Вся на веска на уровень выше, доки есть, пробег судя по описанию не большой, но можно глянуть. Даже колеса 29))) единственное с чем сложность - найти нужную ростовку.
outtime, я бы б/у смотрел, за те же деньги можно получить навеску, которая как минимум будет работать, а не греметь на ходу и утяжелять вел.
Сколько занято на дисках? Есть софтовый RAID? Смотрели blktraceом что именно происходит в эти моменты, кто и что делает с дисками?
Да, там надо сделать PRIMARY KEY (product_id, iso_code), чтобы выборки по WHERE product_id = ? AND iso_code = ? выполнялись быстро. В той же кассандре например, можно объявить partition key и clustering key по разному. Например, чтобы все локали товаров лежали на одной ноде, можно сделать так: PRIMARY KEY ((product_id), iso_code), тогда выбор ноды будет происходить по product_id, а внутри конкретной партиции данные будут отсортированы по iso_code.
У меня вообще все проекты сделаны так: в урле всегда присутствует ID, причем в большинстве случаев это uuid, например:
`/ru/product/nike-boost-1911@1b3e4648-6099-4e60-8258-6f5ca13e95b9`.
ЧПУ в данной ссылке только для юзеров и поисковых ботов, нам нужно использовать все что после символа @.
Я использую uuid потому что нет синхронизации между счетчиками, не нужно париться с оффсетами/гепами между сиквенс генераторами, и под этот тип данных в СУБД всегда есть эффективный дата-тайп, для эффективного хранения. Это такой себе conflict-free identificator. Можно использовать и числовые, они не такие громоздкие, но я привык работать с uuidами.
У uuidов есть ещё большое преимущество: чтобы создать товар, нам нужно его сохранить в базу, получить ID, после, мы можем этот ID мы используем при добавлении товар в категорию, при добавлении фото товаров, т.е. по сути, мы не можем сохранить товар со всеми его фотками и категориями, пока не получим ID товара. С uuidами такой фигни нет, мы просто генерируем рандомный uuid, и сразу можем вставлять и сам товар, и фотки к нему, и все данные.
У числовых есть свои профиты, например по номеру id можно сортировать, натуральная кластеризация, и т.д.
Имея только ID, мы можем выполнить следующие запросы, и все из них параллельно:
По мере выполнения запросов, мы просто мёрджим их в объект, когда все из них выполнились (или например, не все, а какая-то часть) - мы отдаём готовый объект.
Можно, я согласен. Но ещё хуже костылить таблицу со строками в основной таблице, и дополнительными переводами в другой.
Ну так я про это и говорю. Если у вас есть нормально задизайненная таблицы с M:M и O:M связями, без денормализации которую вы сделали на ровном месте, то для выборки локаленезависимых данных, вам нужно будет сделать запрос `SELECT * FROM product WHERE id = ?`, а для локалезависимых - `SELECT * FROM product_l10n WHERE product_id = ?`, и не надо городить логику для выборки строк из основной таблицы, или из дополнительной. Меньше кода - меньше багов.
Российских - не знаю. Но я из Украины, откройте любой сайт, rozetka.ua, 27.ua, у всех лидеров есть две версии сайта. В данном контексте, это может и не важно, но раз зашла речь за интренационализацию и локализацию, то это не такая ненужная штука как может показаться на первый взгляд.
Можно и сразу заджойнить, никто от этого не умерал ещё.
Я не совсем понял, вы имеете ввиду, что если магазин имеет несколько языковых версий, или продает в несколько стран, то целесообразно заводить несколько копий товара под разные языки? Или вы имеете ввиду, что большинство магазинов просто продает разные товары, без необходимости в языках?
На самом деле, никто от джойнов не умрёт, и лучше сразу дизайнить архитектуру приложения так, чтобы добавление второго языка не было смертеподобным.
За опенкарт не топлю, только идиот будет в 2к20 делать магазин на опенкарте, тем более на 100к товаров и с бюджетом 20+ тысяч долларов.
А как правильно делать, если многоязычность?)
Автор создал тему 24.04 в 9:44, а последний визит у него был в 10:00. Т.е., после создания темы, он ушел, и больше никогда не заходил на этот форум. Кому вы советуете? Этот сценарий происходит каждую субботу.
Берите WordPress, там все решается установкой двумя-тремя сотнями плагинов.
