BiTel

Вопрос по структуре таблиц user_login и user_alias или иначе говоря Где используется номер логина?
Разбирался со струткрой бд, планировал заранее забить табличку с алиасами, чтобы при заведении договора (по шаблону там создается логин) сразу к логину был привязан уже забитый в бд алиас.
Был несколько удивлен, когда увидел, что привязка в таблице юзер_алиас идет не к полю логин таблицы юзер_логин, а к индексному полю. Видимо я где-то не понимаю логики. Зачем тогда это поле логин нужно вообще? (1й аттач)
Тем более это поле (login) еще и не редактируемое. (2й аттач)

ps Кстати, интересная штука еще вспылал во время экспериментов - скопировал старый запрос инсерта в юзер_алиас, login_id поменял, а алиас забыл изменить... При редактировании через интерфейс клиента при совпадении алиасов он выдает ошибку. Тут же - инсерт выполнился и у меня в базе оказались два договора с разными логинами, но одинаковыми алиасами. Что-то мне кажется так не должно быть. Может поле login_alias сделать уникальным, чтобы уже даже на уровне БД не давало писать в нее повторяющиеся записи?

Система ориентирована на использование ЦИФРОВЫХ ЛОГИНОВ, которые генерируются автоматически или берутся из предоплаченных карт. Алиасы используются как дополнительные индификаторы к цифровым логинам. Когда программа получает алиас она находит соответствующий ему цифровой логин и проводит проверку.

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

А если вы закроете логин у одного товарища и откроете у другого с новой даты но с таким же алиасом?

Хм.. такой вариант я не рассматривал =) Мы логины повторно не используем. Но теперь логика понятна. Спасибо =)

помнится я выкладывал скрипт создающий алиас = номеру договора, м.б. это то что Вам подойдет? ну или подправьте его как Вам удобно

вопрос возник когда я и разбирался куда что пишется и что как линкуется =) чужие скрипты хорошо, но надо разбираться почему и как работает =)
основательно помог еще ваш скрипт из темы по миграции с биллингов, где заведение клиентов sql запросами кстати, раз уж зашел разговор про это, а управление айпишниками похожим образом реализовывали? у нас статика пока что. при заведение с указанием реалмов вообще все красиво, но это будет позже. на первых порах придется работать со статикой, и хотелось бы тоже чтобы при заведение автоматом хватался следующий свободный айпишник, как и в случае с алиасами/логинами

а чего разбираться? на dbinfo.bitel.ru все расписано


управление адресами проще всего сделать на бумажке как я собственно это и сделал (у меня очень мало статических адресов), т.к. в dialup, в отличие от ipn никакого механизма управления адресами, ЕМНИМП, нет, а жаль

никто с этим и не спорит документированность базы - одна из причин выбор бгбиллинга была =) но одно дело что оно где-то расписано, а другое что ты сам повносил значения и _понял_ что от чего зависит.

ну будет надеяться что появится, а пока ручками доделывать самим, благо функционал позволяет по человечески дотачивать