Интересная дискуссия получилась однако
Прокомментирую то, что знаю

PNC>>>А что вам в нем не нравилось?
M>>Ну это взгляд со стороны EndUser-а, как пользователя MTS со стажем. Вечно какие-то мелкие накладки и, похоже, принципиальная невозможность получить актуальное состояние счета сразу после совершения некоего действия влияющего на оный счет.

PNC>Ааа! Это опять про "непонятный баланс". Пора уже раз и навсегда объяснить суть этой проблемы:

PNC>Начну издалека: абоненты сотовых сетей делятся на 2 категории — предоплаченные и кредитные. Первые могут пользоваться услугами связи только до тех пор, пока на их счете есть средства. Вторые пользуются услугами связи сколько угодно, а в конце месяца оплачивают выставленный счет.

PNC>Для того, чтобы на счетах предоплаченных абонентов не появлялись отрицательные остатки, используются prepaid — системы и специальные коммутаторы. Коммутатор отличается от обычного тем, что перед звонком запрашивет по специальному протоколу prepaid-систему достаточно ли у абонента средств для звонка и на какую длительность звонка этих средств хватит. Prepaid-система при получении такого запроса, выполняет расчет разрешенной длительности соединения исходя из баланса абонента и его тарифного плана. По окончании звонка коммутатор уведомляет prepaid-систему о длительности совершенного звонка, prepaid-система списывает средства со счета абонента. Побочным эффектом такой системы является возможность в любой момент времени узнать свой баланс и он будет аббсолютно точным, с учетом даже самого последнего недавно завершившегося звонка. Характерная задержка между окончанием звонка и попаданием его в систему — порядка одной секунды.

Не совсем так. Есть предоплаченные, контрактные и кредитные Предоплаченные — предактивированные, типа МТС Джинс. Контрактные — обычные абоненты. Кредитные — это те, кто говорит в кредит.
Про "специальные" коммутаторы не слышал, мне кажется, это преувеличение. Тут вопрос именно в биллинге, так как с, наверное, любого современного коммутатора можно запросить данные в любой момент времени. А баланс он в базе, а не на коммутаторе, хранится.
В известной мне системе дело происходит так:
При запросе соединения с коммутатора отправляется запрос к системе. При наличии денег связь разрешается, соединение устанавливатся. Каждые 10 секунд приходит повторный запрос... Вероятно, существуют несколько иные способы реализации Real Time Billing, но, думаю, суть не шибко меняется.

PNC>При обслуживании кредитных абонентов схема совсем другая. Используется значительно более дешевый коммутатор, prepaid-системы нет. Коммутатор время от времени выгружает файлы, содержащие информацию о совершенных звонках. Этот файл проходит длинную цепочку обработки и загружается в биллинговую систему. Как легко видеть, в такой ситуации узнать актуальный баланс практически невозможно. Более того, поскольку цепочка достаточно длинная, возможно возникновение длительных задержек между окончанием звонка и попаданием информации в биллинговую систему. Но, при обслуживании кредитных абонентов это не играет большой роли, поскольку deadline для загрузки всех звонков в систему — это начало следующего биллинга и формирования счетов абонентам. Характерное время — порядка двух недель...

Опять неправда ( в общем) . Коммутатор, все-таки, может быть один. Но при не Real-time billing информация о звонке закачивается с коммутатора после окончания разговора, причем, как правило, не сразу, а по таймеру оптом. скажем, раз в 10 минут. Происходит оценка, при этом изменяется текущий баланс, который можно узнать. Двумя неделями тут не пахнет. Про CBOSS, навреное, вы лучше знаете, но 2 недели это какая-то дикость.

К сожалению, про RTB от CBOSS я ничего не знаю, сказать нечего. Я про биллинг карманной конторы, о которой ты ниже писал...

PNC>Не уверен, что эта стратегия МТС была совсем неправильной — малыми средствами им удалось отвоевать лидирующие позиции в стране, но имидж был подпорчен... Сейчас МТС закупила все необходимое оборудование, prepaid-систему и... другой биллинг. Для нас, сотрудников CBOSS, это было немного обидно — мы делали все, что могли, помогали экономить, продвигаться, а сейчас оказались не у дел...

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

Здравствуйте, denisio_mcp, Вы писали:

A>>ну это типа риал таим биллинг..
A>>Но на эту систему тока переходят пока. Кое где перешли поболее, где-то поменее.

_>Единсвтенный реалтайм биллинг — это у билайн. Там отрубить телефон могут прямо во время разговора, если деньги кончаются в процессе... У остальных идет постобработка после звонка.
Неправда, есть еще у МТС такое дело. Не на всех тарифах и не совсем везде, правда. Но повторюсь: ИМЕЕТСЯ.

Попробую еще тут поумничать...

Здравствуйте, PNCHL, Вы писали:


PNC>Причины 2:
PNC>1) FK снижают производительность DML-операций. Эффект достаточно сильный — достаточно подсчитать количество дисковых чтений для каждой операции.

PNC>Например, удаление из таблицы:
PNC> а) Если на ней нет FK и запись удаляется по RowID, то перед удалением выполняется одно дисковое чтение (может быть и больше, но это другая история).
PNC> б) Если на ней есть FK, то дополнительно производится индексный поиск по ссылающейся таблице. Индексный поиск — это, как минимум еще одно дисковое чтение. Если же ссылающаяся таблица большая, то количество дополнительных чтений больше 1, порядка ceil(ln(table_rows_count)/ln(block_size/index_row_size)).Обычно базы создают с размером блока 4 Кб, так что для таблицы с 10 млн. записей и размером записи в индексе порядка 20 байт получается 3-4 дополнительных чтения. Итого, замедление будет в 2-5 раз.


PNC>Конечно, на самом деле, общее снижение производительности системы не будет таким большим, поскольку в системе выполняются не только DML, да и DML-это не только работа с диском и по RowID... Но для систем, обслуживающих несколько миллионов абонентов, снижение производительности операций даже на 10%, означает дополнительные затраты на оборудование в несколько сотен тысяч долларов. Для клиента это прямые потери — неоткрытые дополнительные офисы обслуживания, непроведенные рекламные кампании и т.д...

С этим не поспоришь. Но скажите, сколь часто в CBOSS происходит операция удаления? На самом деле, я подозреваю, что ж0сткие вставки идут только в таблицы звонков, и всё. Всё остальное делается гораздо реже и гораздо более вручную. ТАк что, боюсь, 10% это ооочень большое преувеличение.
Долой ключи и индексы по трафику, кроме индекса по приложению обслуживания... что и есть везде.



PNC>2) Почитайте документацию про "объектную модель CBOSS", особенно про версионность — каждый объект представлен в таблице несколькими записями, все с одинаковым суррогатным ключем, но разными "сроками жизни". Соответственно ссылка на объект не то же самое, что ссылка на строку в таблице — FK неприменимы.
Может, стоило добавить таблички, содержащие, скажем, список всех ОСНОВНЫХ объектов данного типа БЕЗ истории, и исторические — как их расширения?
Например, табличка App (App_id, -- какие нибудь параметры неизменные--)
и App_histories(App_id$$FK, fd,td)
Да,это лишняя табличка, линшине десятки мегабайт дискового массива. На проивзодительности сказаться не должно особо, абонентытакими темпами не добавляются в базу, чтоб ее поломать Зато будет целостность, какая-никакая.



A>>Кроме того, из-за прикольной системы именования столбцов, довольно трудно вникнуть в устройство базы.

PNC>Все столбцы в таблицах именуются согласно CBOSS-овским стандартам. Они, как раз помогают вникнуть в устройство базы. Хотя, конечно, разобраться непросто — таблиц порядка 3000...

воот эти стандарты мне и не очень хорошими показались. Коненчо, не отвратительными Но .. видите ли, очень ТРУДНО понять. на ЧТО идет ЛОГИЧЕСКАЯ (воображаемая на уровне приложения) ссылка по полю UP с названием UP.


A>>Я понимаю, что наличие констреинтов на таблицы, куда лихо пред вставка данных (например, траффик) — мягко говоря, не желательно.
A>>Но там, где ввод\редактирование данных делается ВРУЧНУЮ...

PNC>Пользователю СBOSS никогда не приходится делать DML "вручную" (писать "Insert ..." и т.д.) и вам я этого тоже не советую
PNC>На все есть свои АРМ или специальные API, а в них целостность обеспечена.
Я назвал вводом "вручную" ввод посредством человека, использующего АРМ.

Здравствуйте, Astellar, Вы писали:

A>Не совсем так. Есть предоплаченные, контрактные и кредитные Предоплаченные — предактивированные, типа МТС Джинс. Контрактные — обычные абоненты. Кредитные — это те, кто говорит в кредит.

я бы сказал, что кредитный — это подвид контрактного. в том смысле, что подвидов два: с предоплатой и постоплатой. суть примерно та же самая.

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

а вот для препейдников как раз и начали придумывать оборудование. простое и шустрое. препейдные балансы, как правило, хранятся на препейдной платформе, которая, грубо говоря, есть компьютер, подсоединенный к коммутатору. или может уже крутые коммутаторы делают, у которых все внтури. просто для меня эта тема была закрыта в период всяких препейд-платформ "lite".

в этом смысле, всегда было непросто организовать фичу "просмотр препейдного баланса в биллинговой системе", именно потому что не биллинговая система его вела. может за последние годы что-то поменялось, но лет 5 назад было просто дикое разнообразие подходов к реализации препейд-платформ, из-за которых единого надежного решения было добиться сложно

A>В известной мне системе дело происходит так:
A>При запросе соединения с коммутатора отправляется запрос к системе. При наличии денег связь разрешается, соединение устанавливатся. Каждые 10 секунд приходит повторный запрос... Вероятно, существуют несколько иные способы реализации Real Time Billing, но, думаю, суть не шибко меняется.

современные in-платформы (дорогие) как раз должны решать проблему авторизации действий абонентов. т.е. хочет абонент позвонить, а коммутатор спрашивает у in-платформы, типа "можно или нельзя, а если можно, то в каком объеме". хорошая in-платформа скажет, что этот звонок делать можно, но только 4 минуты 30 секунд. соотв. если абонент их проговорит, то умный коммутатор, поняв и приняв к сведению эту инфу, сможет разговор вовремя разорвать. отличная in-платформа как и коммутатор обязана решать проблему параллельных событий, таких как входящие, удерживаемые звонки, отсылаемые в процессе разговора смски и проч. если честно, я даже не в курсе, начали делать реальные экземпляры таких платформ или до сих пор только частичные реализации существуют, но в любом случае, это не возлагают на биллинговую систему

возможно, PNCHL, будучи в теме, сможет уточнить мои слова и добавить что-то ценное из общих знаний по вопросу

Здравствуйте, PNCHL, Вы писали:

PNC>Наличие FK и других констрейнтов НИКОГДА не увеличивает производительность
PNC>1) Про производительность и FK я уже писал

Автор: PNCHL
Дата: 12.01.06

. Могу добавить только, что если на ссылающейся таблице индекса нет, то Oracle не только делает full scan таблицы в поисках ссылок на удаляемую в родительской таблице запись, но и блокирует таблицу целиком!.
Че за чушь.
1. Разницу между ссылающимися таблицами и вложенными таблицами ощущаешь?
2. Конечно, прикольно иметь в Oracle констраинт FK без индекса. Лучше расскажи как это сделать. Я не знаю.

Удивление о том, что Oracle дeлает full scan при отсутсвии индекса навевает на мысль, что в CBOSS знают другой способ функционирования базы данных в данной ситуации.

PNC>Если уж говорить о технических решениях, касающихся БД (FK и прочее) — очень зря. Думаю (конечно, многоуважаемый ALL меня с удовольствием поправит ), что лучших программистов под Oracle, чем в CBOSS, в России нет.
Ну, самых выпендрежных с учетом написанного, действительно нет

С уважением, Gleb.

Здравствуйте, PNCHL, Вы писали:

PNC>Oracle так не делает. Я даже специально проверил — план запроса вообще не меняется. Видимо в MS SQL помимо парсинга и генерации плана запроса оптимизатор занимается еще и семантическим анализом...
Семантическая оптимизация(так они называются) у Oracle также имеется. Ну например, примерный запрос:

select A1.* from A1, A2 where A1.ID=A2.ID AND A2.ID>50

если а1 существенно меньше a2 то фильтрация(в большинстве случаев) будет по меньшему a1.

Что касается вышеуказанной оптимизации(и вообще констрейнтов), то ей мешает наличие deferred режима(отложенный режим констрейнтов). То есть транзакция может содержать до момента коммита неконсистентные данные.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

PNC>>1) Про производительность и FK я уже писал

Автор: PNCHL
Дата: 12.01.06

. Могу добавить только, что если на ссылающейся таблице индекса нет, то Oracle не только делает full scan таблицы в поисках ссылок на удаляемую в родительской таблице запись, но и блокирует таблицу целиком!.
GZ>Че за чушь.
GZ>1. Разницу между ссылающимися таблицами и вложенными таблицами ощущаешь?
GZ>2. Конечно, прикольно иметь в Oracle констраинт FK без индекса. Лучше расскажи как это сделать. Я не знаю.

не знаю, менялось ли что-то в версиях oracle после 7.3 насчет данного поведения, но PNCHL прав (я с этим также сталкивался в Oracle7.3 и по-моему это также было в 8.1), а называется эта ситуация "неиндексированный внешний ключ":

пусть поле b_x таблицы A ссылается на поле x таблицы B.
ссылающаяся таблица — это A и ничто не принуждало делать индекс по A.b_x.
любая активность в B по модификации x или удалению записи с некоторым значением x приводила к блокировке всей таблицы A, и транзакции выстраивались в цепочку даже, если не противоречили друг другу. создание индекса по A.b_x решало проблему, т.к. начинали блокироваться только конкретные позиции в индексе

Здравствуйте, GlebZ, Вы писали:

GZ>Что касается вышеуказанной оптимизации(и вообще констрейнтов), то ей мешает наличие deferred режима(отложенный режим констрейнтов). То есть транзакция может содержать до момента коммита неконсистентные данные.
За отмазку не канает.
Изменения в deffered check транзакции другим транзакциям до коммита (а, следовательно, и до проверки) не видны, и влиять на результат не могут. А уж внутри самой транзакции совершенно неважо что делать, если в случае косяка все равно будет откат.

GZ>2. Конечно, прикольно иметь в Oracle констраинт FK без индекса. Лучше расскажи как это сделать. Я не знаю.

Без индекса по foreign key? А оракл его сам и не создает, ручками надо.

C0s>не знаю, менялось ли что-то в версиях oracle после 7.3 насчет данного поведения, но PNCHL прав (я с этим также сталкивался в Oracle7.3 и по-моему это также было в 8.1), а называется эта ситуация "неиндексированный внешний ключ":

не менялось.

Здравствуйте, Igor Trofimov, Вы писали:

GZ>>2. Конечно, прикольно иметь в Oracle констраинт FK без индекса. Лучше расскажи как это сделать. Я не знаю.

iT>Без индекса по foreign key? А оракл его сам и не создает, ручками надо.
А ты создай foreign key без индекса. И мне расскажи как.

С уважением, Gleb.

Здравствуйте, Merle, Вы писали:

M>За отмазку не канает.
M>Изменения в deffered check транзакции другим транзакциям до коммита (а, следовательно, и до проверки) не видны, и влиять на результат не могут. А уж внутри самой транзакции совершенно неважо что делать, если в случае косяка все равно будет откат.
Нет. Проблема в самой транзакции. Ей приходится самой по себе работать с невалидными данными. Хотя конечно, пути обхода всегда можно найти(типа проверять режим для каждого констрейнта), но до девятки такой оптимизации нет. Десятки у меня нет, поэтому проверить не могу.

С уважением, Gleb.

iT>>Без индекса по foreign key? А оракл его сам и не создает, ручками надо.
GZ>А ты создай foreign key без индекса. И мне расскажи как.

Как обычно

ALTER TABLE SomeTable ADD CONSTRAINT SomeFK FOREIGN KEY (FkField) REFERENCES AnotherTable (PkField)

Индекса по FK автоматически создано не будет и не требуется.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Индекса по FK автоматически создано не будет и не требуется.
Прекрасно, удали в AnotherTable все индексы и попробуй создать foreign key. Или наоборот. Попробуй удалить индексы при живом foreign key.

С уважением, Gleb.

Здравствуйте, Astellar, Вы писали:

Возможно, целостность действительно реализуется на уровне приложения, что дает преимущество, не зависеть от источника данных, т.е. СУБД, это может быть даже обыкновенный файл.

Здравствуйте, GlebZ, Вы писали:

GZ>Прекрасно, удали в AnotherTable все индексы и попробуй создать foreign key. Или наоборот. Попробуй удалить индексы при живом foreign key.

речь с самого начала идет о ссылающейся таблице. т.е. не об AnotherTable, а о SomeTable. GlebZ, про это пишут уже три человека я и Igor Trofimov привели пример ну повнимательнее же можно?

Здравствуйте, Astellar, Вы писали:

A>Не совсем так. Есть предоплаченные, контрактные и кредитные Предоплаченные — предактивированные, типа МТС Джинс. Контрактные — обычные абоненты. Кредитные — это те, кто говорит в кредит.
A>Про "специальные" коммутаторы не слышал, мне кажется, это преувеличение. Тут вопрос именно в биллинге, так как с, наверное, любого современного коммутатора можно запросить данные в любой момент времени. А баланс он в базе, а не на коммутаторе, хранится.

это не преувеличение! Наоборот, компании делающие такие коммутаторы (а сейчас почти все такие, так как интерес к препейду намного выше чем к постпейду) обычно имеют свои компании делающие ртт-биллинг под свой коммутатор. по секрету сибосс одну такую компанию производителя и перекупил (RTB-биллинг). он кстати лучше (старше) того рт-биллинга что у мтс, но опять же дороже


A>В известной мне системе дело происходит так:
A>При запросе соединения с коммутатора отправляется запрос к системе. При наличии денег связь разрешается, соединение устанавливатся. Каждые 10 секунд приходит повторный запрос... Вероятно, существуют несколько иные способы реализации Real Time Billing, но, думаю, суть не шибко меняется.

Это со старыми коммутаторами. такое решение сильно проигрывает в маштабируемости аппаратному

Здравствуйте, C0s, Вы писали:

C0s>речь с самого начала идет о ссылающейся таблице. т.е. не об AnotherTable, а о SomeTable. GlebZ, про это пишут уже три человека я и Igor Trofimov привели пример ну повнимательнее же можно?
Да, я это уже вчера понял. Только не понял смысловую часть. Зачем это нужно.
Для консистенстности транзакции, разницы между таблицей с индексом и просто индексом нет. Для производительности, тоже как то не клеится. Если индекс не по нужному полю(а нужное поле не обладает уникальностью), то использование индекса обычно не используется.

Здравствуйте, KBH, Вы писали:

KBH>Возможно, целостность действительно реализуется на уровне приложения, что дает преимущество, не зависеть от источника данных, т.е. СУБД, это может быть даже обыкновенный файл.
Во-первых, приложение такой сложности, да еще написанное в ручную, обладает такой степенью зависимости от СУБД, что наличие или отсутствие констрейнтов, в плане оной зависимости — это просто проблема другого порядка малости.
А во-вторых, наличие констрейнтов в СУБД, вовсе не избавляет от необходиомсти реализовывать контроль уровнем выше.

Здравствуйте, Astellar, Вы писали:
A>Господа, столкнулся я с биллинговой системой CBOSS.
A>почему не сделать ключи?

Причин ровно две:
1) Для большинства таблиц CBOSS PK создавать бессмысленно, поскольку обному объекту соответствуют несколько записей-версий, различаемых по датам начала/завершения действия. По этой же причине нельзя создать FK, поскольку он ничего не сможет проконтролировать (даты версий родительского дочернего объектов, вообще говоря, не связаны).
2) Первой причины вообще-то достаточно

Теперь про оптимизацию.
Oracle ориентируется по индексам, а не по констрейнам.
И индексы в CBOSS, разумеется, есть.
Более того, для больших таблиц эти индексы буквально вылизываются и явно поддерживаются в коде (большинство запросов "закрепляется" хинтами).
Да, этот подход создает проблемы при смене версии сервера.
Но он же позволяет относительно быстро выявлять причины "затыков".