Полезная статья для новичком, однако, замечу, что редактирование файлов ядра чревато большими проблемами. Если что-либо вас не устраивает в самом ядре- в помощь ООП.
Также стоит заметить, что в реальной ситуации, при работе с крупными проектами такой подход, по моему мнению, не самый удачный, так как часто приходится разносить проекты на разные сервера. В таком случае, при достаточном уровне финансирования больше подходит вариант с промежуточным сервером для тестирования+система контроля версий(я использую mercurial).В таком варианте можно уже на уровне .htpasswd настроить доступ+ ip.
Вообще, очень интересно, можно ли добиться ответственности от компании, которая так подставила?
Думаю, в случае создания законодательной базы, дыр в сайтах станет намного меньше.
Собственно говоря, суть этой статьи была не в том, чтобы предложить битовую маску для реализации большинства задач, которые подходят, а в том, чтобы дать готовое решение для работы с битовой маской на Yii.
По поводу замедления запросов в 10 раз: откуда такая цифра? Если проводились тесты- то на каких объемах данных? Со сколькими битами велась фильтрация? Я думаю, что говорить о быстродействии можно только в рамках конкретной задачи. Хотя Ваше замечание в некоторых случаях действительно верно.
К вопросу по индексам- не вижу проблем с созданием индексов при условии, что флаги меняются редко. Тогда запрос идет по одному поле, в отличие от нескольких полей в Вашем случае.
Система создавалась для наших клиентов, для экономии рекламного бюджета и привлечении целевой аудитории. У нас это получилось. Аукцион формирования цен, который не привязывает рекламодателя к личному кабинету, для контроля за большим процентом показов. На учет кликов влияет поведение пользователя на сайте(анализ клика на заинтересованность пользователя сайтом).
Не уверен, что такой подход будет всегда уместен. Хотя такая идея тоже имеем место быть.
Например, мне нужно проверить, установлен ли определенный бит, вне зависимости от других. Описанный мною подход я обычно использую для определения определенных битов. Кроме того, может возникнуть ситуация, когда в запросе может оказаться несколько требований к флагам из разных мест. Например, часть требований заложены в моделе поумолчанию, в defaultScope, часть требований мы вводим через noBlock(), например. Еще часть закладываем напрямую в findAll() через параметры. Причем, эти параметры зависимые и изначально мы не всегда можем определить и найти комбинированные значения, которые предложены Вами. Т.к. В экшонах могут быть случаи, когда мы абстрагируемся от модели и не знаем, какая она будет и какие флаги в ней уже заложены и какие понадобятся…
Не согласен с фильтрацией на строне php. Вовсе не так. Фильтрация происходит на строне sql. На стороне php реализован механизм для работы с классами Yii для работы с базой.
Все дело в том, что при проектировании базы данных нужно иметь представление о требованиях. Если предполагается, что набор свойств может быть порядка нескольких десятков и разрядности может не хватить- тогда эту схему применять не стоит. Однако, пример с серилизацией здесь не уместен, т.к. это действительно зло и никаких методов для фильтрации через такие поля не существует без костылей. А предлагаемый мной метод позволяет и фильтровать и оптимизировать работу с флагами.
А что нужно в голове удерживать то?
Каждый флаг имеет свое название и свое место в битовой маске. А при вызове нужно указывать не цифру, а свойство-константу класса- тогда код будет читаем и понятен.
Да, к тому же, таким способом появляется удобный интерфейс работы с подобными данными, как с единым функциональным элементом. Вроде, getFlag- можно для некоторых данных интерпретировать как получить настройку.
что именно сложного было в моем коде?
2 метода — это простая логика, с которой должен быть знаком как раз любой пятиклассник.
что касается метода фильтрации- то тут нужно знать как работать с CDbCriteria в Yii и как работать с той же булевой логиков в sql. Возможно, некоторые детали можно, а может, и нужно было написать по другому, тогда пишите, что не так.
Обязательно. Я хотел сначала закончить идею про битовые флаги. После второй части выложу сразу готовый инструмент на yii-extentions и дам линк в топик.
Понимаю, однако такой подход не везде следует использовать. объем данных требует использовать критерий как ключ, то описанный подход не самый удачный. Такой подход подойдет, когда следует хранить много настроек для одной сущности и по ним нужна фильтрация.
Данный метод подойдет и к хранению данных из checkbox-ов с последующим обращением к ним.
Также стоит заметить, что в реальной ситуации, при работе с крупными проектами такой подход, по моему мнению, не самый удачный, так как часто приходится разносить проекты на разные сервера. В таком случае, при достаточном уровне финансирования больше подходит вариант с промежуточным сервером для тестирования+система контроля версий(я использую mercurial).В таком варианте можно уже на уровне .htpasswd настроить доступ+ ip.
я так понимаю, можно использовать и POST запросы. а как передавать данные в POST?
Думаю, в случае создания законодательной базы, дыр в сайтах станет намного меньше.
По поводу замедления запросов в 10 раз: откуда такая цифра? Если проводились тесты- то на каких объемах данных? Со сколькими битами велась фильтрация? Я думаю, что говорить о быстродействии можно только в рамках конкретной задачи. Хотя Ваше замечание в некоторых случаях действительно верно.
К вопросу по индексам- не вижу проблем с созданием индексов при условии, что флаги меняются редко. Тогда запрос идет по одному поле, в отличие от нескольких полей в Вашем случае.
Например, мне нужно проверить, установлен ли определенный бит, вне зависимости от других. Описанный мною подход я обычно использую для определения определенных битов. Кроме того, может возникнуть ситуация, когда в запросе может оказаться несколько требований к флагам из разных мест. Например, часть требований заложены в моделе поумолчанию, в defaultScope, часть требований мы вводим через noBlock(), например. Еще часть закладываем напрямую в findAll() через параметры. Причем, эти параметры зависимые и изначально мы не всегда можем определить и найти комбинированные значения, которые предложены Вами. Т.к. В экшонах могут быть случаи, когда мы абстрагируемся от модели и не знаем, какая она будет и какие флаги в ней уже заложены и какие понадобятся…
Каждый флаг имеет свое название и свое место в битовой маске. А при вызове нужно указывать не цифру, а свойство-константу класса- тогда код будет читаем и понятен.
2 метода — это простая логика, с которой должен быть знаком как раз любой пятиклассник.
что касается метода фильтрации- то тут нужно знать как работать с CDbCriteria в Yii и как работать с той же булевой логиков в sql. Возможно, некоторые детали можно, а может, и нужно было написать по другому, тогда пишите, что не так.
Данный метод подойдет и к хранению данных из checkbox-ов с последующим обращением к ним.