| |||||||||
| |||||||||
01.10.2016 18:06
Думаю на днях. скорее к понедельнику-вторнику.
Что делается или сделано:
-теперь не будет отдельных скриптов(почти) с префиксом mysql, одна единственная админка
-я вшиваю поддержку sql в существующие модули, поэтому все фишки файловой БД будут автоматически становится фишками БД MySQL - это была основная проблема, но я ее решил совмещенным режимом работы (тем более EWC стало настоящей СУБД, только сфинкса не хватает):
-пока EWC будет работать в совмещенном режиме при выборе MySQL в качестве хранения БД товаров (пользователей пока не выбирайте в качестве хранения в MySQL БД) - это означает что все товары вносятся в базу MySQL, в которой хранятся кроме самих товаров, их рейтинги, юнифиды, enum-ы, внешний склад и тому подобная служебка в первых 10 столбцах. с 11 столбца начинаются столбцы те же что и в db_index
-при индексации они расползаются в db_index.txt (общий индекс, который может работать самостоятельно! при крэше MySQL или при дропе ее), далее в преиндексы разделов и фасет товаров (итемы)
-при заходе на страницы, сортировке товаров создается файловый кэш, все как обычно, то есть как такового доступа к БД MySQL нет!
При СП - режиме - ОРГи заполняют только свои файловые БД не имея доступа к БД mySQL
при индексации идет наполнение БД MySQL ОРГ-базами.
Плюсы совмещенного режима:
-всегда есть бекап базы и при креше и дропе можно все восстановить простой миграцией (такой пункт есть в ADM-ДОПОЛНИТЕЛЬНО) или даже сделать автопереключение на режим files (это я подумаю)
-отсутствие SQL уязвимостей
-не надо переделывать все и вся
-БД можно использовать в других местах по вашему усмотрению
-миграция туда и обратно
Минусы совмещенного режима:
-при админской работе приходится править обе БД сразу, что немного замедляет скорость админинья.
-сложно прикрутить сфинкс (нужен при огромном кол-ве товаров под 100000 и выше)
-мемкэшед остается не задействован, но об этом ниже.
Теперь что сделано под совмещенный режим:
-Админ товаров
-Удаление товара
-Убирание товара из продажи и занесение в архив
-Редактирование карточки товара
-При выборе MySQL и windows-1251 кодировки на сайте, автоматически БД переводится в режим запросов cp1251 (не надо настраивать апач)
Что надо сделать:
-Клонирование товара
-Удаление разделов товара
-Заведение нового товара
Неспешно:
-поиск и замена в MySQL базе (и сейчас можно сделать через админку - но только через бекап MySQL Базы в файловую, поиск и замена и миграция обратно)
-вывод товара напрямую из MySQL базы (для использования мемкэша), хотя кто использует файловый кэш - это некритичный пункт
-подбор товара напрямую из MySQL базы, позволит прикруть мемкэшед и сфинкса
Очень неспешно:
-Прикрутить MySQLi
-Универсальный API доступа к БД
-Юникод движка (только при использовании БД MySQL)
Что делается или сделано:
-теперь не будет отдельных скриптов(почти) с префиксом mysql, одна единственная админка
-я вшиваю поддержку sql в существующие модули, поэтому все фишки файловой БД будут автоматически становится фишками БД MySQL - это была основная проблема, но я ее решил совмещенным режимом работы (тем более EWC стало настоящей СУБД, только сфинкса не хватает):
-пока EWC будет работать в совмещенном режиме при выборе MySQL в качестве хранения БД товаров (пользователей пока не выбирайте в качестве хранения в MySQL БД) - это означает что все товары вносятся в базу MySQL, в которой хранятся кроме самих товаров, их рейтинги, юнифиды, enum-ы, внешний склад и тому подобная служебка в первых 10 столбцах. с 11 столбца начинаются столбцы те же что и в db_index
-при индексации они расползаются в db_index.txt (общий индекс, который может работать самостоятельно! при крэше MySQL или при дропе ее), далее в преиндексы разделов и фасет товаров (итемы)
-при заходе на страницы, сортировке товаров создается файловый кэш, все как обычно, то есть как такового доступа к БД MySQL нет!
При СП - режиме - ОРГи заполняют только свои файловые БД не имея доступа к БД mySQL
при индексации идет наполнение БД MySQL ОРГ-базами.
Плюсы совмещенного режима:
-всегда есть бекап базы и при креше и дропе можно все восстановить простой миграцией (такой пункт есть в ADM-ДОПОЛНИТЕЛЬНО) или даже сделать автопереключение на режим files (это я подумаю)
-отсутствие SQL уязвимостей
-не надо переделывать все и вся
-БД можно использовать в других местах по вашему усмотрению
-миграция туда и обратно
Минусы совмещенного режима:
-при админской работе приходится править обе БД сразу, что немного замедляет скорость админинья.
-сложно прикрутить сфинкс (нужен при огромном кол-ве товаров под 100000 и выше)
-мемкэшед остается не задействован, но об этом ниже.
Теперь что сделано под совмещенный режим:
-Админ товаров
-Удаление товара
-Убирание товара из продажи и занесение в архив
-Редактирование карточки товара
-При выборе MySQL и windows-1251 кодировки на сайте, автоматически БД переводится в режим запросов cp1251 (не надо настраивать апач)
Что надо сделать:
-Клонирование товара
-Удаление разделов товара
-Заведение нового товара
Неспешно:
-поиск и замена в MySQL базе (и сейчас можно сделать через админку - но только через бекап MySQL Базы в файловую, поиск и замена и миграция обратно)
-вывод товара напрямую из MySQL базы (для использования мемкэша), хотя кто использует файловый кэш - это некритичный пункт
-подбор товара напрямую из MySQL базы, позволит прикруть мемкэшед и сфинкса
Очень неспешно:
-Прикрутить MySQLi
-Универсальный API доступа к БД
-Юникод движка (только при использовании БД MySQL)