я не говорил, что первый вариант неправильный...
с точки зрения sql оба запроса будут работать одинаково.
лучше почитать статью, которую я кинул упомянул. там хорошо все описано
@xoma
лично у меня мнение двоякое... да, вроде как такое работать будет везде, но:
- очень много зависит от количества задач, которые нужно обработать в единицу времени + постоянное их дополнение. из моего опыта могу сказать, что когда приходит в секунду даже по 10 задач на выполнение - база начинает тормозить (а если учесть, что есть разграничения на приоритеты + индексация...)
- проблема при работе с БД в том, что можно нормально организовать только 1 процесс/поток для получения тасков. в противном случае могут быть проблемы с синхронизацией доступа к одной и той же задаче
@PiloTeZ
если делать не для людей, тогда зачем вообще делать?
если хоть как-то косвенно это касается людей - уже делается "для людей"
очереди всегда используются для внутренней логики. вопрос в скорости их обработки и синхронизации.
мое мнение: я бы не реализовывал очередь в БД, если бы играла роль скорость ее обработки. если не важно когда это выполниться, главное, чтоб выполнилось и это будет обрабатываться только 1 точкой входа - тогда можно и в БД
если выбор останется за БД, тогда я посоветовал бы не плодить (добавлять) колонки, а ввести колонку с конфигурацией, где будут совмещены те параметры, которые нужны для инициализации/запуска (к примеру: класс, метод, входящие параметры и т.п.)
@mx2000
(facepalm)
1. я говорил о code style и именовании переменных. это приминимо в ЛЮБОМ языке программирования
2. паскаль давно умер. и паскаль - это не панацея. нормальные IDE говорят еще во время написания кода такие проблемы.
3. я не говорил про то, что типизация и скриптовый язык - две взаимоисключающие вещи. я говорил про скорость разработки.
в любом случае, как в типизированных языках, так и в слабо типизированых (или, как кто-то порой думает НЕтипизированых) можно проверять как с учетом типов данных, так и без.
пример на скриптовых языках:
@mx2000
плохому танцору всегда что-то мешает...
проблема не в том, что PHP плох, проблема в том, что его зачастую неумело используют по причине того, что начинают его учить, так как он сам по себе простой.
а дыры - это совсем другое дело. это никак не зависит от выбора языка. на java и c# такого немало встречал
да и скорость разработки на скриптовом языке в разы больше чем на любом типизированом
@invaest
пожалуйста.
небольшой совет:
надо очень усердно поработать над code style (взять, к примеру, psr-x стандарт) и над именованием переменных. так же советую почитать Clean Code Роберта Мартина
я ведь и говорю, что будут создаваться, если приходит запрос на добавление нового индекса )
в инструкции к автомобилю ведь не пишут: не надо впрягаться и тянуть автомобиль, надо садиться и ехать внутри. вот и тут такая-же ситуация
а ведь и так, и сяк автомобиль будет котиться (если силенко при впрягании хватит, конечно :) )
>Видимо действительно просто не сделали "защиты от дурака".
а зачем? в некоторых случаях это бывает необходимо (в случае с разными типами индексов)
а почему бы и не создавать, если поступила инструкция на создание индекса? основным критерием разграничения индексов является только имя индекса
сами по себе индексы ведь не создаются )
@Fesor
имхо главная проблема в том, что в yii2 все дальше продолжают изобретать велосипеды + явные попытки втолкнуть то, что плохо вталкивается в текущую архитектуру. в Laravel идут как раз от обратного (за частую): берут за основу что-то уже готовое (и, за частую, концептуально хорошее) и используют
лично мне ActiveRecord не нравиться как был реализован в yii, так и в yii2 ничем особо он не отличился. все так же и осталось много граблей/прыжков с переподвыподвертом для реализации нужд. а ORM в фреймворке на сегодняшний день наверное одна из наиболее используемых (после роутинга) компонент
@killeat не обязательно это делать за деньги... можно поучаствовать в open source, к примеру... проектов на github валом, в которых есть баги, которые, в свою очередь, надо править. а на все времени ни у кого не хватает...
@uJlJluduAH вообще немного странно, что не работает (попробовал на MacOS X 10.9 + iPhone - все нормально)... но тут без деталей сложно что-то сказать... может хоть на форуме помогут )
@killeat ни в коем случае не надо боятся собеседований. даже если не возьмут на работу - все равно будет практика проходить собеседования (а это уже не малого стоит)
в 90% случаев на junior позицию берут с базовым знанием языка и программирования.
параллельно для развития предложил бы попробовать что-то (более мение толково работающее) реализовать самостоятельно/поучавствовать в разработке в команде даже удаленно, но с code review (обязательно). об этом можно будет упоминать на собеседованиях + кто-то будет смотреть как пишется код и поправлять ошибки (что является не плохой практикой)
с точки зрения sql оба запроса будут работать одинаково.
лучше почитать статью, которую я кинул упомянул. там хорошо все описано