Биллинговая система Nodeny

Это информация сугубо для разработчиков модулей NoDeny.

Напоминаю, что в dopdata есть поле "ревизия", которое указывает на актуальный блок данных. Ревизий может быть несколько, актуальной считается имеющая самый большой номер для клиента, причем в заданном темплейте (шаблоне). Для выборки актуальных данных приходится писать не совсем тривиальные sql-запросы. Поэтому я решил слегка переработать концепцию.

Понятие ревизия остается, поскольку вещь очень полезная, не буду повторяться почему. Однако вводятся 2 положительных момента:

в dopdata для конкретного id клиента будет всего одна ревизия для всех шаблонов. Т.е. чтобы получить все актуальные данные можно будет сделать запрос: select * from dopdata where paret_id=xx. Заметьте, что все шаблоны будут иметь один номер ревизии, а не как раньше приходилось делать разные выборки для разных шаблонов.

Почему в запрос не попадут устаревшие данные и куда они вообще пропали? Для того, чтобы устаревшие данные не мешались, для них parent_id станет отрицательным, т.е. id клиента, но с минусом. Вообще эти данные вам врядли понадобятся, к ним будет доступ через админку по моим скриптам. Единственное, что придется сделать dopvalues транзакционной таблицей, поскольку придется юзать транзакции. Старая схема была интересна тем, что была абсолютно корректной в любом месте обновления данных, т.е. застрахована от сбоев при неиспользовании транзакций (сейчас я уже отхожу от этой идеи ибо Mysql уже нормально с ними работает). Но из-за этого труднее работать с конечным результатом. Я решил обменять эти условия местами

+1

а можно это сделать в текущей версии?

я уже говорил, что не буду апдейтить текущую версию.

Кстати, новая уже координально отличается от 50й. Как я уже говорил, абсолютно все поля (характеристики объектов (уже нет понятия  клиент, есть объекты - клиенты/роутеры/работники)) задаются через настраиваемые дополнительные. По умолчанию у объекта нет ничего кроме id и группы (таблица users состоит из этих двух полей, ха-ха). Группа задает то, что из себя представляет объект. Он может иметь логин/пароль/счет(а)/имя/трафик/время, а может ничего из вышеперечисленного.

а не надо апдейтить, мы сами поковыряемся ))
а то больно неудобно вложенными запросами доставать из допдаты данные )

всем привет,
сделал view как на картинке с максимальными ревизиями для поиска по адресу, вюха строится быстро.
Кто нибудь подскажет как выбрать все уникальные parent_id  с номером улицы И/ИЛИ дома И/ИЛИ квартиры?
Чета немогу ничего придумать.

Нипанимать вопроса!