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

Здравствуйте.

Кроме просмотра данных о клиенте в окне биллинга я (и наверное не только я) использую для анализа и статистики свои SQL-запросы.С выводом адресов и телефонов из USERS стало очень неудобно.  Верните,плз, адреса и телефоны в основную таблицу.Изменения по ним происходят крайне редко.Адрес клиента есть основная характеристика но не дополнительная.

Спасибо.

Согласен, вообще не понял, зачем их было в дополнительные данные переносить. Не... история... ревизия это все хорошо. Но адрес - это перебор ИХМО

Вернуть не сможем! перенос адреса в доп данные вполне разумно с точки зрения уменьшения нагрузки на базу данных

То что Адрес и телефоны хранятся в доп.даных неплохо. Может лучше отображение перенести в на страницу просмотра клиента.

Все таки так удобней. Может просто привычка!?

Позволю себе не согласится с этим. Приведите пример, при котором простой запрос на выборку будет более ресурсоемким чем составной или с объединением таблиц. Если можно, применительно к адресу клиента.

Вынос адреса и иных полей в дополнительную таблицу продиктован такими соображениями:

- невозможно (и не разумно) внести в таблицу users все поля, которые могут понадобиться конкретной сети. Например, недавно мы были в городе Новоднестровске, так там понятие "улица" вообще отсутствует. Зато есть микрорайоны. Есть сети, у которых обязательным параметром должно быть поле "город". Есть организации, которым до фени подъезд, этаж и телефон. Мы даем гибкую структуру, позволяющую настроить биллинг конкретно под себя. Вы можете создать несколько полей, хранящих, скажем несколько мак-адресов сетевых карт (допустим у клиента несколько компов и он так хочет, он платит) - создаем несколько полей mac-адреса и вуаля. Или еще реальный пример: в одной из сетей для доступа к статистике используется один пароль, а для авторизации иной, поскольку он прописан в модеме.

- единый интерфейс доступа к дополнительным полям по их алиасам, позволяет писать автономные скрипты, даже не вникая в структуру БД, просто в админке внеся новые поля заданной конфигурации.

- возможность в любой момент произвести откат к любой ревизии, просмотреть всю цепочку изменений.

Да, по-началу трудно воспринимать структуру дополнительных полей. Но если разобраться и записать в блокнотик примеры выборок, то работать с ними не составит труда.

просто вы рассматриваете задачу слишком узко. С таблицей users работает ядро, сателлиты и т.д. Там идут постоянные выборки. Минимализация объема users - важная задача в таких условиях. Также учтите, что апдейты таблиц существенно сказываются на производительности выборок.

Тогда помогите.
Дайте пример эффективного запроса для вывода в одной таблице данных клиента:

SELECT ID,IP,FIO,улица,дом,квартира,телефоны

Спасибо.

или например получение только дома:

Получение одной из позиций не вопрос.
Покажите как выбрать одновременно много позиций из DOPDATA в одну таблицу одним запросом

Для чего это надо.
Монтажной бригаде совершенно не обязательно видеть всю базу биллинга.
Но видеть заявки на ремонт и подключения видеть необходимо.
При этом такие таблицы удобны в виде представлений,дабы не публиковать всю базу в интернете.

надо было потратить 10 секунд на проверку того, что я написал выше и убедиться, что 1й запрос выдает все данные

Доп данные имеют такое понятие как темплейт, напримпер темплейт адрес, темплейт технические данные, темплейт паспортные данные и инн клиента, темплейт данных юридического лица
Теперь вопрос приведите мне пример задачи которая потребует вывода всех данных со всех темплейтов одним запросом?
Ну и как ответили выше просто внимательнее читать надо! первый же запрос выводил все данные из темплейта где алиас доп данных начинается с _adr_! Этого достаточно что бы вывести адрес и телефон клиента одним запросом!

Хотя кто их читает те запросы!

И всё-таки я настаиваю:
покажите как вывести всю таблицу USERS (или её часть по признаку cstate =2)
с указанными дополнительными параметрами.
При этом подразумевается что АЙДИ_КЛИЕНТов постоянно меняются и в момент запроса не известны  

Для чего это надо.
Монтажной бригаде совершенно не обязательно видеть всю базу биллинга.
Но видеть заявки на ремонт и подключения видеть необходимо.
При этом такие таблицы удобны в виде представлений,дабы не публиковать всю базу в интернете.

я думаю с вашими знаниями SQL вам лучше обратится не на форум, а на тематический ресурс
http://dev.mysql.com/doc/refman/5.0/en/,  мы ж НЕ обучаем работе с базой данных! за отдельные деньги я могу сделать для вас исключение  50-100 баксов за запрос
Ну или обучить поиску на форуме за каких то жалких 30 баксов

я так понимаю вашей монтажной бригаде просто жизненно необходимы данные о паспорте и инн пользователе о закрытом порте 25 и расчетном счете организации ?

Правильно ли я понял,-это сделано именно с этой целью?

А диалог мне напомнил классику:

- О.Бендер. "А что отец,есть ли в городе невесты?"
- Дворник.  "Кому и кобыла невеста."
- О.Бендер. "Вопросов больше не имею"

Спасибо

Не надо утрировать.
Что нужно монтажнику я указал конкретно

SELECT ID,IP,FIO,улица,дом,квартира,телефоны

Это сделано с целью оптимизации базы данных к растущему потреблению ресурсов! Перечитай всю ветку с начала! ради того что ты не можешь/не хочешь изучать SQL  мы должны вернуть тормоза в ядро ?

Отвечу в вашем духе
-Может всё-таки возьмёте частями?
-Я бы взял частями. Но мне нужно сразу.

Все и на шару не бывает! Либо поиск либо учится либо платить деньгами