1. Тут используется конкретный индекс B-дерева, но в любом случае происходит full index scan, как я уже успел упомянуть.
2. Я не предлагаю держать счётчики внутри БД и блокировать всё и всея, это тема для отдельной статьи.
Я советую, исходя из своего личного опыта работы, он наверняка очень сильно отличается от вашего, не думаю что тут применима эстимация какого-либо уровня квалификации. Не стоит так категорично «вы тему не знаете, но советуете», у меня есть на то свои, личные, причины.
Вид джоина никак не должен влиять на full table scan
Это почему-же?
«Яичная диаграмка» left outer join'a говорит об обратном
В случае с Outer Join'aми заполняется внешняя часть круга — соответственно для её формирования нужен full table scan, или fast full index scan. Он может быть кэшированным в рамках профилятора СУБД, но это приводит к росту счётчиков MVCC транзакций, и возможному провалу уже существующих, что, собственно, лочит всю табличку.
В таблице 16 полей по которым мы хотим группировать в любых сочетаниях
Какая-то прям утопически идеальная задачка — такого в реальной жизни не бывает. Чаще всего, всё приходится генерировать по требованию, и подчищать если давно не использовалось. А надеяться что пользователи будут равномерно пользоваться всеми существующими сочетаниями какого-либо функционала — очень наивно.
Это быстрее чем каждый раз пересчитывать всё заново.
Там могут возникать весёлые моменты с join'aми, иногда проще отдельно заводить счётчик чем сталкиваться с таким.
А outer joinы почему долго?
Потому что, обычно, это 100% full table scan. Обычно проще заменить на UNION ALL, или на CROSS JOIN, типа так.
Я начинал с фреймворков и конкретных спецификаций — мне проще не писать лапшекод, и перерабатывать уже существующий.
Смотря что подразумевать под понятием «программирования» — у меня оно никак не связано с достижением поставленных задач любой ценой, не смотря на качество и гарантии долгосрочной поддержки.
Зачем копаться в «чужом» коде, который наверняка не покрыт тестами и наверняка плохо документирован, я уж не говорю об адекватном использовании разнообразных шаблонов проектирования?
При больших выборках count() и outer join'ы занимают очень много времени, особенно при full table scan'ах. Нужно заводить отдельно счётчики, а не ялозить всю табличку из-за каждого чиха.
Нужно понимать что существует понятие «шаблона проектирования», и оно имеет очень поверхностное отношение к «архитектуре» приложения, так как обычно она состоит с 4-5 различных шаблонов. Нужно понимать что кроме MVC существует ещё и много других вариаций шаблонов «трёхзвенной архитектуры», ну там MVP MVVM etc.
Статья бы стоила внимания если бы в ней более детально рассматривался MVC шаблон в рамках нескольких существующих фреймворков, а также если бы было сравнение с другими шаблонами и были бы описаны примеры их реализации.
А так получается Вот есть MVC, а в нём всё есть CRUD — на каждую табличку нужно по контроллеру, и по другому быть не может, MVC — это «пилюля от всех болезней» и «вселенная вращается вокруг MVC».
По личному опыту могу сказать что большинство «школьных» РНР программистов не знают
что такое PSR, и как их использовать
как производить менеджмент зависимостей
как проектировать нормализированные модели БД
почему за outer join'ы и count() нужно органов лишать
что если есть push нотификации — нужно прикручивать beanstalk / gearmand / rabbitmq, и это уже далеко не MVC
p.s. мне 23, я бросил универ на втором курсе. Учитывая ситуацию с дилетантством студентов/аспирантов (бывают исключения) — совсем не жалею.
Было бы неплохо ввести нумерацию статей, и список с содержанием в конце каждой для удобства. Не знаю, как по мне — не хватает живых примеров, я всё не читал, но отсылок к каким-либо фидлам в jsfiddle или репозиториям в github не нашёл. Нужна наглядность, а так получается — грубое описание методов без привязки к каким либо реальным задачам. Можно оформить каких-то gif'ок… в общем было бы желание.
Вы же серьёзная контора — за эти статьи наверняка кому-то платятся деньги, займитесь нормальным оформлением.
Не, на самом деле мне смешно это всё читать… я три дня угораю xD
Я ничего не говорил о вашей зрелости, и не думаю что проекция «ты сам такой» здесь уместна, вы сами в подсознании приняли это суждение к себе самому, на то есть причины, которые я не буду здесь обсуждать, за ненадобностью. Я не говорю что все вокруг дерьмо, я говорю что дерьма много, и оно есть у всех, и с ним нужно что-то делать. Не нужно так явно разбрасываться им в комментариях и считать это «почётным долгом». Просто полный ad hominem.
Я видел много всякого ангулярного дерьма, которое писалось дилетантами, и которое нереально поддерживать. После рефаторинга и покрытия тестами оно становится в половину легче и в раз 20 шустрее… Для Реакта не нужно быть «гуру JS», просто нужно относится к нему как к шаблонизатору загружающему различные данные, а их контроллеры уже нужно реализовывать отдельно в асинхронных решениях типа Rx.js или highlandjs.
Если умеешь пользоваться гуглом и читать доки — нет проблем.
Все проблемы в статье решаемы, и связаны с нежеланием автора искать какое-либо решение, а гневно ПОСТИТЬ КАПСОМ, потому что эта технология оказалась для него слишком сложной в освоении.
Если хочется шустрее чем Angular, Ember или Backbone — пробуй лучше React с rx.js или highlandjs.
Я не считаю что здоровый человек может называть себя героем, просто не хотел объяснять это подробно.
Где именно я пишу о неприемлимости «диагнозов по фото»?
По вашим комментариям можно судить о многом… и там психологу, к сожалению, делать точно нечего.
Юзабилити — это не обобщённое понятие, это отдельная дисциплина, которая включает в себя задачи микроэргономики, но от эргономики отличается тем что концентрируется на продуктивности человека, а не на продуктивности связки человека и машины в целом. Это международная стандартизированная инженерная, а не художественная дисциплина. Её задачей было совмещение и генерализация инженерной психологии и промышленного дизайна, так что бы их нормально могли воспринимать инженеры.
Речь о том что эти понятия прямого отношения к художникам, графикам и иллюстраторам не имеют. Их тоже всех принято генерализированно называть дизайнерами, но это ошибочное мнение — это разные дисциплины, которые пересекаются лишь отчасти. Художник, иллюстратор и график в реальной жизни рисуют совсем различные вещи.
У нас тут принято употреблять слово юзабилити где не лень, но я знаком со стандартизированным понятием и подразумеваю именно его.
Я понимаю что вам не понравилось слово «задачи», просто я прочитал пару книжек по этому поводу, и, к сожалению, не могу подобрать более подходящего, так как отношусь к предмету не как к абстрактному понятию, а как к дисциплине.
Я не рвусь ставить диагнозы, есть теория и практика, а психологи почти во всём согласны… тем более это слишком примитивные процессы. Не хочу раскладывать по полочкам суждения vilgelm-hero и его проблемы — он потом меня просто возненавидят (об этом тоже написано в статье, если внимательно читать), но могу скинуть в личку. Я пальцем не тыкаю, просто он сам к себе применяет генерализированные общие суждения которые к нему непосредственно не относятся (пишу «люди», а не «ты»). Наверное, не просто так же это происходит. Здоровый человек промолчал после ответа на свой же вопрос, а не стал бы столь явно указывать свои проблемы под действием сильного эмоционального напряжения.
Конечно жаль, что товарищ brizzz не смог написать ничего сложнее чем:
«Ты кинул заказчика — ты плохой и статья твоя дерьмо.»,
это на столько же весело как и написать:
«Как вы не едите мяса ?! Гитлер был вегетарианцем! — Жрите мяяясо!»
Я не виню его, он застрял в PHP со средними навыками симфонии между «мясоперерабатывающим цехом» и «обучением».
Играет в «доброго и пушистого» «заказчик всегда прав», и это его личный выбор: «не жить, а работать».
То что я стараюсь отвечать на каждый комментарий — подразумевает то, что я ценю позицию комментирующих, и хочу выразить свою, чтобы мы могли её обсудить. Это проявление уважения к моим читателям.
2. Я не предлагаю держать счётчики внутри БД и блокировать всё и всея, это тема для отдельной статьи.
Я советую, исходя из своего личного опыта работы, он наверняка очень сильно отличается от вашего, не думаю что тут применима эстимация какого-либо уровня квалификации. Не стоит так категорично «вы тему не знаете, но советуете», у меня есть на то свои, личные, причины.
«Яичная диаграмка» left outer join'a говорит об обратном
В случае с Outer Join'aми заполняется внешняя часть круга — соответственно для её формирования нужен full table scan, или fast full index scan. Он может быть кэшированным в рамках профилятора СУБД, но это приводит к росту счётчиков MVCC транзакций, и возможному провалу уже существующих, что, собственно, лочит всю табличку.
Какая-то прям утопически идеальная задачка — такого в реальной жизни не бывает. Чаще всего, всё приходится генерировать по требованию, и подчищать если давно не использовалось. А надеяться что пользователи будут равномерно пользоваться всеми существующими сочетаниями какого-либо функционала — очень наивно.
Там могут возникать весёлые моменты с join'aми, иногда проще отдельно заводить счётчик чем сталкиваться с таким.
Потому что, обычно, это 100% full table scan. Обычно проще заменить на UNION ALL, или на CROSS JOIN, типа так.
Смотря что подразумевать под понятием «программирования» — у меня оно никак не связано с достижением поставленных задач любой ценой, не смотря на качество и гарантии долгосрочной поддержки.
Зачем копаться в «чужом» коде, который наверняка не покрыт тестами и наверняка плохо документирован, я уж не говорю об адекватном использовании разнообразных шаблонов проектирования?
Статья бы стоила внимания если бы в ней более детально рассматривался MVC шаблон в рамках нескольких существующих фреймворков, а также если бы было сравнение с другими шаблонами и были бы описаны примеры их реализации.
А так получается Вот есть MVC, а в нём всё есть CRUD — на каждую табличку нужно по контроллеру, и по другому быть не может, MVC — это «пилюля от всех болезней» и «вселенная вращается вокруг MVC».
По личному опыту могу сказать что большинство «школьных» РНР программистов не знают
p.s. мне 23, я бросил универ на втором курсе. Учитывая ситуацию с дилетантством студентов/аспирантов (бывают исключения) — совсем не жалею.
Вы же серьёзная контора — за эти статьи наверняка кому-то платятся деньги, займитесь нормальным оформлением.
Я ничего не говорил о вашей зрелости, и не думаю что проекция «ты сам такой» здесь уместна, вы сами в подсознании приняли это суждение к себе самому, на то есть причины, которые я не буду здесь обсуждать, за ненадобностью. Я не говорю что все вокруг дерьмо, я говорю что дерьма много, и оно есть у всех, и с ним нужно что-то делать. Не нужно так явно разбрасываться им в комментариях и считать это «почётным долгом». Просто полный ad hominem.
Все проблемы в статье решаемы, и связаны с нежеланием автора искать какое-либо решение, а гневно ПОСТИТЬ КАПСОМ, потому что эта технология оказалась для него слишком сложной в освоении.
Если хочется шустрее чем Angular, Ember или Backbone — пробуй лучше React с rx.js или highlandjs.
Где именно я пишу о неприемлимости «диагнозов по фото»?
По вашим комментариям можно судить о многом… и там психологу, к сожалению, делать точно нечего.
Юзабилити — это не обобщённое понятие, это отдельная дисциплина, которая включает в себя задачи микроэргономики, но от эргономики отличается тем что концентрируется на продуктивности человека, а не на продуктивности связки человека и машины в целом. Это международная стандартизированная инженерная, а не художественная дисциплина. Её задачей было совмещение и генерализация инженерной психологии и промышленного дизайна, так что бы их нормально могли воспринимать инженеры.
Речь о том что эти понятия прямого отношения к художникам, графикам и иллюстраторам не имеют. Их тоже всех принято генерализированно называть дизайнерами, но это ошибочное мнение — это разные дисциплины, которые пересекаются лишь отчасти. Художник, иллюстратор и график в реальной жизни рисуют совсем различные вещи.
У нас тут принято употреблять слово юзабилити где не лень, но я знаком со стандартизированным понятием и подразумеваю именно его.
Я понимаю что вам не понравилось слово «задачи», просто я прочитал пару книжек по этому поводу, и, к сожалению, не могу подобрать более подходящего, так как отношусь к предмету не как к абстрактному понятию, а как к дисциплине.
Я не рвусь ставить диагнозы, есть теория и практика, а психологи почти во всём согласны… тем более это слишком примитивные процессы. Не хочу раскладывать по полочкам суждения vilgelm-hero и его проблемы — он потом меня просто возненавидят (об этом тоже написано в статье, если внимательно читать), но могу скинуть в личку. Я пальцем не тыкаю, просто он сам к себе применяет генерализированные общие суждения которые к нему непосредственно не относятся (пишу «люди», а не «ты»). Наверное, не просто так же это происходит. Здоровый человек промолчал после ответа на свой же вопрос, а не стал бы столь явно указывать свои проблемы под действием сильного эмоционального напряжения.
Конечно жаль, что товарищ brizzz не смог написать ничего сложнее чем:
«Ты кинул заказчика — ты плохой и статья твоя дерьмо.»,
это на столько же весело как и написать:
«Как вы не едите мяса ?! Гитлер был вегетарианцем! — Жрите мяяясо!»
Я не виню его, он застрял в PHP со средними навыками симфонии между «мясоперерабатывающим цехом» и «обучением».
Играет в «доброго и пушистого» «заказчик всегда прав», и это его личный выбор: «не жить, а работать».
То что я стараюсь отвечать на каждый комментарий — подразумевает то, что я ценю позицию комментирующих, и хочу выразить свою, чтобы мы могли её обсудить. Это проявление уважения к моим читателям.