Это всегда было так, индексы ускоряют выборку, но замедляют запись/изменение/удаление, по этому если в таблицу в основном пишут, то ей индексы противопоказаны. У меня был один ИМ на поддержке, там БД была 17Гб, а в месте с индексами занимала место на диске больше 100Гб, ну и все операции записи/удалении/изменения естественно работают дольше с индексами, чем без. По этому например рекомендуют записи с таблицы не удалять а помечать как уаленные, потому что перестроить таблицу индексов на например 30 млн строк операция не быстрая))
На самом деле глупо расставлять индексе с "заделом на будущее", если нет функционала, который будет юзать этот индекс, то индекс будет только тормозить и увеличивать место занимаемое БД. Часто бывает так, что при разработке каких то своих выборок, ты начинаешь делать SQL с фильтрами которые раньше нигде не использовались и они начинают промахиваться и CMS начинает "тормозить". Очень часто решается анализом SQL и доустановкой нужных индексов + я видел как индексы слетали, не интересовался по какой причине, но случаи бывали. Ну и вполне возможно самописный модуль, сообщество J не сильно отличается по скилам от сообщества W, многие даже не знают что такое индексы
Вообще я отвечал ребятам за скорость их самописов и удобство использования. При том они дальше старта (который закрывают CMS на 99%) в самописах не продвинулись, именно там где самописы в основном и раскрываются. При том люди, которые сами эти самописы пишут для себя и поддерживают. Они не понимают как это выглядит со стороны клиента и поиска и работы с подрядчиками.
А так, как количество товаров определяет сложность интернет магазина, это вот самое сравнение меня ставит в ступор периодически, неужели вы считаете, что для той же MySQL есть разница работать с 500 строками в таблице или с 500к строк?
И именно, тут речь что человеку нужно всего то развернуть магазин на 3.5 калеки, с функционалом который есть в опенкарте + шаблон за 3500р + 10 часов доработки напильником от спеца в итоге по времени за пару дней. А тут про самописы загоняют, чего нет то.
У одного витрина, у другого блокируемая напрочь SQLite при записи и они доказывают за скорость, самописы и ИМ =))) Я с вами согласен ребят, инструмент надо выбирать под задачу, я рад что у вас такие задачи, что вам хватает 3х файлов и БД SQLite и вы даже не в курсе что такое очереди, nosql, шардинг, реплики и прочая херня, без которой и так можно сделать 3000 rps или 30000 rps. К сожалению у меня таких задач как у вас нет.
Банерная реклама не в сервисах, а во вкладке маркетинг. А в сервисах расположен сам компонент
Вот тут правильное направление, самописом должна быть частная логика конкретного бизнеса, а рутинные задачи, типо роутинга, шаблонизации, орм, авторизаций и прочее лучше взять что то готовое, начиная от фремймворка, заканчивая CMS, писать все механизмы самостоятельно сейчас просто глупо.
Это не противоречие, например вы будучи на самописе можете все поля товара запихнуть в одну таблицу - это будет эффективнее, потому что в CMS как правило EAV паттерн, чтоб можно было добавить любое кол-во полей, что по сути не столь эффективно как в одной таблице. Эта неэффективность скорее всего на магазине не выявится никогда и по общей работе сайта это никак не скажется.
Вы поймите, ваш набор не отличается ничем от CMS, просто это ваша cms. А вот насколько это оправданно уже зависит от конечной цели. Вы поймите, за несколько дней можно как на своей CMS так и на коробке сделать, самопис - это когда вы с нуля пишите под ТЗ, а не используете какое то свое решение. Вернитесь на несколько сообщений выше, тащить свою CMS без сопровождения старых клиентов неоправданно, именно по этому многие собственные разработки студий загнулись. При том сильно непонятно что лучше для конечного клиента, платить символических N денег ежегодно для обновления и получения новых функций или не платить и не получать ничего (так как вы как разработчик уже давно забили на этого клиента со своей CMS из набора готовых модулей/классов/кодовой базе)
Для начала я бы повесил индекс все же на табличку, тем более он у вас прям сильно просится сюда
Есть, одно время я делал магазины и на symfony и на битриксе. Так вот на symfony мы делали магазины командой разработчиков, минимум 2 человека и сроком начиная от 2х-3х месяцев, при том в этой же конторе делал магазины уровня сложности не ниже, но один и буквально за месяц. Просто делать на битриксе европейским компаниям как то не совсем удачное решение было. Портал для аларм моторс делали больше года.... вот вам и разработка. В самописе мало написать код, там надо грамотно продумать архитектуру и от постоянно меняющихся требований, самопис превращается в нечто ужасное, либо в точно такую же CMS какие есть на рынке. Преимуществ у самописов очень много, но они открываются в определенные моменты, не с нуля, делать вот прям сайт с нуля для старта бизнеса - неоправданный риск.
Не должен. Магазин должен приносить деньги, а не выдерживать сентетические тесты на стремном железе. Мы не выдержим такую нагрузку, но наш ИМ делает обороты в сотни миллионов, так что когда ваш ИМ дорастет до таких требований там и можно говорить про самопис, но 99% магазинов не дорастают, за то есть такая клёвая цитата в нашем сообществе "Преждевременная оптимизация — корень всех (или большинства) проблем в программировании"
Не вижу проблемы, я сейчас апи нашего приложения на битриксе буду переводить на roadrunner, попробую по крайней мере и посмотрим на результаты. Тем более что мешает писать в БД с другого языка не совсем понятно и в пхп и в любом языке есть клиент
В битриксе это вообще сделать проще чем в любой другой CMS которых я знаю. Потому что достаточно класс автолоадера прописать в init.php который стартует практически первым. У нас большая кодовая база, есть аннотации от доктрины, PSR7 от зенда, серилизатор и консоль от симфони, плюс либы по работу с экселем, кешем и еще кучей всего, все это подключается и обновляется через композер. А еще у нас там есть нода которая собирает фронт. и может в ssr для системы обработки заказов (тоже написана в рамках битрикса)
Эффективней, я же не спорю, если грамотный человек, то эффективнее будет конечно заточено на самописе, тут без вопросов, только на CMS это будет 200-500 человека-часов, а на самописе начинаться от 1000 - 1500 человека часов, при стоимости часа специалиста в 1500р сами посчитаете разницу или помочь? И тут возникает вопрос - в чем профит от этого решения, если на CMS можно сделать не хуже? И самое главное если это не нужно в целом, я давно работаю с бизнесом, ему пофигу на технологии и пофигу что там под капотом, у него есть определенные метрики по которым он измеряет результат, если ты можешь уложится в эти метрики при меньших затратах - почему бы и нет?---------- Добавлено 18.02.2020 в 15:09 ----------
И да, на самом деле надо понимать, что у меня тоже многие проекты самописы - только на CMS. То есть я беру CMS и переписываю те участки кода/модулей реализация которых не устраивает в рамках проекта. По этому по сути у нас наша кодовая база так же очень большая и можно её назвать самописом, но многие вещи и модули нас вполне устраивают и тратить время на написание и поддержку таких же модулей с тем же функционалом для нас не имеет никакого смысла. Это я к тому, что CMS достаточно гибкие и позволяют встраивать свой функционал в свою архитектуру достаточно бесшовно, если конечно ты владеешь этой CMS на достаточно для этого уровне.
самый популярный наверное это TecDoc
