1. Индексы рулят
2. Как только добавляешь вычисления в SELECT, производительность мускля сразу падает, он индексом не будет пользоваться
3. Подзапросы в Мускле сверхмеганеоптимальные, поэтому WHERE id>(SELECT MAX(id) FROM table)-20 — это пипец
А в чем проблема получения коммитов? Эти же коммиты не будут сразу вливаться в trunk
Google Code или GitHub — для того, чтоб иметь багтрекер какой-никакой и нормально уже настроенную систему контроля версий.
Далее. В trunk'е, например, висит текущая версия. Она же доступна для скачивания в виде .zip/.tar.gz с сайта. На этой же версии крутится demo системы
В ветке development идет собственно development. Туда приходят все коммиты от зарегистрированых в проекте пользователей (для этого и нужен хостинг на Гитхабе/гуглокоде, например)
Все приходящие коммиты рассматриваются хозяином проекта или устанавливается peer review, обкатка и т.п.
Как только достигли следующей версии, она сливается в транк, обновляется .zip/.tar.gz/demo
Оо. У нас тут каша понажористее :) Оставлю в качестве примера поставщика, хотя речь пойдет об агентствах. Но для идеи сойдет :)
Поставщик может выделять подюзеров с разграничением прав (например, бухгалтер может только смотреть отчеты по продажам услуг, а главный директор — изменять и добавлять услуги)
То есть поставщику надо иметь доступ к manage/users с хитро ораниченными правами (на самом деле — к отдельному модулю типа user/manage/users, чтобы не превращать код в кашу)
И туроператор может иметь несколько пользователей. Например (реальные примеры).
— Главный оператор имет доступ ко всем заказам всех агентств ко всем поставщикам
— Оператор Надя имеет доступ только к заказам от агентств А, Б, В
— Оператор Вера имеет доступ только к заказам от агентств Г, Д
— главный оператор ушел в отпуск и открыл оператору Свете временный досутп к заказам от агентств А, В и Ж — но только на чтние, а не на редактирование
:)))
То есть да, оно более-менее ложится на ACL или схемы, подобные ACL. Но когда это начинаешь кодировать… И воплощать в интерфейсе… Волосы становятся дыбом :) На спине :))))
ТО есть я жопу имл в виду, скорее, с этой стороны. Потому что начинают смешиваться ACL'и конкретных модулей с ACL'ями данных в базе (то есть, грубо говоря ACL'и логики с ACL'ями данных).
Увы, это подходит только для CMS, где можно четко разграничить пользователей и группы. А есть еще вариант, когда пользователю доступна на просмотр/редактирование только какая-то определенная запись из таблицы. То есть когда действия ограничиваются не только связкой module/controller/action, но и каким-то дополнительными ограничениями.
Например: туроператор-поставщик услуг
— туроператор может просматривать и изменять все данные где угодно
— поставщик услуг может изменять только данные своей услуги. То есть у него есть права на редактирование на manage/service/view|edit|delete, но только своих услуг
2. Как только добавляешь вычисления в SELECT, производительность мускля сразу падает, он индексом не будет пользоваться
3. Подзапросы в Мускле сверхмеганеоптимальные, поэтому WHERE id>(SELECT MAX(id) FROM table)-20 — это пипец
© «High Performance MySQL»
Есть проект: github.com/ngerakines/erlang_couchdb/tree
Мне захотелось в него что-то добавить. Я его форкнул: github.com/dmitriid/erlang_couchdb/tree/master
Добавил кой-чего: github.com/dmitriid/erlang_couchdb/commit/6cd2b690402215355600fd254e316ee18637a208
Отправил так называемый pull request участникам. Авторы залили изменения себе: github.com/ngerakines/erlang_couchdb/commits/master
В следующий раз я просто стяну с главной ветки произошедшие там изменения и буду вносить свои изменения и отсылать их авторам
Google Code или GitHub — для того, чтоб иметь багтрекер какой-никакой и нормально уже настроенную систему контроля версий.
Далее. В trunk'е, например, висит текущая версия. Она же доступна для скачивания в виде .zip/.tar.gz с сайта. На этой же версии крутится demo системы
В ветке development идет собственно development. Туда приходят все коммиты от зарегистрированых в проекте пользователей (для этого и нужен хостинг на Гитхабе/гуглокоде, например)
Все приходящие коммиты рассматриваются хозяином проекта или устанавливается peer review, обкатка и т.п.
Как только достигли следующей версии, она сливается в транк, обновляется .zip/.tar.gz/demo
Поставщик может выделять подюзеров с разграничением прав (например, бухгалтер может только смотреть отчеты по продажам услуг, а главный директор — изменять и добавлять услуги)
То есть поставщику надо иметь доступ к manage/users с хитро ораниченными правами (на самом деле — к отдельному модулю типа user/manage/users, чтобы не превращать код в кашу)
И туроператор может иметь несколько пользователей. Например (реальные примеры).
— Главный оператор имет доступ ко всем заказам всех агентств ко всем поставщикам
— Оператор Надя имеет доступ только к заказам от агентств А, Б, В
— Оператор Вера имеет доступ только к заказам от агентств Г, Д
— главный оператор ушел в отпуск и открыл оператору Свете временный досутп к заказам от агентств А, В и Ж — но только на чтние, а не на редактирование
:)))
То есть да, оно более-менее ложится на ACL или схемы, подобные ACL. Но когда это начинаешь кодировать… И воплощать в интерфейсе… Волосы становятся дыбом :) На спине :))))
ТО есть я жопу имл в виду, скорее, с этой стороны. Потому что начинают смешиваться ACL'и конкретных модулей с ACL'ями данных в базе (то есть, грубо говоря ACL'и логики с ACL'ями данных).
Например: туроператор-поставщик услуг
— туроператор может просматривать и изменять все данные где угодно
— поставщик услуг может изменять только данные своей услуги. То есть у него есть права на редактирование на manage/service/view|edit|delete, но только своих услуг
И тут начинается ж.па :)