Я бы задумался над тем, чтобы оптимизировать архитектуру. Если они были написаны в 2000-х, значит код старый. Можно все переписать, прикрутить кеши всякие, освежить все. Пережмите все стили, html шаблоны можно компилировать без табов и переносов строк. Экономит на 50% вес самой страницы. Базу тоже можно оптимизировать. Переписать запросы.
Конечно, не зная тематики, сложно сказать, но в целом, все как и везде: либо увеличиваем маржу, либо снижаем затраты. Для меня в приоритете всегда снижать затраты.
Попробуйте юзать что-то вроде левентштайна. Суть в том, чтобы мерять расстояние между строками. Примерный алгоритм:
1) Человек вводит на сайт vasya@ramler.ru (не хватает буквы b)
2) Вы берете доменную зону ramler.ru и высчитываете расстояние между теми доменными зонами, на которые письма успешно доходят.
3) Сравниваем ramler.ru и rambler.ru - расстояние 1, потому что не хватает одной буквы (b). Тут утрированно, можно сделать так, что на вставку и на замену разные очки/баллы. Но в вашем случае достаточно 1 для всех случаев не попадания.
4) Если левенштайн > 1 значит что-то не так. Предлагаем варианты, отсортированные по возрастанию левенштайна.
5) Если левенштайн = 0 - значит, как минимум домен, корректный.
Но ошибиться он может и до знака @. Тут поможет подтверждение почты. Можно прикрутить авторизацию по телефону, но тут затраты на SMS. Дебилизм не искоренить.
К наркоману нужно относится так, как будто это человек с раздвоением личности. Сегодня он говорит что готов бросить и сделает все что скажете, завтра пойдет за дозой. И подход нужен соответствующий. Работал с дядькой, который тоже наркоманил сильно по молодости. Единственное что остановило: смерть матери. После похорон зарекся, не пить и не употреблять. Если честно, вы вряд ли что-то сделаете тут. Он сам должен к этому прийти, через какой-то стресс или эмоции. При этом важно не доводить до отчаяния, в котором человек может сорваться и заново начать наркоманить. Если он сам не захочет - то вы ему не поможете. Наркоман становится настолько изобретательным, что вы даже не поймете как он проносит и где берет дозу.
В данной ситуации девочка просто создала новый товар потому что скоро новый год. А старый скрыла с витрины. Сама чашка - та же. И все. Реальная ситуация, где поставщики меняют артикулы как захотят и когда захотят. И объясняй ты им хоть ты тресни, что артикул создается раз, он должен быть уникальным, и не меняться на протяжении жизни товара. Они в артикул вообще могут "1" вписать. Привязываться к идентификаторам поставщиков нельзя. Вообще у меня реализована система, когда прайс импортируется, то все данные сохраняются во временную таблицу. Когда ты заходишь в импорт, там видно товар до, и товар после. И кнопки "Применить все" и "Применить выделенные". Даже после применения есть возможность откатиться назад. Потому что есть лог импортов. Но опять же, автоматизировать я это никогда не рискну, потому что часто косяки.
[id] VARCHAR(32) PRIMARY KEY ON CONFLICT ROLLBACK NOT NULL UNIQUE,
id = strlen($url)>32 ? md5($url) : str::translit($url,'_', str::URL);
Данная конструкция шаткая. Объясняю: если символов меньше или равно 32, то вы транслитеризируете текст, очевидно на английский. Я конечно не знаю что там у вас за транслитеризация, но если она какая-то более вменяемая, то подав на вход url текст "Жирный жираф бежит через поле" на выход вы получите "zhirnyiy_zhiraf_bezhit_cherez_pole", что уже не вмещается в 32 символа VARCHAR(32), потому что их тут 34.
Да и в целом, вы мне скинули не то о чем я вас просил. Я вас просил о том, чтобы вы мне скинули таблицы: товары на сайте, описания, и как вы свяжете описания с товаром на сайте, при этом товары импортируются из прайса поставщика. Пример прайса из одного товара я вам дал выше. После чего мы с вами воспроизведем ситуацию, как сказал человек выше: удалим все товары и зальем заново, и посмотрим на то, как описания останутся прикреплены к товарам.
_SP_: Вы мне одно объясните, нафига ВП для сайта ресторана-то ? Чем нотепад + html не подходят ? Не хватает сил освоить десяток тэгов ?
Ну вообще, как бы да. Можно и так. Почитайте эту тему: /ru/forum/953962
Но в целом, сайт кафе/ресторана подразумевает какие-никакие новости, организация каких-то вечеров свиданий и прочих флешмобов, о которых можно написать в блог. Также есть галерея банкетов, куда можно выгружать всякие фотоальбомы. Так что тут статикой не отделаться.
Marat_Kh: Варианты: $vendorId . $itemId; $vendorId . $name; $vendorId . $sku; $vendorId . $catId . $sku | $name | $itemId; --- или url (md5|crc от url) - считаю самым простым и лучшим, но каждый урл реально д.б. уникальным на вашем сайте. В случае смены урл, в таблице обвеса тоже надо изменить. Уполномоченный юзер (role=manager например) зашел залогиненным на документ, ткнул капу, залил фото/отредактировал текст/(....). По крону, таблица обвеса, чистится от того, чего уже нет на сайте.
Покажите как вы его сохраните у себя, со всеми таблицами.
Marat_Kh: Важно где хранить в ВП и как оттуда быстро добывать, при этом обезопасив себя от коллизий при обновлении прайса и от обновления ВП. И, вообще, есть ли тогда смысл в ВП, только для роутинга (гуру ВП помогите человеку), загрузки картинок, размещения десятка статичных страниц, отчетов вукомерса, м.б. платежей картой и еще там чего по мелочи. Коли мы все равно напишем 100500 строк кода и создадим x-таблиц/файлов для хранения данных (привет обновлениям ВП/плагинов).
Как хранить? Да так же, как и на фреймворках. Только проблема в том, что я не сторонник WP (пруф за 2016 год), но я всегда буду выбирать нужный инструмент под конкретную задачу. А задача другая: сайт ресторана а не интернет-магазина.
Ну а по поводу роутинга, нужно делать canonical. Показывать или не показывать страницу при опечатке или точке/слеше в конце - спорный момент.
borisd: Простой пример: если описания отделены от товаров, то я могу спокойно удалить целиком базу товаров и импортировать её из файлов поставщиков заново. Все описания товаров останутся на месте. А если описания находятся в самих товарах, то вы уже будете связаны по рукам и ногам при импорте.
А связываете вы описания с товарами как? По SKU который дает поставщик? А если два поставщика дадут одинаковые SKU? А знаете как поставщики меняют SKU? А если привязываете к какому-то PRIMARY KEY AUTOINCREMENT, тогда не прокатит ваш трюк.
Marat_Kh, с трудом понимаю ваши посты, манера речи у вас немного не ясная, но все же... Права доступа на что? Есть RBAC/ABAC, выдал контентщикам доступ на изменение фоток и описания, и все. Все остальное не видят. Для этого обязательно микросервис пилить? И то что вы мне скинули, в частности ItemSpecifics, это EAV, ясное дело что никто не будет хранить его в таблице рядом с товаром, хотя BJSON это позволяет и более того, решает некоторые вопросы проивзодительности.
Да я понимаю, что phpenmod включает. Только толку-то. Вот пример:
Зона в основном под софт и стартапы. От Input/Output.
Я бы задумался над тем, чтобы оптимизировать архитектуру. Если они были написаны в 2000-х, значит код старый. Можно все переписать, прикрутить кеши всякие, освежить все. Пережмите все стили, html шаблоны можно компилировать без табов и переносов строк. Экономит на 50% вес самой страницы. Базу тоже можно оптимизировать. Переписать запросы.
Конечно, не зная тематики, сложно сказать, но в целом, все как и везде: либо увеличиваем маржу, либо снижаем затраты. Для меня в приоритете всегда снижать затраты.
Попробуйте юзать что-то вроде левентштайна. Суть в том, чтобы мерять расстояние между строками. Примерный алгоритм:
1) Человек вводит на сайт vasya@ramler.ru (не хватает буквы b)
2) Вы берете доменную зону ramler.ru и высчитываете расстояние между теми доменными зонами, на которые письма успешно доходят.
3) Сравниваем ramler.ru и rambler.ru - расстояние 1, потому что не хватает одной буквы (b). Тут утрированно, можно сделать так, что на вставку и на замену разные очки/баллы. Но в вашем случае достаточно 1 для всех случаев не попадания.
4) Если левенштайн > 1 значит что-то не так. Предлагаем варианты, отсортированные по возрастанию левенштайна.
5) Если левенштайн = 0 - значит, как минимум домен, корректный.
Но ошибиться он может и до знака @. Тут поможет подтверждение почты. Можно прикрутить авторизацию по телефону, но тут затраты на SMS. Дебилизм не искоренить.
К наркоману нужно относится так, как будто это человек с раздвоением личности. Сегодня он говорит что готов бросить и сделает все что скажете, завтра пойдет за дозой. И подход нужен соответствующий. Работал с дядькой, который тоже наркоманил сильно по молодости. Единственное что остановило: смерть матери. После похорон зарекся, не пить и не употреблять. Если честно, вы вряд ли что-то сделаете тут. Он сам должен к этому прийти, через какой-то стресс или эмоции. При этом важно не доводить до отчаяния, в котором человек может сорваться и заново начать наркоманить. Если он сам не захочет - то вы ему не поможете. Наркоман становится настолько изобретательным, что вы даже не поймете как он проносит и где берет дозу.
borisd, предположим, что на следующей неделе Новый год. Год обезьяны. Поставщик присылает новый прайс:
В данной ситуации девочка просто создала новый товар потому что скоро новый год. А старый скрыла с витрины. Сама чашка - та же. И все. Реальная ситуация, где поставщики меняют артикулы как захотят и когда захотят. И объясняй ты им хоть ты тресни, что артикул создается раз, он должен быть уникальным, и не меняться на протяжении жизни товара. Они в артикул вообще могут "1" вписать. Привязываться к идентификаторам поставщиков нельзя. Вообще у меня реализована система, когда прайс импортируется, то все данные сохраняются во временную таблицу. Когда ты заходишь в импорт, там видно товар до, и товар после. И кнопки "Применить все" и "Применить выделенные". Даже после применения есть возможность откатиться назад. Потому что есть лог импортов. Но опять же, автоматизировать я это никогда не рискну, потому что часто косяки.
Marat_Kh, ну и код)) 😕
Данная конструкция шаткая. Объясняю: если символов меньше или равно 32, то вы транслитеризируете текст, очевидно на английский. Я конечно не знаю что там у вас за транслитеризация, но если она какая-то более вменяемая, то подав на вход url текст "Жирный жираф бежит через поле" на выход вы получите "zhirnyiy_zhiraf_bezhit_cherez_pole", что уже не вмещается в 32 символа VARCHAR(32), потому что их тут 34.
Да и в целом, вы мне скинули не то о чем я вас просил. Я вас просил о том, чтобы вы мне скинули таблицы: товары на сайте, описания, и как вы свяжете описания с товаром на сайте, при этом товары импортируются из прайса поставщика. Пример прайса из одного товара я вам дал выше. После чего мы с вами воспроизведем ситуацию, как сказал человек выше: удалим все товары и зальем заново, и посмотрим на то, как описания останутся прикреплены к товарам.
Вы мне одно объясните, нафига ВП для сайта ресторана-то ?
Чем нотепад + html не подходят ?
Не хватает сил освоить десяток тэгов ?
Ну вообще, как бы да. Можно и так. Почитайте эту тему: /ru/forum/953962
Но в целом, сайт кафе/ресторана подразумевает какие-никакие новости, организация каких-то вечеров свиданий и прочих флешмобов, о которых можно написать в блог. Также есть галерея банкетов, куда можно выгружать всякие фотоальбомы. Так что тут статикой не отделаться.
Варианты:
$vendorId . $itemId; $vendorId . $name; $vendorId . $sku; $vendorId . $catId . $sku | $name | $itemId;
--- или
url (md5|crc от url) - считаю самым простым и лучшим, но каждый урл реально д.б. уникальным на вашем сайте. В случае смены урл, в таблице обвеса тоже надо изменить. Уполномоченный юзер (role=manager например) зашел залогиненным на документ, ткнул капу, залил фото/отредактировал текст/(....). По крону, таблица обвеса, чистится от того, чего уже нет на сайте.
Вот вам прайс из одного товара.
Пусть я буду vendor = 1;
Покажите как вы его сохраните у себя, со всеми таблицами.
Важно где хранить в ВП и как оттуда быстро добывать, при этом обезопасив себя от коллизий при обновлении прайса и от обновления ВП. И, вообще, есть ли тогда смысл в ВП, только для роутинга (гуру ВП помогите человеку), загрузки картинок, размещения десятка статичных страниц, отчетов вукомерса, м.б. платежей картой и еще там чего по мелочи. Коли мы все равно напишем 100500 строк кода и создадим x-таблиц/файлов для хранения данных (привет обновлениям ВП/плагинов).
Как хранить? Да так же, как и на фреймворках. Только проблема в том, что я не сторонник WP (пруф за 2016 год), но я всегда буду выбирать нужный инструмент под конкретную задачу. А задача другая: сайт ресторана а не интернет-магазина.
Ну а по поводу роутинга, нужно делать canonical. Показывать или не показывать страницу при опечатке или точке/слеше в конце - спорный момент.
Простой пример: если описания отделены от товаров, то я могу спокойно удалить целиком базу товаров и импортировать её из файлов поставщиков заново. Все описания товаров останутся на месте. А если описания находятся в самих товарах, то вы уже будете связаны по рукам и ногам при импорте.
А связываете вы описания с товарами как? По SKU который дает поставщик? А если два поставщика дадут одинаковые SKU? А знаете как поставщики меняют SKU? А если привязываете к какому-то PRIMARY KEY AUTOINCREMENT, тогда не прокатит ваш трюк.
Marat_Kh, с трудом понимаю ваши посты, манера речи у вас немного не ясная, но все же... Права доступа на что? Есть RBAC/ABAC, выдал контентщикам доступ на изменение фоток и описания, и все. Все остальное не видят. Для этого обязательно микросервис пилить? И то что вы мне скинули, в частности ItemSpecifics, это EAV, ясное дело что никто не будет хранить его в таблице рядом с товаром, хотя BJSON это позволяет и более того, решает некоторые вопросы проивзодительности.