Перейти к содержимому
Local
mac

Объединение баз данных двух биллингов Ubilling

Рекомендованные сообщения

Естественно, ip сети и города - разные, версии Ubilling - одинаковые.
Собственно, как это сделать максимально просто и безопасно?
 
То, до чего сам додумался - это использовать "Модуль Миграция 2"
Для это планирую сделать экспорт нужных полей из базы данных с помощью запроса


 

SELECT
  users.login, users.password, # login;password;
  users.ip, nethosts.mac, # IP;MAC;
  users.tariff, users.cash, users.Credit, users.CreditExpire, # tariff;cash;credit limit;credit expire date;
  city.cityname, # city;
  street.streetname, # street;
  build.buildnum, # build;
  apt.entrance, apt.floor, apt.apt, # entrance;floor;apt;
  phones.phone, phones.mobile, # phone;mobile;
  emails.email, # email;
  userreg.address, # address;
  realname.realname, # realname;
  contracts.contract, # contract;
  users.AlwaysOnline, users.Down, users.Passive  # AlwaysOnline state;Down state;Passive state
FROM
  city, street, build, apt, address, users, nethosts, phones, emails, userreg, realname, contracts
WHERE
  build.streetid = street.id AND
  apt.buildid = build.id AND
  address.aptid = apt.id AND
  address.login = users.login AND
  nethosts.ip = users.IP AND
  userreg.login=users.login AND
  realname.login = users.login AND
  phones.login=users.login AND
  emails.login = users.login AND
  userreg.login = users.login AND
  contracts.login = users.login
INTO OUTFILE '/tmp/ubilling.exp'
FIELDS TERMINATED BY ';'
ENCLOSED BY ''
LINES TERMINATED BY '\n'

 


По sql запросу вопрос прежде всего к уважаемому nightfly : оттуда ли (таблицы, поля) я беру значения?

Изменено пользователем mac

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

с такими вопросами....

ручками всё перенесите, вы ж наебнете себе всё без понимания что вы и куда суете

 

имена табличек похожи на правду, пробуйте на виртуалках, сдампите себе БД с первого и пробуйте перенести данные со второго

попутно проверяя всё ли в БД занеслось как надо и не ахуел ли старгейзер от таких манипуляций

Изменено пользователем l1ght

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, конечно на виртуалке испытаю сначала.

Просто глубоко не копал, что и где лежит.

Имена полей и таблиц - вроде как адекватны назначению.

Но могут же быть, типа, legacy, и не использоваться в новых версиях убилинга

В частности, смущает таблица users (оч много столбцов)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, конечно на виртуалке испытаю сначала.

Просто глубоко не копал, что и где лежит.

Имена полей и таблиц - вроде как адекватны назначению.

Но могут же быть, типа, legacy, и не использоваться в новых версиях убилинга

В частности, смущает таблица users (оч много столбцов)

users это то с чем работает старгейзер

 

почитайте FAQ, посмотрите видео в вики есть ссылочки

думаю станет понятнее, а вообще неиспользуемых табличек у нас нет

все важны и все нужны, стартовая позиция собрать все логины и IP из таблички users

это то по чему есть связь по всем остальным таблицам

соотвественно бабло (cash), кредит, имя тарифа, всё остальное живет в других табличках

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уже есть готовый SQL запрос выборки всех необходимых данных. Сейчас немного подкорректирую под миграцию 2 и вперед, если Вы желаете так переносить. А вообще вариантов масса.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уже есть готовый SQL запрос выборки всех необходимых данных. Сейчас немного подкорректирую под миграцию 2 и вперед, если Вы желаете так переносить. А вообще вариантов масса.

 

Ну что-то типа такого:

            SELECT 
                    `users`.`login`, `ip`, `mac`, `Tariff`,  `Cash`,  `Credit`, `CreditExpire`, 
                    `cityname`, `streetname`, `buildnum`, `entrance`, `floor`, `apt`,
                    `phones`.`phone`, `mobile`, `emails`.`email`, 
                    concat(`cityname`, ' ', `streetname`, ' ', `buildnum`, IF(`apt`, concat('/',`apt`), '')) AS `fulladress`,
                    `realname`.`realname`, `contract`, `AlwaysOnline`, `Down`, `Passive`                   
            FROM `users` LEFT JOIN `nethosts` USING (`ip`)
                    LEFT JOIN `realname` ON (`users`.`login`=`realname`.`login`)
                    LEFT JOIN `address` ON (`users`.`login`=`address`.`login`)
                    LEFT JOIN `apt` ON (`address`.`aptid`=`apt`.`id`)
                    LEFT JOIN `build` ON (`apt`.`buildid`=`build`.`id`)
                    LEFT JOIN `street` ON (`build`.`streetid`=`street`.`id`)
                    LEFT JOIN `city` ON (`street`.`cityid`=`city`.`id`)
                    LEFT JOIN `phones` ON (`users`.`login`=`phones`.`login`)
                    LEFT JOIN `contracts` ON (`users`.`login`=`contracts`.`login`)
                    LEFT JOIN `emails` ON (`users`.`login`=`emails`.`login`)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

l1ght, Pautiina, большое спасибо за советы и решения!

Pautiina, в вашем запросе в

`users`.`login`, `ip`,

пропущен `password`. Правильнее будет

`users`.`login`, `password`, `ip`,
Изменено пользователем mac

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Там еще данные по платежам, начислениям АП, нетхосты и куча потрохов других есть. Если логины юзеров, сети, и прочее такое не перекрываются, то в принципе, можно пробовать переносить данные в лоб. Проблема будет, только с адресами из "город-улица-дом", так как там куча связей по id, и хорошо бы писать для этого какой-то "заселятор" на пхп. Ненавижу такие штуки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ничего (логины юзеров, сети, и прочее такое) не перекрывается.

Т.к. сначала данные были в одном биллинге, потом их разделили на 2 (ломать - не строить).

Дальше они жили своей жизнью. И теперь из-за автоматизации платежей (opayz) их нужно объединить.

Nightfly, Ваше мнение понял, заселятор я не осилю, поэтому - или миграция, или вручную.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Nightfly, Ваше мнение понял, заселятор я не осилю, поэтому - или миграция, или вручную.

Ну по идее, какая-то из миграций должна пытаться угадывать, чего там делать с адресами. Точно не уверен - отродясь ими не пользовался. Кстати экспорт в ЦСВ-шку вроде был в "мастере отчетов".

Остальное да, можно переносить в лоб, тупо табличками.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

l1ght, Pautiina, большое спасибо за советы и решения!

Pautiina, в вашем запросе в

`users`.`login`, `ip`,

пропущен `password`. Правильнее будет

`users`.`login`, `password`, `ip`,

Пусть будет так :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Появились новые вопросы по "Миграции 2"

1. Когда создавать недостающие тарифы - до или после миграции?

2. В wiki есть рекомендация выключить stargazer перед миграцией. Но тогда перестает работать ubilling. Это как раз тот случай, когда нужно использовать опцию NOSTGCHECKPID ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. По идее до.

2. Да.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: pavlabor
      Вопрос дополнения базы данных и биллинга таблицей "все-ко-всем", продиктованы следующими потребностями.
      Есть модуль "Филиалы".
      При подключении данного модуля возникает следующая проблема.
      Не возможно подключить например город или филиалы для филиала, потому как филиал получает доступ ко всей информации о других филиалах.
      Нужно создать условия при которых филиал сможет самостоятельно вносить пользователей, адреса, вести склад при этом не видя информацию в материнской базе и других филиалах.
      Далее филиал не может создавать филиал.
       
      Такие задачи решаются созданием таблицы "все-ко-всем" в которой формируется каскадное вложение филиалов и связкой соответствующих таблиц сервисов.
      При правильном построении форм запроса и проверке на стороне сервера прав, филиал сможет получать доступ только к разрешенным ему модулям, и только его позициям в базе.
      Более того филиал сможет создавать свои филиалы, контролировать в них данные.
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
    • Автор: pavlabor
      Почитал вопросы возникающие вокруг работы ubilling и понял что проблемы связаны с архитектурой  Stargazer
      Насколько я понял проблем очень много, некоторые из них.
      Stargazer работает с базой в памяти и при параллельной работе с базой возникают конфликты с работой, например с внесением оплаты другим приложением.
      При остановке Stargazerа или биллинга идет сбой работы Насов.
      Текущая архитектура может стать ограничением по количеству возможно обслуживаемых клиентов.
       
      Проблемы не все, но этих достаточно чтобы задуматься о альтернативе написания эмулятора  Stargazer-а.
      Мое понимание, эмулятор должен выглядеть как модуль, который можно включить или выключить, или выбор работы или через Stargazer, или через внутренний модуль.
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
    • Автор: pavlabor
      Права, введение расширенной настройки прав.
      Предлагаю рассмотреть формирование и в перспективе реализации расширения следующих прав.
      Имеется, структурированное управление правами, которое не совсем закрывает потребность.
      Имеется.
      Объекты.
      - Модуль.
      - Позиция в модуле, юнит.
      Юзатели.
      - Филиалы.
      - Администраторы.
      Администраторы.
      - Стажер(демо).
      - Специалист.
      - Эксперт.
      Действия.
      - Просмотр.
      - Создание.
      - Редактирование.
      - Удаление.
      Собственно идея в чем. В оператора, или при создании филиала, администраторам могут быть переданы права на работу с модулем.
      В текущий момент, не имеется сквозной политики на права, поэтому они предоставляются выборочно и не совсем понятно по какой системе, по все вероятности "так получилось", как следствие, например.
      При создании филиала и передачи ему права на роботу с модулем город, то админ филиала может удалить город, изменить название, что может привести к проблеме у других филиалах и материнской структуре.
      При реализации единой политики, появляется необсуждаемая возможность и требование к модулям по правам.
      В связи с этим, определенный модуль можно делегировать/не делегировать филиалу, с определенными ограничениями, например филиал может просматривать, вносить города, но не может их редактировать или удалять.
      Внутри филиала, появляется возможность создавать профили уровней сотрудников не беспокоясь о состоянии базы, например создаеются
      - Стажер(демо).
      - Специалист 3 категории.
      - Специалист 2 категории.
      - Специалист 1 категории.
      - Эксперт.
      Взяли на работу чела, дали ему уровень стажера и пусть листает базу пока не прозреет,
      прозрел, дается профиль Специалиста 3 категории, и т.д.
      То же самое и с филиалами.
      Как админ филиала может завести пользователя, а выносить мозг дирекции тоже не каширно, вот и даются оговоренные права что админ филиала пользователя может завести, но редактировать и удалять не может, если другое не оговорено.
       
      Параллельно возникает вопрос с пользователями другого филиала, но этот вопрос будет рассмотрен в разделе "Требуется внесение таблицы "все-ко-всем".
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
       
    • Автор: cetim
      Если сменить view при формировании платежного ID , чем это чревато со стороны приема платежей (кроме недовольства пользователей) ?
    • Автор: kaisserhaff
      Всем привет, интересует такой вопрос, есть роутер установленный в точке А в отдельной сети, и есть ubilling в точке Б в отдельной сети с белым ип, на роутере активирована служба pptp и в этой службе имеется возможность авторизации пользователя по радиусу, сам вопрос в том можно ли подружить их между собой, если возможно то с помощью каких инструментов? С этим вопросом уже мучаюсь много времени, но не как не могу разобраться. Заранее спасибо
×