Разработка крупного интернет-магазина

Можно, я согласен. Но ещё хуже костылить таблицу со строками в основной таблице, и дополнительными переводами в другой.

Ну так я про это и говорю. Если у вас есть нормально задизайненная таблицы с M:M и O:M связями, без денормализации которую вы сделали на ровном месте, то для выборки локаленезависимых данных, вам нужно будет сделать запрос `SELECT * FROM product WHERE id = ?`, а для локалезависимых - `SELECT * FROM product_l10n WHERE product_id = ?`, и не надо городить логику для выборки строк из основной таблицы, или из дополнительной. Меньше кода - меньше багов.

Российских - не знаю. Но я из Украины, откройте любой сайт, rozetka.ua, 27.ua, у всех лидеров есть две версии сайта. В данном контексте, это может и не важно, но раз зашла речь за интренационализацию и локализацию, то это не такая ненужная штука как может показаться на первый взгляд.

Зависит от магазина.

Некоторым магазинам достаточно перевести интерфейс и названия товаров. Тут можно даже не заморачиваться с внесением изменений по многоязычности в движок, все выполняется внешенй оберткой на выдаче.

Некоторые магазины сильно таргетируются под целевую аудиторию с учетом ее языка. Там опять же можно не заморачиваться с внесением изменений по многоязычности в движок, т.к. будет различаться абсолютно все - ассортимент, цены, скидки, процедура регистрации, дизайн, методы оплаты, персонал сайта - просто поставят второй движок рядом.

Настоящая многоязычность нужна или очень крупным агрегаторам типа ебея и амазона, либо совсем никаким магазинам типа вася продает два мопеда.

У вас просто несколько языков в стране, и часть людей знает только один из. Тут с вами я согласен, в вашем случае оно действительно оправдано было бы, но это специфика вашей страны. В России никто локализацию не делает, так как не имеет никакого смысла в рамках продаж екоммерса. буть то озон или вайлдбериес или кто либо еще из онлайн гипермаркетов, в нашем случае непонятно на какой язык еще можно перевести, так как сильно большая часть население не знает никакого кроме русского и все 100% знают русский

Делают. Дальний восток делает дубляж на китайский, питер эстонский и финский делают. Правда это при условии специфичного ассортимента.

Во втором product_id не примари. Ну или еще и локаль видимо должна фигурировать.

2 товара в одном из 1с зашли en, es, ru. Во втором только ru

Array

(

    [14818] => Array

        (

            [_id] => 14818

            [analogi] => Array

            [primenyaemost] => Array 

            [soputstvuyuschietovary] => Array

            [relevitems] => Array

            [artikul] => 

            [gruppy] => 

            [id] => 

            [kartinka] => Array

            [naimenovanie] => 

            [naimenovanienaanglijskom] => 

            [naimenovanienaispanskom] => 

            [opisanie] => 

            [price] => Array 

            [up] => 

            [ups] => 1

            [ves] => 

            [znacheniyarekvizitov] => Array

            [words] =>

            [trigramms] =>

            [seo] => Array  

            [ishit] =>

            [isview] =>

            [actionPrice] => Array

            [vendor] => Array

            [delivery] => Array

            [storage] => Array

            [slug] =>

            [customslug] =>            

        )

    [11927] => Array

        (

            [_id] => 19927

            [analogi] => Array

            [artikul] => 

            [bazovayaedinica] => Array

            [gruppy] => 

            [id] => 

            [kartinka] => Array

            [naimenovanie] => 

            [price] => Array 

            [up] => 

            [ups] => 1

            [ves] => 

            [znacheniyarekvizitov] => Array

            [words] =>

            [trigramms] =>

            [seo] => Array  

            [ishit] =>

            [isview] =>

            [actionPrice] => Array

            [vendor] => Array

            [delivery] => Array

            [storage] => Array

            [slug] =>

            [customslug] =>

        )

В целом - монга хороша для таких задач. Постгре, говорят тип json тоже сейчас имеет - тогда это идеальный вариант.

Опенкарт для малого бизнеса (но и 100к товаров тянет спокойно, и даже 1м), Битрикс для лохов. Для фреймов бюджет может быть маловат, и доработки дороговаты, а еще сроки могут затянуться.

Никак ничего конкретного не посоветуешь, когда вводных так мало. Может ему и ВП, сделанного за недельку, за глаза будет, и на долгие годы хватит. А может php/mysql в любой обертке ни в коем случае рассматривать нельзя.

Спасибо, о учитель за столь сокровенное знание что Вы нам открыли.

Да, там надо сделать 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, мы можем выполнить следующие запросы, и все из них параллельно:

• выборка информации о товаре на основании нужного нам языка
• выборка категорий товара
• выборка информации о товаре (фото, характеристики)

По мере выполнения запросов, мы просто мёрджим их в объект, когда все из них выполнились (или например, не все, а какая-то часть) - мы отдаём готовый объект.

На ВП напр

https://www.tarox.co.uk/shop/

https://ecodrift.ru/

https://medknigaservis.ru/

https://tentorium.ru/internet-magazin/

http://atlanticexpress.com.ua/

https://dobriyortoped.ru/

https://akb-moscow.ru/

Не 100к товаров, но кол-во, как правильно говорили выше, значения не имеет. А вот запросы и трафик - это да.

По внутренностям там я думаю есть все связи - и со складами и с бухгалтерией и может даже с СРМ.

Ида. не движок надо выбирать, а исполнителей (с).

Похожую тактику юзаю, c той лишь разницей, что ид - хеш от урла. Почему то не нравится ИД в урлах:(

Здесь, в отличии от рандомного (uuid -v 4) или основанного на времени (v1) все же приходится, для сборки обвеса документа использовать (урл админ может изменить и соотв. урл_ид) ид генерируемый базой или второй uid. Что накладывает, в случае автоинкрементного, ограничение на использование REPLACE/INSERT OR REPLACE, но я и так не юзаю эти команды.

Ну, или, при изменении урла/урл_ид менять все урл_ид в связанных хранилищах, что несколько муторно

 [uri] => Array

        (

            [uri_id] => 5c668ed8

            [uri] => /ru/product/nike-boost-1911

            [sids] => Array

                (

                    [f1364608] => /ru

                    [581bb2eb] => /ru/product

                    [5c668ed8] => /ru/product/nike-boost-1911

                )



            [_sids] => Array

                (

                    [/ru] => f1364608

                    [/ru/product] => 581bb2eb

                    [/ru/product/nike-boost-1911] => 5c668ed8

                )



            [sections] => Array

                (

                    [0] => ru

                    [1] => product

                    [2] => nike-boost-1911

                )



            [first] => ru

            [second] => product

            [params] => Array

                (

                    [0] => product

                    [1] => nike-boost-1911

                )



            [prm_pair] => Array

                (

                    [ru] => product

                    [product] => nike-boost-1911

                )



            [@] => 1b3e4648-6099-4e60-8258-6f5ca13e95b9 #🍻

            [full_uri] => /ru/product/nike-boost-1911@1b3e4648-6099-4e60-8258-6f5ca13e95b9

        )

В моем случае достаточно простой хеш.

  // в данном случае, где то раньше define('_HASHALGO', 'crc32b');

  return hash(_HASHALGO, $str);

Над переходом к чему то типа

$ uuid -v 5 $NAMESPACE "/ru/product/nike-boost-1911"

df5bedc5-e212-5f62-9ee3-3dea998fcd63

уже не первый раз задумываюсь.

Зы: Идею с хранением дополнительного параметра в урле спикрал :)