Ну а что тут такого?
Задачи-то разные бывают.
Вот например, надо отдавать какую-то простую динамику. Можно навернуть nginx и всякое, а можно повесить php демона на порт и отдавать им.
Я уверен в том, что простой функционал: прочитать из порта, обработать и отдать в порт реализуется на большенстве языков одинакого. А так же работает с той же скоростью.
В рамках обычного виртуального хостинга (не jail, не VPS и т.п.) можно лишь обрубать скрипты по времени. Поставить, к примеру, что любой скрипт/запрос к базе выполняется не более одной секунды. Всё что больше отключать. Но это вызовет массу негодований со стороны пользователей.
Как видно из скриншота, пхп запускается в режиме CGI, скорее всего через suPHP.
В этом случае на файл сессии ставятся права 0600, что исключает возможность чтения/записи другими пользователями.
Можно я ещё покритикую?
Лучше сделать ваши экшны user_edit, user_delete и т.п. не строчками, а дефайнами.
Это позволит уже на этапе компиляции видеть ошибки синтаксиса. И позволит избежать долгой отладки для ошибок набора вроде user_edlt и т.п.
Хорошо, храните в нескольких, никто вам не мешает.
Я и не настаивал на том что всё должно хранится в одном поле, а приводил такую ситуацию как возможный пример.
А дальше всё зависит от архитектуры.
varchar(1024) появилось как результат предложения одного из участников беседы, что есть ограничения на длину (почитайте внимательно первый пост этого треда).
Зачем вы теперь про него везде говорите, мне не понятно.
Вы троль?
Из примеров что я приводил, достаточно ясно следует что позиция нужного бита мне за ранее известна.
Длину маски контролировать нет нужды. Она никак не связана с позицией нужного бита, это следует из примеров и вышесказанного.
Да, одно из ограничений битовых масок, плохая читаемость человеком.
Уже нельзя открыть базу и быстро понять по выборке какие есть права у человека.
Но, как показывает опыт, задача хранения прав решается однократно. Плюс, если сильно хочется, можно легко написать скриптик, который будет делать выборки из базы по нужным условиям.
Не столько однобоко, это как?
Индексы поведут себя замечательно.
А что за bitmap-индексы? И какой идеи они противоречат?
Скажите, а вы понимаете что способ хранения прав в битовых масках и ваш способ — одинаков по сути?
Различия в том, что вы храните права в одном байте, а я предлагаю хранить в одном бите.
Вы предлагаете плодить записи в таблице, я предлагаю сохранять все права в одной записи (читай атомарность).
Способ, который я предлагаю — компактнее, только и всего.
Видимо вы, как и другие критикующие, не потрудились разобраться в том, что именно я предлагаю и говорите ерунду.
Т.е. вы указываете на ситуацию что добавляя права, вы не будете знать каким битом это сделано?
Каждое право записывается своим числом. И ситуация которую вы описали не возможна.
Может вам станет понятнее если вы переведёте число из двоичного кода в десятичный код.
Поиск по объектам делается через битовые операции.
Вы попробуйте написать небольшую програму на php и посмотреть что получается. А то у меня складывается ощущение что вы критикуете то, что никогда не пробовали делать. Отсюда и такие ошибки.
Я может что-то и не понимаю. Зачем контролировать длину маски?
Вы про битовые операции читали? XOR, OR, AND?
Добавлении бита слева никак не повлияет на предыдущие проверки.
Попробуйте сами проверить, в том же калькуляторе.
Пример с «А должно быть» вообще не понял. Почему вы решили что будет так? Откуда взялся ноль?
Да всё просто.
00000001-- чтение сообщений
00000010 — добавление сообщений
00000100 — апрув новых сообщений
00001000 — удалить сообщение
00010000 — редактировать сообщение
Можно ввести группы в эти права, а можно хранить их отдельно.
Сути это не изменит.
Если мы будем хранить права в отдельной табличке/в коде:
00000001 — гости
00000011 — пользователи
00000100 — супервизоры
00001011 — модератор
00011111 — администратор
Как проверять на принадлежность группе, я писал выше.
Ваш вопрос не очень понятен.
С точки зрения хранения, группы и операции никак не различаются.
Сделайте для групп отдельные биты и всё будет работать.
Скажем так (двоичный код):
00000001 — операция1
00000010 — операция2
00000100 — операция3
00001000 — операция4
00010000 — доступ_к_объекту_1
00100000 — доступ_к_объекту_2
01000000 — членство_в_группе_1
10000000 — членство_в_подргуппе_1_группы_1
и т.п.
Затем вам надо будет в запросе писать WHERE `code` AND `нужное_вам_условие`
Само условие можно так же формировать из битов.
Какое ограничение на длину?
Почему не слепить группы?
Что мешает под них отдельное поле в таблице выделить, точно так же с битовой маской?
Или отдать под группу один из разрядов в существующей битовой маске.
Задачи-то разные бывают.
Вот например, надо отдавать какую-то простую динамику. Можно навернуть nginx и всякое, а можно повесить php демона на порт и отдавать им.
Я уверен в том, что простой функционал: прочитать из порта, обработать и отдать в порт реализуется на большенстве языков одинакого. А так же работает с той же скоростью.
В этом случае на файл сессии ставятся права 0600, что исключает возможность чтения/записи другими пользователями.
Что в этом случае — зло.
Лучше сделать ваши экшны user_edit, user_delete и т.п. не строчками, а дефайнами.
Это позволит уже на этапе компиляции видеть ошибки синтаксиса. И позволит избежать долгой отладки для ошибок набора вроде user_edlt и т.п.
Я и не настаивал на том что всё должно хранится в одном поле, а приводил такую ситуацию как возможный пример.
А дальше всё зависит от архитектуры.
Зачем вы теперь про него везде говорите, мне не понятно.
Вы троль?
Длину маски контролировать нет нужды. Она никак не связана с позицией нужного бита, это следует из примеров и вышесказанного.
Да, одно из ограничений битовых масок, плохая читаемость человеком.
Уже нельзя открыть базу и быстро понять по выборке какие есть права у человека.
Но, как показывает опыт, задача хранения прав решается однократно. Плюс, если сильно хочется, можно легко написать скриптик, который будет делать выборки из базы по нужным условиям.
Не столько однобоко, это как?
Индексы поведут себя замечательно.
А что за bitmap-индексы? И какой идеи они противоречат?
Различия в том, что вы храните права в одном байте, а я предлагаю хранить в одном бите.
Вы предлагаете плодить записи в таблице, я предлагаю сохранять все права в одной записи (читай атомарность).
Способ, который я предлагаю — компактнее, только и всего.
Видимо вы, как и другие критикующие, не потрудились разобраться в том, что именно я предлагаю и говорите ерунду.
Каждое право записывается своим числом. И ситуация которую вы описали не возможна.
Может вам станет понятнее если вы переведёте число из двоичного кода в десятичный код.
Поиск по объектам делается через битовые операции.
Вы попробуйте написать небольшую програму на php и посмотреть что получается. А то у меня складывается ощущение что вы критикуете то, что никогда не пробовали делать. Отсюда и такие ошибки.
Вы про битовые операции читали? XOR, OR, AND?
Добавлении бита слева никак не повлияет на предыдущие проверки.
Попробуйте сами проверить, в том же калькуляторе.
Пример с «А должно быть» вообще не понял. Почему вы решили что будет так? Откуда взялся ноль?
00000001-- чтение сообщений
00000010 — добавление сообщений
00000100 — апрув новых сообщений
00001000 — удалить сообщение
00010000 — редактировать сообщение
Можно ввести группы в эти права, а можно хранить их отдельно.
Сути это не изменит.
Если мы будем хранить права в отдельной табличке/в коде:
00000001 — гости
00000011 — пользователи
00000100 — супервизоры
00001011 — модератор
00011111 — администратор
Как проверять на принадлежность группе, я писал выше.
Обновите только маски тех объектов для которых эта новая группа введена.
С точки зрения хранения, группы и операции никак не различаются.
Сделайте для групп отдельные биты и всё будет работать.
Скажем так (двоичный код):
00000001 — операция1
00000010 — операция2
00000100 — операция3
00001000 — операция4
00010000 — доступ_к_объекту_1
00100000 — доступ_к_объекту_2
01000000 — членство_в_группе_1
10000000 — членство_в_подргуппе_1_группы_1
и т.п.
Затем вам надо будет в запросе писать WHERE `code` AND `нужное_вам_условие`
Само условие можно так же формировать из битов.
Почему не слепить группы?
Что мешает под них отдельное поле в таблице выделить, точно так же с битовой маской?
Или отдать под группу один из разрядов в существующей битовой маске.