Биллинговая система Nodeny
29 Сентября 2024, 09:33:23 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Прекращена поддержка версии Nodeny 49
 
   Начало   Помощь Поиск Войти Регистрация  
Страниц: [1] 2
  Печать  
Автор Тема: Вопрос по структуре БД  (Прочитано 8267 раз)
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« : 30 Апреля 2011, 15:27:52 »

Добрый день.
Подскажите пожалуйста, назначение некоторых полей в БД Nodeny v50
Таблица users -  paket3,  next_paket3
Записан
0xbad0c0d3
гуру nodeny )
NoDeny
Спец
*

Карма: 116
Offline Offline

Сообщений: 1059



Просмотр профиля
« Ответ #1 : 30 Апреля 2011, 16:45:23 »

Дополнительный пакет
Записан
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« Ответ #2 : 04 Мая 2011, 09:55:20 »

Можете подробнее расказать про таблицу
dopvalues
Я так понимаю:
line_id - просто id записи
parent_id - id user к которому относятся эти записи.
dopfield_id - соответствует id в таблице dopfields
field_value - значение для дополнительного поля
admin_id - Поле, кто добавлял
time - timestamp
revision - ?

Что такое revision? Для чего это поле?

Также есть таблица rev_users. Для чего она? Что будет если добавить пользователя скриптом и не добавлять никаких данных в rev_users?
Записан
VitalVas
NoDeny
Спец
*

Карма: 60
Offline Offline

Сообщений: 991



Просмотр профиля WWW
« Ответ #3 : 04 Мая 2011, 10:11:20 »

dopfields - содержит описания дополнительных полей:

 id      - идентификатор поля
 template_num   - номер шаблона
 parent_type   - с каким объектом ассоциируется поле. 0 - с клиентом
 field_type   - тип поля: целое, строковое, да/нет и т.д.
 field_name   - имя поля
 field_alias   - алиас имени
 field_flags   - строка флагов: убирать ли лидирующие/завершающие проблелы,
        включить транслитерацию, привести к нижнему регистру и т.д.
 field_template   - регулярное выражение для проверки корректности заполнения поля
 comment   - комментарий


dopvalues - содержит данные дополнительных полей:

 parent_id   - хозяин данного параметра, например id абонента
 dopfield_id   - ссылка на описание параметра в таблице dopfields (по полю id)
 field_value   - значение параметра
 admin_id   - id администратора, внесшего/изменившего данные
 time      - timestamp создания/изменения данных
 revision   - номер ревизии, чем больше тем актуальнее
Для разных parent_id ревизия всегда разная.
« Последнее редактирование: 04 Мая 2011, 10:13:40 от VitalVas » Записан
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« Ответ #4 : 04 Мая 2011, 10:44:28 »

Cпасибо!
Если идет добавление пользователя через скрипт (перенос абонов из другого биллинга),
то какую ревизию нужно выставлять для этих дополнительных полей?
Можно ли просто выставить всем версию ревизиюи 1, или она каким то образом вычисляется?

Нужно ли заполнять таблицу rev_users при добавлении нового пользователя? Я так понимаю она служит для указания какая версия дополнительных полей актуальна для для пользователя с user.id = rev_users.id ?

Еще вопрос по поводу оплат...
Если переносится абонент, у которого оплачено несколько месяцев, то достаточно ли просто указать соответствующую сумму в users.balance или нужно еще что-то добавлять по таблицам?
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4787



Просмотр профиля
« Ответ #5 : 04 Мая 2011, 12:41:46 »

Ревизия должна быть уникальна не только в пределах одного юзера, а для всех клиентов. В самом NoDeny номер ревизии формируется таким образом: в dopvalues вставляется пустая запись (parent_id=0). Mysql после вставки возвращает last_insert_id, который берется из поля line_id - это и есть номер ревизии. С этим номером вставляются все данные для текущего клиента, удаляется пустая запись. Такая схема используется для того, чтобы гарантировать уникальность ревизии т.к. если сделать select max(revision)+1, а потом делать Insert, то если параллельно какой-либо админ сделает ту же самую операцию, то с некоторой вероятностью мог бы возникнуть конфликт ревизий.

Если же переносить данные из другого биллинга, то можно завести переменную "номер ревизии" и инкрементить ее после вставки блока данных для каждого юзера.

Важно. Схема с ревизиями замедляет работу, поэтому в 49.33 и 50.33 ревизий нет в dopvalues, т.е в этой таблице всегда актуальные значения. А ревизии хранятся в другой таблице, которая нужна чисто для  history. 50.32 и 50.33 практически только этим и отличаются
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4787



Просмотр профиля
« Ответ #6 : 04 Мая 2011, 12:44:28 »

Если переносится абонент, у которого оплачено несколько месяцев, то достаточно ли просто указать соответствующую сумму в users.balance или нужно еще что-то добавлять по таблицам?
Да. В таблице pays создать бонусный платеж с комментом "перенос баланса с другого биллинга" на сумму баланса. Причем отрицательные таким же образом
Записан
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« Ответ #7 : 04 Мая 2011, 14:18:11 »

Спасибо!
Вопрос по таблице pays
При добавлении платежа по конкретному пользователю. Непонятны значения некоторых полей.
id   id записи в таблице.
mid   соответствует user.id
cash   Сумма на счет (она же падает в баланс абона)
time   timestamp
admin_id соответствует admin.id
admin_ip Вычисляется по группам цифр ip. $1*16777216 + $2*65536 + $3*256 + $4
office   Непонимающий
bonus   Непонимающий
reason   Просто вставить текст "перенос баланса с другого биллинга"
coment   Коментарий который видит абонент
type   Непонимающий
category   Непонимающий
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4787



Просмотр профиля
« Ответ #8 : 04 Мая 2011, 14:29:16 »

из tables.html:
Цитировать
id      - уникальный id записи;
 mid      - id клиента (см. таблицу users);
 cash      - денежная сумма, для всех нефинансовых записей = 0;
 time      - время формирования записи, timestamp;
 admin_id   - id администратора (см. табл. admin), который сформировал запись,
        если запись сформировал клиент или система (например, ядро) = 0;
 admin_ip   - ip администратора/клиента с которого было произведено
        формирование данного события. Для ядра = 0, что соответствует 0.0.0.0,
        ip упаковывается в 4 байта;
 office      - номер отдела, в котором работает админ сформировавший запись.
        Для ядра и клиентов = 0;
 bonus      - для финансовых платежей указывает безналичный ли платеж;
 reason      - многофункциональное поле. В зависимости от типа платежа (type) и
        категории (category) может являться:
   - комментарием для администратора, если запись является сообщением;
   - информацией о каком-то событии, например, какие поля в учетной записи были изменены;
   - закодированным событием, например, данные о работе.
 coment      - многофункциональное поле. Обычно хранит сообщение для клиента.
 type      - тип записи: платеж, событие, сообщение, передача наличных;
 category   - категория платежа, более детально сообщает о внутреннем устройстве
        текущей записи.


Поле type может принимать строго такие значения:

10 - платеж клиента;
20 - временный платеж;
30 - сообщение/комментарий клиенту;
40 - передача наличных;
50 - событие.

Типы 10 и 20 являются финансовыми платежами, т.е влияют на состояние счета клиента. Сумма всех платежей с типами 10 и 20 строго соотвествует значению поля balance в таблице users. При добавлении/удалении платежей с типом 10 и 20, система модифицирует поле balance.

Для записей с кодом 30 и 50, поле cash должно быть всегда равным 0.

Тип 40 является внутренней проводкой, указывающей на перемещение наличности от одного администратора к другому. В поле reason должен быть указан id администратора передающего наличные, а в поле coment - принимающего наличные.

Поле bonus, установленное в значение 'y' указывает на то, что платеж безналичный. Для типа 20 всегда bonus='y'.

Тип 30 указывает на то, что запись является либо сообщением либо комментарием. Чем именно скажет поле category.

Тип 50 наиболее обширный в описании. Как обычно, поле category регламентирует действие записи с типом 50.

В файле paystype.pl прописаны действия, которые необходимо применить для расшифровки поля reason для определенных категорий событий.
Записан
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« Ответ #9 : 04 Мая 2011, 14:45:42 »

Коротко и понятно. Спасибо!
Записан
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« Ответ #10 : 12 Мая 2011, 09:34:24 »

Переношу пользователей из старого биллинга.
Не пойму в чем проблема...
Нужно перенести текущее состояние абонента (т.е. если у него текущий месяц оплачен, то просто пренести с нулевым балансом;
Если оплачено несколько месяцев, то положить соответствующую сумму на баланс. Если пользователь отключен, то так и переносим отключенным. Отрицательных балансов нет.)
Все нормально, за исключением первого варианта.
Выполняется следующий запрос:
Код:
INSERT INTO users
                        SET
                        ip='172.xx.xx.xx',
                        name='139/3',
                        passwd=AES_ENCRYPT( '3ba0d4ce','hardpass3$'),
                        grp='1',
                        mid='0',
                        contract='1024',
                        contract_date= '0',
                        state= 'on',
                        auth= 'no',
                        balance= 0,
                        money='0',
                        limit_balance='0',
                        block_if_limit='1',
                        sortip= '321321',
                        modify_time=unix_timestamp(),
                        fio= 'Пупкин В.В.',
                        srvs='0',
                        paket= '25',
                        next_paket= '0',
                        paket3='0',
                        next_paket3='0',
                        start_day='0',
                        discount='0',
                        hops='0',
                        cstate='0',
                        cstate_time=unix_timestamp(),
                        comment='',
                        lstate='1',
                        detail_traf='0'
Но почему-то у абона потом появлятся отрицательный баланс и соответственно его отключает.. В таблице pays система автоматом проводит снятие с cash=0.00, type=50 и category=423.
При этом если добавляется другой абон с ненулевым балансом и соответственно платеж в pays, то ничего больше не снимается и абон продолжает работать...
Подскажите пожалуйста с чем может быть связана проблема...
Что делается не так?
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4787



Просмотр профиля
« Ответ #11 : 12 Мая 2011, 10:43:27 »

Поле баланс - баланс клиента без стоимости услуг текущего месяца. Если день последнего платежа меньше текущего числа, то биллинг работает по предлоплате, следовательно сначала деньги потом стулья. Это все означает, что нулевой баланс - это состояние "денег нет для оплаты текущего месяца"
Записан
HEDG_SS
NoDeny
Пользователь
*

Карма: 0
Offline Offline

Сообщений: 48


Просмотр профиля
« Ответ #12 : 12 Мая 2011, 12:21:10 »

Понял, спасибо за пояснения
Записан
Elisium
NoDeny
Старожил
*

Карма: 19
Offline Offline

Сообщений: 360


На форумах "спасибом" называется плюс к карме.


Просмотр профиля
« Ответ #13 : 06 Июля 2011, 10:49:59 »

Апну тему.
Есть таблица users, в ней есть поле sortip.
В доке написано
Код:
sortip		- используеся при сортировки записей по ip;
Стоит задача переноса юзеров из одного билля в другой.
Как формируются данные в этом поле ? Можно ли его поставить в "0" ?
Записан
versus
Администратор
Спец
*****

Карма: 21
Offline Offline

Сообщений: 845


44306843
Просмотр профиля WWW Email
« Ответ #14 : 06 Июля 2011, 11:34:00 »

Код нодени нам говорит так:

Код:
 
if ($test_ip!~/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/ || $1>255 || $2>255 || $3>255 || $4>255)
 $sortip=$2*65536 + $3*256 + $4;

Записан
Страниц: [1] 2
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!