Господа, столкнулся я с биллинговой системой CBOSS.
До этого сталкивался с парой-тройкой других биллинговых систем, и что меня озадачило..
В CBOSS нет ключей! Т.е. таблицы никак не связаны между собой "физически", целостность обеспечивается на уровне приложений.
Кроме того, из-за прикольной системы именования столбцов, довольно трудно вникнуть в устройство базы.
Я понимаю, что наличие констреинтов на таблицы, куда лихо пред вставка данных (например, траффик) — мягко говоря, не желательно.
Но там, где ввод\редактирование данных делается ВРУЧНУЮ...
В общем, я далеко не эксперт с мировым именем, поэтому не кричу тут что это плохо и неправильно, а хочу узнать, почему так?
Первое, что приходит на ум — производительность. Не согласен.
Второе — не смогли продумать систему ключей для сложной базы. Но тоже не убедительно, логическеи связи жеесть, целостность типа соблюдается,
почему не сделать ключи?

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

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

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

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

A>...
A>почему не сделать ключи?

Скорее всего тут две причины.

1. Использовался специальный инструментарий при разработке (а-ля ORM), который просто не создает констрейнты по своим внутренним причинам (эту функцию не реализовали разработчкии, это обусловлено особенностями архитектуры или см. п. 2).
2. Для легкой переносимости на другие СУБД.

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

A>>...
A>>почему не сделать ключи?

AR>Скорее всего тут две причины.

AR>1. Использовался специальный инструментарий при разработке (а-ля ORM), который просто не создает констрейнты по своим внутренним причинам (эту функцию не реализовали разработчкии, это обусловлено особенностями архитектуры или см. п. 2).
AR>2. Для легкой переносимости на другие СУБД.

Есть еще третья, маловероятная причина — автор не знал про сущестование FK

Здравствуйте, Коваленко Дмитрий, Вы писали:

AR>>1. Использовался специальный инструментарий при разработке (а-ля ORM), который просто не создает констрейнты по своим внутренним причинам (эту функцию не реализовали разработчкии, это обусловлено особенностями архитектуры или см. п. 2).
AR>>2. Для легкой переносимости на другие СУБД.

КД>Есть еще третья, маловероятная причина — автор не знал про сущестование FK

Я думаю все же производительность.

Между прочим, обязательное использование FK — это вовсе не догма, как многие думают. Целостность может обеспечиваться и на уровне приложения. Если, например, это единственное приложение, изменяющее данные.

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

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

W>Здравствуйте, Коваленко Дмитрий, Вы писали:

AR>>>1. Использовался специальный инструментарий при разработке (а-ля ORM), который просто не создает констрейнты по своим внутренним причинам (эту функцию не реализовали разработчкии, это обусловлено особенностями архитектуры или см. п. 2).
AR>>>2. Для легкой переносимости на другие СУБД.

КД>>Есть еще третья, маловероятная причина — автор не знал про сущестование FK

W>Я думаю все же производительность.

W>Между прочим, обязательное использование FK — это вовсе не догма, как многие думают. Целостность может обеспечиваться и на уровне приложения. Если, например, это единственное приложение, изменяющее данные.

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

A>Но каким боком это влияет на производительность?
Меньше индексов.

Кстати, "там, где ввод\редактирование данных делается ВРУЧНУЮ", это может делать очень много людей.

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

W>Я думаю все же производительность.
Ага, плохая производительность..

Вообщем-то не секрет, что FK и прочие констрейнты, грамотно расставленые в нужных местах, производительность наоборот увеличивают, так как являются неплохой подсказкой оптимизатору.
Ну и второе, в базе всегда найдется на чем повысить производительность и помимо констрейнтов, так что тут скорее всего виновата действительно та платформа, с помощю которой генерилась БД, о чем косвенно говорят и "странные" имена объектов.
Впрочем биллинговая система CBOSS никогда не считалась образцом для подражания..

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

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

A>>Но каким боком это влияет на производительность?
W>Меньше индексов.
Гм. Вообще обычно где ключи — там и джойны. Джойны без индексов будут работать настолько плохо, что снижение производительности при вставке покажется легким ветерком.
Надо уточнить у автора — есть ли там индексы?
Если есть, то опять же наличие ключей помогает оптимизатору построить более качественный план запроса (т.к. он точно знает, что каждому значнию ключа соответствует одно значение в целевой таблице).

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

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

W>>Я думаю все же производительность.
M>Ага, плохая производительность..

M>Вообщем-то не секрет, что FK и прочие констрейнты, грамотно расставленые в нужных местах, производительность наоборот увеличивают, так как являются неплохой подсказкой оптимизатору.
M>Ну и второе, в базе всегда найдется на чем повысить производительность и помимо констрейнтов, так что тут скорее всего виновата действительно та платформа, с помощю которой генерилась БД, о чем косвенно говорят и "странные" имена объектов.
M>Впрочем биллинговая система CBOSS никогда не считалась образцом для подражания..

Повышают, при селекте и уменьшают при Инсерте.

Я CBOSS не разрабатывал, но если это биллинг, то инсертов там значительно больше.

Видел я системы без FK , целостность на тригерах, и все нормально работало

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

W>>Меньше индексов.
S>Гм. Вообще обычно где ключи — там и джойны. Джойны без индексов будут работать настолько плохо, что снижение производительности при вставке покажется легким ветерком.
Не всегда.

S>Надо уточнить у автора — есть ли там индексы?
Да, и еще — какой оптимизатор используется. Если RBO, то не имеем ли мы случай жесткого закрепления планов хинтами или outline'ами. В этом случае ключи оптимизатору как бы не нужны.

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

B>Повышают, при селекте и уменьшают при Инсерте.
Триггеры в этом отношении, как правило, заметно хуже.

B>Видел я системы без FK , целостность на тригерах, и все нормально работало
Работало, но плохо и не долго...
Характерный пример тот же CBOSS — думаешь слухи о том, что МТС тырит деньги возникли на пустом месте? Нет, это просто отсутствие должного контроля целостности в биллинговой системе.
Правда сейчас там системане лучше...

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

B>Я CBOSS не разрабатывал, но если это биллинг, то инсертов там значительно больше.

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

B>Видел я системы без FK , целостность на тригерах, и все нормально работало

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

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

Возможно, "так сложилось". С самого начала не озаботились, не оценили возможных последствий — а потом руки не дошли.
Я имел счастье участвовать в развитии и сопровождении системы с БД без FK — с ростом базы проблем появляется все больше. Чаще всего были ошибки с участием "оборванных" данных — повисшие в подчиненных таблицах записи, не имеющие соответствия в главной таблице (в результате какого-нибудь срочного фикса в триггере на удаление).

Ну, скажу, для порядка, пару слов. Во-первых, насчет МТС и CBOSS. Он используется не везде. Например, в родном Красноярске, где такие слухи ходили очень активно после покупки МТСом СибЧеленджа, не CBOSS.
Да, естественно, при ребиллинге — очень прилично невынужденных косяков.
При этом, кстати, тенденция такая: если косяк в пользу компании, т.е. у абонентов снимают лишнее, они жалуются, и в основном, все исправляют, и деньги возвращают. При обратном случае (по теории вероятности, таких 50 на 50), зачастую, компания предпочитает ошибку в биллинге исправить, но недоснятые деньги абонентам простить. Воот. Так что деньги скорее не тырят, а наоборот.
Да и скоро не будет CBOSS вообще в МТС нигде

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

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

B>>Повышают, при селекте и уменьшают при Инсерте.
M>Триггеры в этом отношении, как правило, заметно хуже.

B>>Видел я системы без FK , целостность на тригерах, и все нормально работало
M>Работало, но плохо и не долго...
M>Характерный пример тот же CBOSS — думаешь слухи о том, что МТС тырит деньги возникли на пустом месте? Нет, это просто отсутствие должного контроля целостности в биллинговой системе.
M>Правда сейчас там системане лучше...

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


A> Например, в родном Красноярске, где такие слухи ходили очень активно после покупки МТСом СибЧеленджа, не CBOSS.
Значит это тоже хорошая система...

A> Так что деньги скорее не тырят, а наоборот.
Но дело-то не в этом, проблема в том, что система в принципе допускает возникновение подобных косяков, что вообщем-то довольно дико, с точки зрения простого обывателя.

A>Да и скоро не будет CBOSS вообще в МТС нигде
Та система на которую они сейчас переходят — ни чем не лучше.

Здравствуйте, Коваленко Дмитрий, Вы писали:

A>>>...
A>>>почему не сделать ключи?

AR>>Скорее всего тут две причины.

КД>Есть еще третья, маловероятная причина — автор не знал про сущестование FK

Кажется я знаю кто автор

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


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

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


A>> Например, в родном Красноярске, где такие слухи ходили очень активно после покупки МТСом СибЧеленджа, не CBOSS.
M>Значит это тоже хорошая система...

A>> Так что деньги скорее не тырят, а наоборот.
M>Но дело-то не в этом, проблема в том, что система в принципе допускает возникновение подобных косяков, что вообщем-то довольно дико, с точки зрения простого обывателя.

A>>Да и скоро не будет CBOSS вообще в МТС нигде
M>Та система на которую они сейчас переходят — ни чем не лучше.

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

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

A>>>Да и скоро не будет CBOSS вообще в МТС нигде
M>>Та система на которую они сейчас переходят — ни чем не лучше.

Типа Билайн рулит?

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

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

A>А то, на что они переходят... оооо это такая зверушка, намаются еще абоненты
Да уж... Я вот уже..

P. S.
Большая просьба отвечать под цитируемым текстом и выкидывать из ответа лишние цитаты.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, Коваленко Дмитрий, Вы писали:

A>>>>...
A>>>>почему не сделать ключи?

AR>>>Скорее всего тут две причины.

КД>>Есть еще третья, маловероятная причина — автор не знал про сущестование FK

КД>Кажется я знаю кто автор

Сказал "А" говори "Б" — открой секрет, кто?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Типа Билайн рулит?
Не, просот про билайн я неичего не знаю в плане биллинга

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



A>>так это, в основном, человеческий фактор: либо банальная ошибка, либо неверное понимание того, как работает система.
M>Так любую проблему можно свести к человеческому фактору, но контроль целостности средство защиты и от человеческого фактора в том числе...
Да не от всякого. От , скажем, введенной цифры 0.07 вместо 0.05 хрен защитишься
Пожалуй, единственный вариант — создание альтернативной, тесотвой тарификации со своим вводом тарифов итп, и постоянная проверка
Хотя тоже не очень хороший вариант.

A>>А то, на что они переходят... оооо это такая зверушка, намаются еще абоненты
M>Да уж... Я вот уже..
рпойдет время — все нормализуется

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

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

W>>>Меньше индексов.
S>>Гм. Вообще обычно где ключи — там и джойны. Джойны без индексов будут работать настолько плохо, что снижение производительности при вставке покажется легким ветерком.
W>Не всегда.

S>>Надо уточнить у автора — есть ли там индексы?
W>то не имеем ли мы случай жесткого закрепления планов хинтами или outline'ами. В этом случае ключи оптимизатору как бы не нужны.
ага, именно так там и есть! хинты проставлены во всех селектах.

а насчет того что там сейчас система лучше (это в МТС то есть)... можно сильно поспорить. единственно чем она лучшен — ее делает "картманная" МТСовская кампания. т.е. заведомо дешевле сибосса

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

КД>>>Есть еще третья, маловероятная причина — автор не знал про сущестование FK

КД>>Кажется я знаю кто автор

___>Сказал "А" говори "Б" — открой секрет, кто?

Это я стебаюсь насчет -1

Автор: Коваленко Дмитрий
Дата: 16.12.05

, который мне поставили за третью причину. Типа, не знаешь, Коваленко, как нам там тогда стрёмно было делать FK — молчи

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

g_i>Возможно, "так сложилось".

Такое бывает сплошь и рядом. Люди идут на поводу у своих страхов, либо умышленно — чтобы гарантировано обеспечить себя работой в будущем. Как правило — первое. И я не был усключением (хотя это база для регистрации сделок с недвижимостью), поскольку правильная расстановка приоритетов — это вещь которая приходит только в процессе эксплуатации. Особенно для баз данных

Буквально весной этого года ездили "в гости" — у них база эквивалентного назначения работает на Оракле. Всего ~2GB и народ страшится перегрузить его целостностью и сложностью. У нас на FB — 12GB и от наших конструкций, целостность которых контролируется в большинстве случаев за счет FK, нас самих перидически колбасит
Вот тут и подумаешь — а если бы мне не было страшно в 2000 году? Или на ухо шепнул кто ...

Здравствуйте, Аноним, Вы писали:

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

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

А>а насчет того что там сейчас система лучше (это в МТС то есть)... можно сильно поспорить. единственно чем она лучшен — ее делает "картманная" МТСовская кампания. т.е. заведомо дешевле сибосса

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

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

A>Господа, столкнулся я с биллинговой системой CBOSS.
A>До этого сталкивался с парой-тройкой других биллинговых систем, и что меня озадачило..
A>В CBOSS нет ключей! Т.е. таблицы никак не связаны между собой "физически", целостность обеспечивается на уровне приложений.

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

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

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

2) Почитайте документацию про "объектную модель CBOSS", особенно про версионность — каждый объект представлен в таблице несколькими записями, все с одинаковым суррогатным ключем, но разными "сроками жизни". Соответственно ссылка на объект не то же самое, что ссылка на строку в таблице — FK неприменимы.

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

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

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

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

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

PNC>1) FK снижают производительность DML-операций.
Ну да, снижают, немного...

PNC>Эффект достаточно сильный — достаточно подсчитать количество дисковых чтений для каждой операции.
Это мотря как считать, а лучше даже не считать, а померять. Думаю, что если набежит пара процентов, то это будет рекорд.

PNC> б) Если на ней есть FK, то дополнительно производится индексный поиск по ссылающейся таблице. Индексный поиск — это, как минимум еще одно дисковое чтение.
Как минимум это 0 дисковых чтений, потому как такую классную штуку как кеш изобрели не вчера..

PNC>Обычно базы создают с размером блока 4 Кб,
Это смотря какие базы, кто создает и из каких соображений, впрочем это другой вопрос...

PNC> Итого, замедление будет в 2-5 раз.
Ага. В 0.02-0.05 потому как корневые страницы часто используемых индексов сидят в кеше перманентно, а для не часто используемых тормоза не критичны.

PNC>Конечно, на самом деле, общее снижение производительности системы не будет таким большим,<...>
Ну ясен байт.

PNC>Но для систем, обслуживающих несколько миллионов абонентов, снижение производительности операций даже на 10%, означает дополнительные затраты на оборудование в несколько сотен тысяч долларов.
Все верно, только чтобы набежало 10% — "тут одному не правиться — помошник нужен..."
С другой стороны, косяк в базе — это еще большие бабки и недовольство клиента. Так что выбирай, но осторожно, но выбирай.

PNC>На все есть свои АРМ или специальные API, а в них целостность обеспечена.
То есть, в данном случае считается что проверка вручную будет быстрее проверки встроенного механизма СУБД?

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

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

W>>Я думаю все же производительность.
M>Ага, плохая производительность..

M>Вообщем-то не секрет, что FK и прочие констрейнты, грамотно расставленые в нужных местах, производительность наоборот увеличивают, так как являются неплохой подсказкой оптимизатору.

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

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

. Могу добавить только, что если на ссылающейся таблице индекса нет, то Oracle не только делает full scan таблицы в поисках ссылок на удаляемую в родительской таблице запись, но и блокирует таблицу целиком!.
2) Сами констрейнты напрямую на оптимизатор не влияют. При формировании плана запроса оптимизатор учитывает только сопутствующие индексы, которые, при необходимости, можно создать и без констрейнтов.

Учите матчасть


M>Ну и второе, в базе всегда найдется на чем повысить производительность и помимо констрейнтов, так что тут скорее всего виновата действительно та платформа, с помощю которой генерилась БД, о чем косвенно говорят и "странные" имена объектов.

Генераторы схем БД в CBOSS не используются...

M>Впрочем биллинговая система CBOSS никогда не считалась образцом для подражания..

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

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

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

ну вот разговор наконец-то и дошел до бюджетов....

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

мне как активному программисту известно, что проверить правильность алгоритма далеко не всегда просто. в большой системе ситуация усложняется тем, что алгоритмы начинают надеяться друг на друга, как следствие при правке одного что-то может отъехать в другом месте. не обязательно отъезжает, и уж тем более не имею информации о том, как часто это отъезжало в cboss, но мне очевидно, что затраты на верификацию реализации API больше, чем на верификацию правильной расстановки FK. какой-то конкретный FK был до модификации функциональности и им останется, продолжая своим надежным до тупости подходом с N-M доп. обращениями к диску контролировать целостность тех или иных данных, а при модификации алгоритма по-хорошему надо делать review всех мест, от него зависящих (по крайней мере с формальной точки зрения, не полагаясь на субъективное представление о том, писали ли это лучшие программисты в россии и не успели ли они зазнаться там на своем олимпе).

простыми словами, получаем, что большая система с такими вот "оптимизационными" усложнениями обходится дороже в поддержке и развитии. ключевой момент — на кого ложится это "дороже".
1) вариант, когда для поддержки X абонентов надо купить оборудования на M денег для заказчика — это разовое вложение денег. пусть даже из-за FK пришлось переплатить на L
2) вариант, когда постоянно в подпроекты на добавление дополнительной функциональности добавляются скрытые суммы, учитывающие затраты на более сложное верифицирование — это как незаметно подсесть на иглу, т.к. вроде и не видно, а переплачивать Kn денег приходится с каждым n-ным контрактом на поддержку

безусловно, все упирается в то, как соотносятся L и сумма(Kn). чем дольше заказчик собирается использовать систему, тем вероятнее, что первый вариант выгоднее. но все осложняется трудностью оценки K и тем, что ее обычно скрывают.

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

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

C0s>мне как активному программисту известно, что проверить правильность алгоритма далеко не всегда просто. в большой системе ситуация усложняется тем, что алгоритмы начинают надеяться друг на друга, как следствие при правке одного что-то может отъехать в другом месте. не обязательно отъезжает, и уж тем более не имею информации о том, как часто это отъезжало в cboss, но мне очевидно, что затраты на верификацию реализации API больше, чем на верификацию правильной расстановки FK. какой-то конкретный FK был до модификации функциональности и им останется, продолжая своим надежным до тупости подходом с N-M доп. обращениями к диску контролировать целостность тех или иных данных, а при модификации алгоритма по-хорошему надо делать review всех мест, от него зависящих (по крайней мере с формальной точки зрения, не полагаясь на субъективное представление о том, писали ли это лучшие программисты в россии и не успели ли они зазнаться там на своем олимпе).

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


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

Если требования к целостности данных не выполнимы в рамках PK-FK + CHECK CONSTR , нужно ли их реализовывать лишь частично с помощью этих средств? Например, возможность удаления/вставки элементов может обусловливаться самой замысловатой бизнес-логикой, не реализуемой нормально даже в триггерах. Зачем тогда усложнять систему и размазывать (или дублировать) код, отвечающий за целостность данных между внешними API, триггерами и констрейнтами? Не проще ли сконцентрировать его во внешних библиотеках, контролирующих ВСЕ действия с данными и написанных на более приспособленных для этого языках программирования?

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

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

AR>Ваши суждения как програмиста достаточно наивны, хотя и верны отчасти. Не заморачиваясь темой организационных и финансовых проблем, посмотрите хотя бы с технической точки зрения.

не сомневаюсь насчет общей наивности , просто не сочинения же писать в 20 главах в каждом посте, начиная каждую словами "мне как активному такому-то/пассивному сякому-то/ночному теоретику того-то/дневному практику сего-то" и, соотв, рассматривая вопрос с каждой стороны и повышая тем самым объективность суждений

AR>Если требования к целостности данных не выполнимы в рамках PK-FK + CHECK CONSTR , нужно ли их реализовывать лишь частично с помощью этих средств? Например, возможность удаления/вставки элементов может обусловливаться самой замысловатой бизнес-логикой, не реализуемой нормально даже в триггерах. Зачем тогда усложнять систему и размазывать (или дублировать) код, отвечающий за целостность данных между внешними API, триггерами и констрейнтами? Не проще ли сконцентрировать его во внешних библиотеках, контролирующих ВСЕ действия с данными и написанных на более приспособленных для этого языках программирования?

я бы тогда также предложил посмотреть вот с какой стороны:
— допустим есть связь A references B
— есть алгоритм C, который валит записи в A, гарантируя путем внутренних оптимизаций, что ссылочная целостность будет соблюдена
— есть алгоритм D, который оперируя данными из двух таблиц A и B полагается на выполнение целостности, т.е. для него это правило — предусловие при обработке каждой записи из A, выполнение которого гарантирует правильность его работы (а он записывает в A1 references B1, далее это обрабатывается алг. D1 и т.д. по нарастающей)

и, соотв, стоит выбор подхода к реализации Dx — то ли поверить, что кто-то (в данном случае C... Dx-1) будут всегда пушистым, то ли как-то явно себя обезопасить путем явной проверки выполнения предусловия (и при невыполнении как-то сигнализировать об этом в виде, скажем, исключения в лог и/или аларма на пейджер)
полагаясь на всеобщую пушистость, обнаруживая при анализе конечного результата в таблице An расхождение, в большой системе имхо сложно понять какой из алгоритмов цепочки слажал (и какому сотруднику cboss в конечном итоге штрафные баллы ставить )

пока программа настолько маленькая, что сложности алгоритмов равно как и количество связей обозримы одним-двумя умниками — оба подхода хороши, и остается время для любых фантазий на тему оптимизации. но как только система разрастается настолько, что алгоритм C поддерживают в отделе E, а D пишут в отделе F, и расстояние между E и F вычисляется в G днях пересылки служебки через H руководителей для синхронизации и координации усилий по совокупному добавлению функциональности, затрагивающей C и D одновременно, то устойчивость и явная изолированность алгоритмов может сильно помочь.

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

выбирая явную проверку предусловий, далеко не всегда ее можно эффективно реализовать какими-то программными подходами. в случае A и B наличие FK обычно оказывается наиболее простым и надежным решением, пусть и не самым эффективным в runtime.
оценивать преимущество решения с FK над решением без FK или наоборот как и многие другие решения, которые приходится принимать при создании и развитии больших систем, надо не с позиции одного-двух факторов, а по возможности многих. в целом, я не удивлен, что во многих проектах, растущих из середины-конца 90х вес технических факторов (таких как эффективность в runtime) сильно превышает веса остальных, т.к. оборудование все еще стоило дорого, СУБД были менее совершенны и т.д., а менеджеры проектов обычно сами происходили из программистов или даже совмещали управление с изготовлением поделок. искоренять же те решения или начать пробовать новые подходы в уже работающей большой системе практически малореально (даже если собраны самые лучшие программисты )

AR>PS: Выше почему-то ничего не сказали о существенном торможении, которое могут добавить констрейнты при записи данных. А ведь в биллинговых системах именно это и имеет место в основном (запись больших объемов данных). Проведите примитивный эксперимент хотя бы даже на двух таблицах по 5-10 млн. записей в каждой и одной PK-FK связью. Вы увидите гигантскую разницу в скорости заполнения этих таблиц данными при наличии/отсутствии констрейнтов.

что мог бы добавить:
— часто путают биллинг и рейтинг. как раз именно в рейтинге чаще всего не делают констрейнтов (вполне оправданно) и обработку пишут на нормальных языках, в которых свои подходы (ОО) обеспечивают повышенную корректность алгоритмов
— для больших таблиц, которые растут прямо пропорционально количеству абонентов, помноженному на среднее/максимальное время их активной жизни в системе, часто применяют партиционирование, данные индексов выносят в отдельные пространства и за счет разноса данных по разным носителям увеличивают параллелизм. к сожалению, это не мой конек, возможно я и ошибаюсь, но для меня факт наличия в арсенале oracle этих функциональных возможностей подтверждает наличие способов борьбы с проблемой. иными словами, я не думаю, что при отлаженном сотрудничестве программистов и администраторов субд мы будем видеть

гигантскую разницу в скорости

даже при чрезмерном использовании FK

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

PNC>Наличие FK и других констрейнтов НИКОГДА не увеличивает производительность
Смело, не правда, но смело..

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

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

.
Напрасно... Впрочем я уже ответил..

PNC> Могу добавить только, что если на ссылающейся таблице индекса нет, то Oracle не только делает full scan таблицы в поисках ссылок на удаляемую в родительской таблице запись, но и блокирует таблицу целиком!.
Клинические случаи не рассматриваем.

PNC>2) Сами констрейнты напрямую на оптимизатор не влияют.
Это смотря какой оптимизатор. Не ораклом единым....

PNC>Учите матчасть
Во-во, и не зацикливайтесь на Оракле..

PNC>Генераторы схем БД в CBOSS не используются...
А ведь могли бы...

PNC>Если уж говорить о технических решениях, касающихся БД (FK и прочее) — очень зря.
Вот уж точно слава байту что не образец.

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

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

PNC>>Наличие FK и других констрейнтов НИКОГДА не увеличивает производительность
M>Смело, не правда, но смело..

Буду рад узнать примеры, когда увеличение производительности все же происходит...


PNC>> Могу добавить только, что если на ссылающейся таблице индекса нет, то Oracle не только делает full scan таблицы в поисках ссылок на удаляемую в родительской таблице запись, но и блокирует таблицу целиком!.
M>Клинические случаи не рассматриваем.

Случай не самый клинический — очень часто забывают о необходимости создавать такие индексы (см. Тома Кайта, "великого и ужасного", аминь )

PNC>>2) Сами констрейнты напрямую на оптимизатор не влияют.
M>Это смотря какой оптимизатор. Не ораклом единым....

Речь шла о биллинге CBOSS — он на Oracle..

PNC>>Генераторы схем БД в CBOSS не используются...
M>А ведь могли бы...

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


PNC>> Думаю (конечно, многоуважаемый ALL меня с удовольствием поправит ), что лучших программистов под Oracle, чем в CBOSS, в России нет.
M>Меня терзают смутные сомненья, особенно после пользования этим пресловутым биллингом.

А что вам в нем не нравилось? По возможности с подробностями... Обещаю честно рассказать, в чем была (или есть) проблема...

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

PNC>Буду рад узнать примеры, когда увеличение производительности все же происходит...
Когда оптимизатор начинает принимать их во внимание, ну вот самый наглядный пример, для сиквела 2000/2005:

-- создаем две таблички, пока констрейнтом не связываем
--
CREATE TABLE t1(col1 int NOT NULL PRIMARY KEY) 
CREATE TABLE t2(col1 int NOT NULL) 

INSERT INTO t1 VALUES(1)
INSERT INTO t2 VALUES(1)

Делаем простейший запрос, который возвращает из t2 записи которые есть в t1,
и смотрим план.

SELECT COUNT(*) FROM t2
WHERE EXISTS (SELECT * FROM t1 WHERE t1.col1 = t2.col1)

-- План запроса:
--
  |--Compute Scalar(DEFINE:([Expr1008]=CONVERT_IMPLICIT(int,[Expr1011],0)))
       |--Stream Aggregate(DEFINE:([Expr1011]=Count(*)))
            |--Nested Loops(Inner Join, OUTER REFERENCES:([t2].[col1]))
                 |--Table Scan(OBJECT:([t2]))
                 |--Clustered Index Seek(OBJECT:([t1].[PK]), SEEK:([t2].[col1]) ORDERED FORWARD)

Все, вообщем, вполне ожидаемо и предсказуемо.... Теперь добавляем констрейнт, выполняем тот же запрос и опять смотрим план.

ALTER TABLE t2 WITH CHECK ADD CONSTRAINT fk_t2_t1 FOREIGN KEY(col1)
REFERENCES t1(col1)

-- Новый план того же запроса после добавления констрейнта
--
  |--Compute Scalar(DEFINE:([Expr1008]=CONVERT_IMPLICIT(int,[Expr1011],0)))
       |--Stream Aggregate(DEFINE:([Expr1011]=Count(*)))
            |--Table Scan(OBJECT:([t2]))

Чувствуешь разницу? К таблице t1 обращений нет вообще, выгода в производительности налицо.

PNC>Речь шла о биллинге CBOSS — он на Oracle..
Ну, этого я не знал, поэтому отвечал из общих соображений, да и вообще — лишний минусик Ораклу за это, и DB2 и Сиквел такими подсказками пользуются давно и с удовольствием.

PNC>Существующие не подходят из-за особенностей объектной модели CBOSS, а свой как-то не удосужились написать...
Ну ясное дело, что тут надо свой писать, в таких вещах на чужое готовое полагаться — себе дороже... )

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

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

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

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

PNC>>Буду рад узнать примеры, когда увеличение производительности все же происходит...
M>Когда оптимизатор начинает принимать их во внимание, ну вот самый наглядный пример, для сиквела 2000/2005:

M>

M>SELECT COUNT(*) FROM t2
M>WHERE EXISTS (SELECT * FROM t1 WHERE t1.col1 = t2.col1)
M>

M>Чувствуешь разницу? К таблице t1 обращений нет вообще, выгода в производительности налицо.

Круто, выходит, что при наличии FK MS SQL воспринимает этот запрос как

  select count(*) 
  from t2
  where col1 is not null

Oracle так не делает. Я даже специально проверил — план запроса вообще не меняется. Видимо в MS SQL помимо парсинга и генерации плана запроса оптимизатор занимается еще и семантическим анализом...

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

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

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

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

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


А теперь про МТС:
они объявили свои тарифные планы предоплаченными, но при это решили "круто сэкономить" — не стали покупать ни специальных коммутаторов (порядка 1$ на абонента), ни prepaid-системы (1-10$ на абонента). Звонки всё также по длинной цепочке загружались в биллинг, а уж там, после их загрузки проверялось, не пора ли абонента отключить из-за нулевой или отрицательной суммы на счете... И вот тепереь представьте, как можно ждать от системы актуальных данных в течение, допустим, дня, если характерное время задержки для нее — 2 недели?! Мы, конечно, сделали все, что могли — при условии, что вся цепочка работает "как часы" характерное время уменьшалось до нескольких минут. НО, это время НЕ ГАРАНТИРОВАНО, в случае любых сбоев оно опять растягивается до 2-х недель!

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

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

W>Здравствуйте, Коваленко Дмитрий, Вы писали:

AR>>>1. Использовался специальный инструментарий при разработке (а-ля ORM), который просто не создает констрейнты по своим внутренним причинам (эту функцию не реализовали разработчкии, это обусловлено особенностями архитектуры или см. п. 2).
AR>>>2. Для легкой переносимости на другие СУБД.

КД>>Есть еще третья, маловероятная причина — автор не знал про сущестование FK

W>Я думаю все же производительность.

W>Между прочим, обязательное использование FK — это вовсе не догма, как многие думают. Целостность может обеспечиваться и на уровне приложения. Если, например, это единственное приложение, изменяющее данные.

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

самое прикольное, что я видел: access, подключеный к oracle. и в нем и правили данные в таблицах.
отговорка: мы ж не работаем. просто данные поправляем.

мое устойчивое imho: за валидносью (непротиворечивостью,типами,превышением пределов) данных должна следить db. в этом случае все попытки вставить-поправить данные с ошибкой, встретят отпор.

во

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

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

Единсвтенный реалтайм биллинг — это у билайн. Там отрубить телефон могут прямо во время разговора, если деньги кончаются в процессе... У остальных идет постобработка после звонка.

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

B>Я CBOSS не разрабатывал, но если это биллинг, то инсертов там значительно больше.
B>Видел я системы без FK , целостность на тригерах, и все нормально работало

Как правило триггеры намного более время- и ресурсоемкие средства контроля. Констрейнты и индексы намного легче в проверке.

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

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, разумеется, есть.
Более того, для больших таблиц эти индексы буквально вылизываются и явно поддерживаются в коде (большинство запросов "закрепляется" хинтами).
Да, этот подход создает проблемы при смене версии сервера.
Но он же позволяет относительно быстро выявлять причины "затыков".

Здравствуйте, Аноним, Вы писали:

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

так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

А>2) Первой причины вообще-то достаточно

т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

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

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

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

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

Хм. На самом деле, операция удаления в CBOSS не является системной. Это обусловлено объектной моделью данных в CBOSS'е. Так что и в самом деле, серьезность проблемы в данном месте преувеличена. Более того, в CBOSS'е ЕСТЬ таблицы, связанные по PK/FK — к примеру, в функционале ЕСПП, но там объектная модель CBOSS не применяется .

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

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

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

А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

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

C0s>Здравствуйте, Аноним, Вы писали:

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

C0s>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

А>>2) Первой причины вообще-то достаточно

C0s>т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

Скорее отсутствие констрейнтов проистекает из версионности. Логически.

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

C0s>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

ну почему же с одинаковой? в основной таблице для объектов какого-то класса — все атрибуты, какие нужны. а вот исторических вспомогательных таблиц к ней нужно столько, сколько есть групп взаимосвязанных атрибутов (т.е. которые меняются обычно вместе), по которым надо сохранять историю. в каждой исторической таблице — ссылка на основную, даты начала-конца периода действия конкретных значений атрибутов и значения каждого атрибута из соотв. группы в указанный период.
при этом, не каждый параметр объекта требует ведения по нему истории. например, по какому-нибудь галимому вольнотекстовому description я бы не стал вести историю, т.е. имхо следует творчески подходить к выделению множеств исторических атрибутов, чтобы не делать лишнего.

имхо (и по опыту), обычно для большинства алгоритмов типичной системы требуется последнее состояние объекта, а к историям (состоянию объектов в прошлом) приходится обращаться реже. на oracle, как следствие, исторические вспомогательные таблички можно убирать в отдельный tablespace со всеми вытекающищми.

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

А>>>2) Первой причины вообще-то достаточно

C0s>>т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

J>Скорее отсутствие констрейнтов проистекает из версионности. Логически.

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

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

C0s>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

Проблема даже не в нежелании создавать по две таблицы. Проблема в требовании иметь консистентный набор данных не только на текущий момент времени, но и в любой момент времени в прошлом. Использование 2-х таблиц — одна с актуальными, вторая с историческими данными (без последней, актуальной записи), только все усложнит.
Пример:
есть 2 объекта — сотрудник (emp и emp_hist) и подразделение (dept и dept_hist). Актуальная запись в emp ссылается на актуальную запись в dept.
А теперь представьте, что в момент времени t_1 запись в dept изменилась. Соответственно если мы хотим получить информацию, актуальную на момент t<t_1 в селекте необходимо джойнить emp и dept_hist, если на момент t>t_1, то джойнить нужно emp и dept. Для того, чтобы выяснить, с чем же нужно джойнить таблицу emp придется выяснять чему равен этот момент t_1, а для этого все равно придется делать селект из dept. Все еще более усложнится, если изменится запись в emp, тогда придется дважды решать, что с чем джойнить. Проблему можно решить одним махом, если всегда джойнить не таблицы, а их объединения:

 (select * from emp 
  UNION ALL
  select * from emp_hist)

в этом случае для получения актуальных на момент времени t данных достаточно наложить на это объединение одно условие

 select *
 from (select * from emp 
       UNION ALL
       select * from emp_hist) all_emp_data
 where t between all_emp_data.begin_date and all_emp_data.end_date

Как легко видеть, в этом случае выгоднее иметь одну таблицу содержащую и историю и актаульные данные.

Часто говорят, что выделять актуальные данные в отдельную таблицу выгодно, поскольку они используются гораздо активнее, чем исторические. Однако даже в этом случае это необязательно — достаточно выделить специальную секцию (partition) в таблице в которую будут попадать только актуальные данные.


P.S. Кстати, вопрос апологетам внешних ключей: а как вообще с их помощью можно добиться ссылочной целостности для исторических данных? По-моему, без размножения данных в таблицах — никак. Ну а коли так, то и "радость от их использования" будет неполной .
Поправьте, плз, если способ, на самом деле, есть...

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

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

C0s>>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

C0s>ну почему же с одинаковой? в основной таблице для объектов какого-то класса — все атрибуты, какие нужны. а вот исторических вспомогательных таблиц к ней нужно столько, сколько есть групп взаимосвязанных атрибутов (т.е. которые меняются обычно вместе), по которым надо сохранять историю. в каждой исторической таблице — ссылка на основную, даты начала-конца периода действия конкретных значений атрибутов и значения каждого атрибута из соотв. группы в указанный период.

То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

C0s>имхо (и по опыту), обычно для большинства алгоритмов типичной системы требуется последнее состояние объекта, а к историям (состоянию объектов в прошлом) приходится обращаться реже. на oracle, как следствие, исторические вспомогательные таблички можно убирать в отдельный tablespace со всеми вытекающищми.

Реже, конечно, но не так уж редко, чтобы этими запросами можно было пренебречь. Отдельный таблспейс? Это можно, через секционирование, но что значит "убирать"? Крутить job, который будет делать delete/insert?


C0s>вообще говоря, я еще предпочитаю добавлять к каждой группе исторических атрибутов номер версии (как в головной таблице, так и в исторических, причем в последних он становится частью PK, а в головной по нему можно сделать констрейнт уникальности), чтобы во всех случаях, где требуется ссылка на конкретное состояние объекта в прошлом можно было делать выборку по номеру версии (т.е. используя в джойне ключи вместо сравнения дат)

Что-то очень сложное получается. Есть подозрение, что производительность будет проседать.

J>>Скорее отсутствие констрейнтов проистекает из версионности. Логически.

C0s>да, в целом, понятно, что какими-то соображениями пользовались, как и понятно, что вся эта ветка вряд ли выявит настоящие причины
C0s>просто субъективно, если бы мне пришлось стоять перед аналогичным выбором, вариант без констрейнтов для реализации графа связей бизнес-объектов я бы, скорее всего, не взял

В идеале можно все сделать хорошо и красиво. Нормализованные таблицы, констрейнты... В реале же приходится и денормализовать порой, и от констрейнтов отказываться...

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


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

J>А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

А почему нет?
На семом деле все немного не так...
Но при необъодимости произвести какие-то рассчеты, соорудить отчет, пусть даже создать малеьнкую утилитку, которая не предусмотрена CBOSS,
было бы мило иметь грамотно обозванные данные.
Кроме того, работай я в CBOSS, тоже было бы приятнее
Как ни крути, везде приятнее!

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

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


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

J>>А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

A>А почему нет?

Потому что money

A>На семом деле все немного не так...
A>Но при необъодимости произвести какие-то рассчеты, соорудить отчет, пусть даже создать малеьнкую утилитку, которая не предусмотрена CBOSS,
A>было бы мило иметь грамотно обозванные данные.

Для решения этой проблемы можно напрячь техподдержку.

A>Кроме того, работай я в CBOSS, тоже было бы приятнее

А если бы работал в CBOSS, вообще бы проблем не было: запускаешь маленький скриптик и смотришь описания полей

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

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

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

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

Это не совсем семантический анализ — Oracle не анализирует смысл данных и наложенные на них ограничения.
Пример, если у нас создана таблица с ограничением на столбец not null:

  create table t1(id number not null)

то для того, чтобы выяснить сколько в таблице записей с ПУСТЫМ ID

  select count(*)
  from t1
  where id is null

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

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

PNC>совершенно необязательно лезть в таблицу, можно на основе констрейнта сразу сказать, что таких записей нет. Однако Oracle этого не делает — он честно лезет в таблицу и все подсчитывает.
Я же сказал, что констрейнты он не учитывает. В отличие от смысла запроса и метаданных. Хотя бывает достаточно интересно. Многое он не доделывает(или тупо показывает что дескать будет делать). Например, если преобразовать твой запрос несколько по другому:

select * from t1 where id<100 and id>1000

Ессно, при разборе такое в любом случае обойти он не сможет. Хотя бы статистику ему для построения планов по 100>x>1000 нужно построить. И вполне понятно, что в таком случае запрос изначально пустой и бесцельный, но эту ситуацию он не обрабатывает.

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

PNC>Поправьте, плз, если способ, на самом деле, есть...

Размножать можно очень ограниченный набор данных. Напримр, иметь табличку с ID и... и... ну пусть дата регистрации приложения, самая первая.
И одну историческую, с FK на этот ID

Уважаемый PNCHLЮ видите ли, все ваши уверения о том, что невозможно создать целостную базу с историчностью, они неверны хотя бы потому, что я видел такую базу

Никаких торомзов, связанных с этим, не наблюдалось. Тормоза были связаны с другими вещами в других местах
Кстати, почему CBOSS, с такими прекрасными принципами, НЕ ОБЕСПЕЧИВАЕТ историчность аккумуляторов?

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


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

J>>>А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

A>>А почему нет?

J>Потому что money
Да да, увы. Вот таланты и пропадают в провинции

A>>На семом деле все немного не так...
A>>Но при необъодимости произвести какие-то рассчеты, соорудить отчет, пусть даже создать малеьнкую утилитку, которая не предусмотрена CBOSS,
A>>было бы мило иметь грамотно обозванные данные.

J>Для решения этой проблемы можно напрячь техподдержку.
Долго и нудно

A>>Кроме того, работай я в CBOSS, тоже было бы приятнее

J>А если бы работал в CBOSS, вообще бы проблем не было: запускаешь маленький скриптик и смотришь описания полей
Но я там у счастью или к сожалению — не работаю

PNC>>P.S. Кстати, вопрос апологетам внешних ключей: а как вообще с их помощью можно добиться ссылочной целостности для исторических данных? По-моему, без размножения данных в таблицах — никак. Ну а коли так, то и "радость от их использования" будет неполной .
PNC>>Поправьте, плз, если способ, на самом деле, есть...

A>Размножать можно очень ограниченный набор данных. Напримр, иметь табличку с ID и... и... ну пусть дата регистрации приложения, самая первая.
A>И одну историческую, с FK на этот ID

Не совсем понял вашу идею. Объясните, плз, на каком-нибудь простом примере, как с помощью FK обеспечить ссылочною целостность, скажем, для двух объектов — "сотрудник" и "подразделение", если о каждом из них хранятся актуальные и исторические данные. При этом необходимо добиться выполнения следующих требований:
1) Данные о подразделении, актуальные на какой-либо момент времени, не могут быть удалены, если в этот момент времени в подразделении были какие-нибудь сотрудники;
2) Сотрудник не может быть привязан "задним числом" к подразделению, для которого не существует актуальной информации на тот момент времени;

A>Уважаемый PNCHL видите ли, все ваши уверения о том, что невозможно создать целостную базу с историчностью, они неверны хотя бы потому, что я видел такую базу

Поделитесь, плз, рассказом о том, что вы видели.

A>Кстати, почему CBOSS, с такими прекрасными принципами, НЕ ОБЕСПЕЧИВАЕТ историчность аккумуляторов?

Обеспечивает — история изменений хранится в упакованном виде в таблице с протарифицированными звонками. Могли бы, конечно, вместо этого сделать версионной таблицу с аккумуляторами, но тогда на каждый звонок было бы 2 инсерта в проиндексированные по одному и тому же полю таблицы — производительность была бы хуже.

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


PNC>Не совсем понял вашу идею. Объясните, плз, на каком-нибудь простом примере, как с помощью FK обеспечить ссылочною целостность, скажем, для двух объектов — "сотрудник" и "подразделение", если о каждом из них хранятся актуальные и исторические данные. При этом необходимо добиться выполнения следующих требований:
PNC>1) Данные о подразделении, актуальные на какой-либо момент времени, не могут быть удалены, если в этот момент времени в подразделении были какие-нибудь сотрудники;
PNC>2) Сотрудник не может быть привязан "задним числом" к подразделению, для которого не существует актуальной информации на тот момент времени;

Уже полночь, и мне трудно сосредоточиться
Навскидку, я сделал бы так примерно:

table emploee(emp_id(PK), sex, date_of_birth, resume_date)
table department(dep_id(PK), name)
table department_hist(depHist_id (PK),dep_dep_id(FK), number_history,start_date, end_date, director_wife_maden_name,...)
table emplpoee_hist(emp_emp_id (FK), number_history, start_date, end_date, depHist_depHist_id(FK), name, passport, salary...)

Ну для особо кривых рук
uunique index on emplpoee (emp_emp_id, number_history) (number_history это порядковый номер, в соответствии с датами. Можно генерить триггером или на уровне приложения, ка Вам нравится:))
uunique index on department_hist(depHist_id, number_history)

A>>Уважаемый PNCHL видите ли, все ваши уверения о том, что невозможно создать целостную базу с историчностью, они неверны хотя бы потому, что я видел такую базу

PNC>Поделитесь, плз, рассказом о том, что вы видели.
Это, наврное, коммерческая тайна ваших конкурентов
Так что, уверен, в вашей компании об этом знают не хуже меня
Если нет — то не мне восполнять этот ПРОБЕЛ



A>>Кстати, почему CBOSS, с такими прекрасными принципами, НЕ ОБЕСПЕЧИВАЕТ историчность аккумуляторов?

PNC>Обеспечивает — история изменений хранится в упакованном виде в таблице с протарифицированными звонками. Могли бы, конечно, вместо этого сделать версионной таблицу с аккумуляторами, но тогда на каждый звонок было бы 2 инсерта в проиндексированные по одному и тому же полю таблицы — производительность была бы хуже.

Ну это да.

Да, это был я Чето браузер не всегда вспоминает, что я должен быть войденным в форум

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

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

C0s>>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

C0s>ну почему же с одинаковой? в основной таблице для объектов какого-то класса — все атрибуты, какие нужны. а вот исторических вспомогательных таблиц к ней нужно столько, сколько есть групп взаимосвязанных атрибутов (т.е. которые меняются обычно вместе), по которым надо сохранять историю. в каждой исторической таблице — ссылка на основную, даты начала-конца периода действия конкретных значений атрибутов и значения каждого атрибута из соотв. группы в указанный период.
C0s>при этом, не каждый параметр объекта требует ведения по нему истории. например, по какому-нибудь галимому вольнотекстовому description я бы не стал вести историю, т.е. имхо следует творчески подходить к выделению множеств исторических атрибутов, чтобы не делать лишнего.

C0s>имхо (и по опыту), обычно для большинства алгоритмов типичной системы требуется последнее состояние объекта, а к историям (состоянию объектов в прошлом) приходится обращаться реже. на oracle, как следствие, исторические вспомогательные таблички можно убирать в отдельный tablespace со всеми вытекающищми.

C0s>вообще говоря, я еще предпочитаю добавлять к каждой группе исторических атрибутов номер версии (как в головной таблице, так и в исторических, причем в последних он становится частью PK, а в головной по нему можно сделать констрейнт уникальности), чтобы во всех случаях, где требуется ссылка на конкретное состояние объекта в прошлом можно было делать выборку по номеру версии (т.е. используя в джойне ключи вместо сравнения дат)

А>>>>2) Первой причины вообще-то достаточно

C0s>>>т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

J>>Скорее отсутствие констрейнтов проистекает из версионности. Логически.

C0s>да, в целом, понятно, что какими-то соображениями пользовались, как и понятно, что вся эта ветка вряд ли выявит настоящие причины
C0s>просто субъективно, если бы мне пришлось стоять перед аналогичным выбором, вариант без констрейнтов для реализации графа связей бизнес-объектов я бы, скорее всего, не взял

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

C0s>имхо (и по опыту), обычно для большинства алгоритмов типичной системы требуется последнее состояние объекта, а к историям (состоянию объектов в прошлом) приходится обращаться реже. на oracle, как следствие, исторические вспомогательные таблички можно убирать в отдельный tablespace со всеми вытекающищми.

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

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

только позавчера отрубили. MTC Москва Jeans 007
Причём на счету еще оставался цент или два, т.е. вообще говоря у меня несколько секунд еще оставалось (минута с Мегафоном обходиться теперь в 39 центов — выживают, сволочи, с обжитых тарифов)

Здравствуйте, PNCHL, Вы писали:
Маленькая просьба к разработчикам CBOSS: не мог бы ты попросить того, кто делал экспорт отчетов в HTML поправить таблички? А то там незакрытые теги, и импорт в Excel съезжает. Пример при необходимости могу предоставить.
Мелочь, а противно. Из-за этого трудно делать анализ своего трафика, даже если оператор предоставляет логи в цифровом виде.

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

PNC>Проблема даже не в нежелании создавать по две таблицы. Проблема в требовании иметь консистентный набор данных не только на текущий момент времени, но и в любой момент времени в прошлом. Использование 2-х таблиц — одна с актуальными, вторая с историческими данными (без последней, актуальной записи), только все усложнит.

как раз требование иметь консистентный набор данных хорошо решается путем разбиения на головную + вспомогательные таблицы. а вот обрабатывать — это уже другое дело

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

PNC> (select * from emp 
PNC>  UNION ALL
PNC>  select * from emp_hist)

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

Автор:
Дата: 16.01.06

чем-то близок

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

J>То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

вообще говоря, надо смотреть от операции изменения. если все четыре параметра идут ее атрибутами вместе — я считаю, что они меняются вместе. по моему опыту редко встречаются классы бизнес-объектов, над которыми требуется много разных операций изменения состояния.

J>Реже, конечно, но не так уж редко, чтобы этими запросами можно было пренебречь. Отдельный таблспейс? Это можно, через секционирование, но что значит "убирать"? Крутить job, который будет делать delete/insert?

я имел в виду сразу создавать эти таблицы в отдельном tablespace.

C0s>>вообще говоря, я еще предпочитаю добавлять к каждой группе исторических атрибутов номер версии (как в головной таблице, так и в исторических, причем в последних он становится частью PK, а в головной по нему можно сделать констрейнт уникальности), чтобы во всех случаях, где требуется ссылка на конкретное состояние объекта в прошлом можно было делать выборку по номеру версии (т.е. используя в джойне ключи вместо сравнения дат)

J>Что-то очень сложное получается. Есть подозрение, что производительность будет проседать.

давай посмотрим.
в моем варианте я вижу, что для проведения операции изменения состояния объекта надо считать его актуальное состояние + последнюю запись из истории, которую надо будет закрыть (select по PK с джойном по уникальному ключу). далее меняем поля (update в главной таблице по PK), закрываем историческую запись (update по PK) и создаем новую историческую запись (insert).
в варианте без исторической таблицы все зависит от наличия номера версии (пока было непонятно из дискусии, присутствует такое или только даты периодов). с ним для выборки потребуется сделать (select по PK и доп. условию, определяющему последнюю версию — флаг там или null в каком-нибудь поле), далее сделать update этой записи (по уникальному ключу, в котором участвует номер версии) и сделать insert новой записи
без номера версии и без исторической таблицы, делая выборки при операциях только на основе дат вообще вижу одно большое заднее место

что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.
а вообще, в процессе проведения операции изменения все равно приходится много чего селектить для проверки правильности проведения операции, поэтому экономить на одном селекте ценой отказа от ключей — как-то странно...

J>В идеале можно все сделать хорошо и красиво. Нормализованные таблицы, констрейнты... В реале же приходится и денормализовать порой, и от констрейнтов отказываться...

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

Здравствуйте, Аноним — Astellar, Вы писали:

А>Навскидку, я сделал бы так примерно:

выкинул все лишнее:

А>table department_hist(depHist_id (PK),dep_dep_id(FK), start_date, end_date, ...)

А>table emplpoee_hist(emp_emp_id (FK), start_date, end_date, depHist_depHist_id(FK), ...)

— это как раз то, что я имел в виду под "размножением данных в таблицах"

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

. Если происходят какие-то изменения "подразделения", возникает новая запись в dept_hist — с новым depHist_id. Для того, чтобы с момента изменения подразделения, "сотрудник" начал ссылаться на новую запись в dept_hist, придется добавить новую запись и в emp_hist — со ссылкой на новый depHist_id. В конечном итоге получится, что при изменении объетка нужно делать новую запись в истории всех ссылающихся на него. По-моему,это не очень хорошо

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

PNC>Пример, если у нас создана таблица с ограничением на столбец not null:
PNC>то для того, чтобы выяснить сколько в таблице записей с ПУСТЫМ ID

PNC>  create table t1(id number not null)

PNC>  select count(*)
PNC>  from t1
PNC>  where id is null

PNC>совершенно необязательно лезть в таблицу, можно на основе констрейнта сразу сказать, что таких записей нет. Однако Oracle этого не делает — он честно лезет в таблицу и все подсчитывает.

с указанным предусловием (id not null) вероятность появления подобного запроса в коде вменяемого программиста равна 0. имхо вряд ли oracle будет что-то писать для академическо-клинических случаев

Здравствуйте, Аноним, Вы писали:

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

Вы не поверите, но откуда идут эти требования мне почему-то известно. наверное, из опыта...

А>Отсюда и модель реализации версионности.

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

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

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

PNC>

PNC>выкинул все лишнее:

А>>table department_hist(depHist_id (PK),dep_dep_id(FK), start_date, end_date, ...)

А>>table emplpoee_hist(emp_emp_id (FK), start_date, end_date, depHist_depHist_id(FK), ...)

PNC>

PNC>- это как раз то, что я имел в виду под "размножением данных в таблицах"

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

. Если происходят какие-то изменения "подразделения", возникает новая запись в dept_hist — с новым depHist_id. Для того, чтобы с момента изменения подразделения, "сотрудник" начал ссылаться на новую запись в dept_hist, придется добавить новую запись и в emp_hist — со ссылкой на новый depHist_id. В конечном итоге получится, что при изменении объетка нужно делать новую запись в истории всех ссылающихся на него. По-моему,это не очень хорошо

из employee_hist должна идти ссылка на department(id), мне вообще странно представить, что история изменения атрибутов департамента имеет какое-то отношение к сотруднику.
при этом я не вижу, какие срезы данных нам становятся недоступными. или я что-то проглядел?

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

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

J>>То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

C0s>вообще говоря, надо смотреть от операции изменения. если все четыре параметра идут ее атрибутами вместе — я считаю, что они меняются вместе. по моему опыту редко встречаются классы бизнес-объектов, над которыми требуется много разных операций изменения состояния.

Насчет "много" — это отдельный вопрос. А насчет "разных" — это бывает. Если каждый из 4 параметров может меняться независимо, но с вероятностью 0.01% за полгода — таблицу отдельную можно не создавать?

J>>Что-то очень сложное получается. Есть подозрение, что производительность будет проседать.

C0s>давай посмотрим.
C0s>в моем варианте я вижу, что для проведения операции изменения состояния объекта надо считать его актуальное состояние + последнюю запись из истории, которую надо будет закрыть (select по PK с джойном по уникальному ключу). далее меняем поля (update в главной таблице по PK), закрываем историческую запись (update по PK) и создаем новую историческую запись (insert).

Последняя запись из истории будет собираться из нескольких таблиц. Это раз. При смене сразу нескольких атрибутов может потребоваться запись в несколько исторических таблиц. Это два.

C0s>в варианте без исторической таблицы все зависит от наличия номера версии (пока было непонятно из дискусии, присутствует такое или только даты периодов). с ним для выборки потребуется сделать (select по PK и доп. условию, определяющему последнюю версию — флаг там или null в каком-нибудь поле), далее сделать update этой записи (по уникальному ключу, в котором участвует номер версии) и сделать insert новой записи
C0s>без номера версии и без исторической таблицы, делая выборки при операциях только на основе дат вообще вижу одно большое заднее место

Очень даже просто. Добавляется конструкция вида '<some_date> between from_date and to_date'. (Затем это очень неплохо можно секционировать по from_date.) При апдейте объекта апдейтится to_date старой версии и инсертится новая версия.

C0s>что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.

Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

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

J>>>То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

C0s>>вообще говоря, надо смотреть от операции изменения. если все четыре параметра идут ее атрибутами вместе — я считаю, что они меняются вместе. по моему опыту редко встречаются классы бизнес-объектов, над которыми требуется много разных операций изменения состояния.

J>Насчет "много" — это отдельный вопрос. А насчет "разных" — это бывает. Если каждый из 4 параметров может меняться независимо, но с вероятностью 0.01% за полгода — таблицу отдельную можно не создавать?
J>Последняя запись из истории будет собираться из нескольких таблиц. Это раз. При смене сразу нескольких атрибутов может потребоваться запись в несколько исторических таблиц. Это два.

я не случайно написал про операцию изменения. чуть более сухим языком:

если имеем для изменения объектов типа A операцию updateObjectA(pk, a1, a2, a3, a4), то a1, a2, a3, a4 — это взаимосвязанные атрибуты. для меня это значит, что одной таблицы истории достаточно

если же имеем две операции для обновления объектов того же типа update1ObjectA(pk, a1, a2) и update2ObjectA(pk, a3, a4), то, скорее всего, a1,a2 я положу в одну таблицу историй, a3,a4 — в другую. при этом ситуацию, когда попросят добавить update3ObjectA(pk, a1, a3) буду рассматривать как недостаточно проработнные требования.

а в целом, сам факт разделения a1,a2 от a3, a4 на уровне требований, для меня значит, что запросы соединяющие a1,a2,a3,a4 вместе будут маловероятными
то бишь, к примеру (более-менее абстрактному), если мне надо услугу, оказываемую абоненту на регулярной основе, и мне важен статус абонента на определенный момент времени, но вообще не волнует его адрес, то в историю статусов абонентов я полезу, а в историю его адресов — нет

J>Очень даже просто. Добавляется конструкция вида '<some_date> between from_date and to_date'. (Затем это очень неплохо можно секционировать по from_date.) При апдейте объекта апдейтится to_date старой версии и инсертится новая версия.

т.е. OR с двумя сравнениями по неиндексированным полям лучше, чем джойн по уникальному ключу? возможно....

C0s>>что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.

J>Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

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

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

C0s>мой анализ виденных систем показывает, что все-таки имеет смысл историю писать именно для историй (визуализаций, разбора полетов и т.п.). а для эффективных вычислений продумывать дополнительные структуры данных, т.е. отделять их от данных для поддержания операций. тогда можно было бы реализовывать событийные (или квазисобытийные) подходы обработки данных и, как следствие, выделение биллинга как модуля из операционной части (вплоть до использования отдельной БД)

Если под "эффективностью вычислений" понимать производительность, то, как я уже писал

Автор: C0s
Дата: 17.01.06

, можно выделить актуальные данные в отдельную секцию и работать с ней практически также, как с отдельной таблицей. Единственный минус — потребуется обязательно использовать Oracle Enterprise Edition, что недешево, но речь сейчас не об этом...

Если под "событийностью" вы понимаете навешивание обработчиков на триггеры таблицы с актуальными данными, то при желании можно применять этот подход и для одной таблицы, хранящей и историю и актуальные данные. Нужно просто сделать VIEW, отбирающую только актуальные данные и навешивать обработчики событий на INSTEAD OF триггеры, которые будут подменять update в VIEW на insert новой записи в историю и update end_date в текущей записи.
Я, однако, считаю, что вместо использования триггеров лучше делать API — функции для выполнения основных операций над объектами и уже в эти функции встраивать вызовы обработчиков событий...


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

Автор:
Дата: 16.01.06

чем-то близок

По поводу "варианта Astellar", я уже ответил

Автор: C0s
Дата: 17.01.06

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

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

C0s>это как же постановщики требований должны промывать разработчикам мозги, что из вполне нормального требования "правильно рассчитвать стоимость услуги в зависимости от статуса абонента и статуса самой услуги (а также других параметров, влияющих на ее стоимость)" выходит требование "делать такую реализацию версионности".

Из неполноты представленного Вами варианта "нормального" требования действительно сложно
Но попробуйте дополнить:
"правильно рассчитвать стоимость услуги в зависимости от статуса абонента и статуса самой услуги (а также других параметров, влияющих на ее стоимость), ДЕЙСТВОВАВШИХ НА МОМЕНТ ОКАЗАНИЯ УСЛУГИ" — и все станет гораздо интереснее

C0s>я к тому клоню, что в норме реализацию выбирают разработчики, а в данном случае она не единственна, поэтому приплетать требования для обоснования конкретной реализации по моим понятиям некорректно

Разработчики и определяли. Если перед Вами задача постоянно (99% случаев) искать версию сложного (т.е. представленного несколькими таблицами) объекта, действовавшую на момент времени, то желание городить еще и отдельные исторические таблицы пропадает напрочь.

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

C0s>а для эффективных вычислений продумывать дополнительные структуры данных, т.е. отделять их от данных для поддержания операций. тогда можно было бы реализовывать событийные (или квазисобытийные) подходы обработки данных и, как следствие, выделение биллинга как модуля из операционной части (вплоть до использования отдельной БД)


Так CBOSS — это в основном тот самый выделенный биллинг и есть. Представлен "дополнительными структурами данных, предназначенных для эффективных вычислений"
А операционная часть... Как бы Вам сказать, на фоне "вычислительной" она невелика и ничуть не хуже работает на "версионных" таблицах.
Объем кода, кстати, существенно меньше.
Объем данных по отношению к Вашему предложению меньше в два раза.
Расходы на поддержку этих данных — в несколько раз.


C0s>

PNC>> (select * from emp 
PNC>>  UNION ALL
PNC>>  select * from emp_hist)
C0s>

А теперь представьте, что эту радость надо расписывать для запроса к 5-10 таблцам?

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

C0s>из employee_hist должна идти ссылка на department(id), мне вообще странно представить, что история изменения атрибутов департамента имеет какое-то отношение к сотруднику.
C0s>при этом я не вижу, какие срезы данных нам становятся недоступными. или я что-то проглядел?

Да, проглядели — предлагаемое вами решение не соответствует описанным выше

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

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

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

J>>Насчет "много" — это отдельный вопрос. А насчет "разных" — это бывает. Если каждый из 4 параметров может меняться независимо, но с вероятностью 0.01% за полгода — таблицу отдельную можно не создавать?
J>>Последняя запись из истории будет собираться из нескольких таблиц. Это раз. При смене сразу нескольких атрибутов может потребоваться запись в несколько исторических таблиц. Это два.

C0s>я не случайно написал про операцию изменения. чуть более сухим языком:

C0s>если имеем для изменения объектов типа A операцию updateObjectA(pk, a1, a2, a3, a4), то a1, a2, a3, a4 — это взаимосвязанные атрибуты. для меня это значит, что одной таблицы истории достаточно

C0s>если же имеем две операции для обновления объектов того же типа update1ObjectA(pk, a1, a2) и update2ObjectA(pk, a3, a4), то, скорее всего, a1,a2 я положу в одну таблицу историй, a3,a4 — в другую. при этом ситуацию, когда попросят добавить update3ObjectA(pk, a1, a3) буду рассматривать как недостаточно проработнные требования.

Ну, помимо существенного усложнения работы на этапе проектирования (определить, какме атрибуты с какими связаны, могут ли они изменяться независимо и т.п.), есть еще один нюанс. Если возможны изменения любого атрибута (к примеру, для информации о человеке: изменения адреса, телефона, фамилии, паспортных данных — вполне независимые операции), то таблицы у нас будут плодиться и размножаться.

C0s>а в целом, сам факт разделения a1,a2 от a3, a4 на уровне требований, для меня значит, что запросы соединяющие a1,a2,a3,a4 вместе будут маловероятными
C0s>то бишь, к примеру (более-менее абстрактному), если мне надо услугу, оказываемую абоненту на регулярной основе, и мне важен статус абонента на определенный момент времени, но вообще не волнует его адрес, то в историю статусов абонентов я полезу, а в историю его адресов — нет

В форме необходимы все данные, и если ты хочешь посмотреть абонента когда-то в прошлом, то придется лезть во все истории.

J>>Очень даже просто. Добавляется конструкция вида '<some_date> between from_date and to_date'. (Затем это очень неплохо можно секционировать по from_date.) При апдейте объекта апдейтится to_date старой версии и инсертится новая версия.

C0s>т.е. OR с двумя сравнениями по неиндексированным полям лучше, чем джойн по уникальному ключу? возможно....

AFAIK, between раскрывается через AND, и обычно существует ключ по <n, from_date, to_date>, где n — номер объекта.

C0s>>>что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.

J>>Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

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

Согласен, друг с другом не надо, но все равно, придется джойнить последовательно.

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

PNC>Если под "событийностью" вы понимаете навешивание обработчиков на триггеры ........
PNC>Я, однако, считаю, что вместо использования триггеров лучше делать API — функции для выполнения основных операций над объектами и уже в эти функции встраивать вызовы обработчиков событий...

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

я имел в виду нечто другое: с точки зрения системы в целом желание включить услугу — это событие, приходящее от оператора системы (или через центр обработки sms-заявок, что не меняет картины). с точки зрения внтутреннго устройства системы обрабатывать это событие мы можем целиком синхронно или поэтапно. так или иначе оно поступает на вход в операционную часть, которая должна проверить, можно ли назначить услугу, не противоречит ли состояние абонента/контракта ее назначению, все ли в порядке с кредитным контролем абонента и в конце после изменения состояния абонента также добавить данные, которые впоследствии позволят при биллинге учесть факт наличия этой услуги.
под квазисобытийным подходом я понимаю ту архитектуру, которая могла бы быть реализована через события асинхронно (например, операционная часть посылает message о том, что у абонента X появляется услуга Y, которое биллинговый модуль у себя принимает и обрабатывает в своей транзакции, заполняя свои биллинговые структуры данных), но на деле реализована путем синхронного вызова из операционной части какого-то API биллингового модуля

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

Здравствуйте, Аноним, Вы писали:

А>Объем кода, кстати, существенно меньше.

меньше, чем где?

А>Объем данных по отношению к Вашему предложению меньше в два раза.

интересно посмотреть, как сформирована оценка. вроде ниоткуда не следует, что будет больше. номера версий — это o-малое от общего объема данных, а больше в моем варианте ничего не добавлялось

А>Расходы на поддержку этих данных — в несколько раз.

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

PNC>>> (select * from emp 
PNC>>>  UNION ALL
PNC>>>  select * from emp_hist)

А>А теперь представьте, что эту радость надо расписывать для запроса к 5-10 таблцам?

в моем варианте таких запросов бы не было, не понятно, какой мой пост дал основание думать об этом

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

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

C0s>>из employee_hist должна идти ссылка на department(id), мне вообще странно представить, что история изменения атрибутов департамента имеет какое-то отношение к сотруднику.
C0s>>при этом я не вижу, какие срезы данных нам становятся недоступными. или я что-то проглядел?

PNC>Да, проглядели — предлагаемое вами решение не соответствует описанным выше

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

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

физически можно навесить триггер, но я бы не стал, просто потому что физическое удаление для такого рода систем операция обычно редкая
да и вообще, как-то я больше беспокоился насчет selectов ("срезы данных"), а не deletов

PNC>Более того, ваше решение исключает очистку таблицы с актуальными данными от несуществующих на текущий момент подразделений, если в этих подразделениях хоть когда-то были сотрудники.

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

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

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

J>Ну, помимо существенного усложнения работы на этапе проектирования (определить, какме атрибуты с какими связаны, могут ли они изменяться независимо и т.п.), есть еще один нюанс. Если возможны изменения любого атрибута (к примеру, для информации о человеке: изменения адреса, телефона, фамилии, паспортных данных — вполне независимые операции), то таблицы у нас будут плодиться и размножаться.

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

J>В форме необходимы все данные, и если ты хочешь посмотреть абонента когда-то в прошлом, то придется лезть во все истории.

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

J>AFAIK, between раскрывается через AND, и обычно существует ключ по <n, from_date, to_date>, где n — номер объекта.

ага, AND, согласен , но не суть важно...

J>>>Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

ну я уже говорил, что ИМХО вероятность одновременного присоединения всех историй мне кажется малореальной

J>Согласен, друг с другом не надо, но все равно, придется джойнить последовательно.

или параллельно. сервер БД, наверное, умеет распараллеливать? а в случае чего ему, наверное, можно и помочь путем разнесения данных для возможности параллельного считывания?

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

C0s>физически можно навесить триггер, но я бы не стал, просто потому что физическое удаление для такого рода систем операция обычно редкая
C0s>да и вообще, как-то я больше беспокоился насчет selectов ("срезы данных"), а не deletов

Речь вообще-то шла о ссылочной целостности и о том, почему в CBOSS нет ключей. Для selectов FK не нужен.

C0s>да и, слабо представляю, ваш-то вариант чем здесь лучше? любое удаление у вас должно привести к потере информации, а если были сотрудники, то как тогда очистка согласуется с требованиями не удалять?

Опять же, речь шла о вариантах использования FK для обеспечения ссылочной целостности исторических данных. Хорошего варианта пока никто не предложил...

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

C0s>Здравствуйте, Аноним, Вы писали:

А>>Объем кода, кстати, существенно меньше.
C0s>меньше, чем где?
Меньше, чем в варианте с выделенными "данными для эффективных вычислений" на отдельном сервере.
Просто потому, что реализовать поддержку как "правильной" схемы, так и "эффективной" в том или ином виде придется

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

Ну как же — оригиналы + "выделенный сервер"

А>>А теперь представьте, что эту радость надо расписывать для запроса к 5-10 таблцам?
C0s>в моем варианте таких запросов бы не было, не понятно, какой мой пост дал основание думать об этом
Был бы другой вариант, еще хуже — поймите, "исторические" данные нужны не "иногда". Они нужны практически всегда

C0s>если же говорить о коде для работы с историческими таблицами, то на стороне ООЯ это не программируется копи-пастом, а делается реюзом кода через делегирование. разговор про программирование вычислений, впрочем, для этой ветки как-бы оффтопик
Зато не оффтопик следующее: есть данные, которые следует организовать наиболее эффективным образом.
Что есть мерило эффективности? ИМХО — решаемые задачи.
"реюз кода через делегирование" — звучит, безусловно, красиво, но ни коим образом не отвечает на вопрос "как эффективно организовать данные" для решения основной задачи биллинговой системы — оценки трафика и выставления счетов.

В этой ветке много раз звучала мысль что МТС "воровал деньги" ввиду неконсистентности данных, которая ворзникла ввиду отсутствия PK/FK. Это неправда.
Механизмы возникновения таких слухов известны и описаны. И первый из них — online отражение на балансе абон. платы в "посекундной" пропорции с начала месяца.
Предложенные решения с разделением данных на оперативные и исторические с единственной целью введения PK/FK:
— Снижают эффективность решения основной задачи
— Повышают стоимость сопровождения системы
— Существенно усложняют либо делают невозможным проведение операций "задним числом"
— Ни коим образом не в состоянии повлиять на возникновение слухов класса "оператор ворует деньги"
Так для чего? Ради искусства? CBOSS — система вполне себе прикладная.

Я без подписи, но все таки
ЗЫ: Когда я пришел в CBOSS, я тоже был полон подобных идей.
Но практические эксперименты (с замерами) убедили меня, что существующая практика для решения поставленных задач подходит все-таки лучше высоконаучных (и даже в чем-то даже правильных) концепций "ограничения целостности обязаны быть реализованы штатными средствами СУБД". Я намеренно опустил "любой ценой". Поскольку цена оказывается выше ожидаемой

Здравствуйте, Аноним, Вы писали:

А>ЗЫ: Когда я пришел в CBOSS, я тоже был полон подобных идей.
А>Но практические эксперименты (с замерами) убедили меня, что существующая практика для решения поставленных задач подходит все-таки лучше высоконаучных (и даже в чем-то даже правильных) концепций "ограничения целостности обязаны быть реализованы штатными средствами СУБД". Я намеренно опустил "любой ценой". Поскольку цена оказывается выше ожидаемой

Этот спор бесконечен. У вас всегда будут оппоненты, которые будут упорно доказывать, что существует элегантное решение с применением PK/FK и что именно это решение и является единственно правильным. На RSDN публика еще более или менее терпима. Поднимись такой вопрос на SQL.RU, вы бы устали отписываться от наездов "крутых знатоков", которые прочитали толстые книжки и уверовали в написанное всеми фибрами своей души. На деле же людей, которые действительно имеют реальный опыт создания и (что немаловажно) длительного сопровождения и доработки систем такого уровня сложности как CBOSS, на этих форумах единицы. А уж тем более, если речь идет о таких материях как управление сложностью и затратами на сопровождение — ведь подавляющее большинство наших доморощенных систем не живут более 2-4 лет.

PS: Единственное, что можно заметить в отношении CBOSS с учетом результатов данного обсуждения — это то, что в свое время выбор именно ORACLE в качестве базовой СУБД для этой системы возможно и не был так уж оправдан. Тут по требуемым характеристикам даже лучше смотрелись бы объектные СУБД а-ля Versant, ObjectStore ... Хотя понятно, что в те годы, когда создавалась архитектура системы CBOSS (да и сегодня тоже) найти в России специалистов по нереляционным системам практически невозможно. У нас вообще какой-то вывих в головах архитекторов в данном вопросе — ORACLE пытаются втиснуть везде — и к месту, и не к месту. Впрочем, это уже оффтоп ...

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

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

Разберем как бы конкретно я, поступил в таком конкретном случае. Может в вашем случае нужно по другому. Но ИМХО, что все несдотатки либо устраняются, либо в данном конкретном случае являются даже достоинствами.

table emploee(emp_id(PK), sex, date_of_birth, resume_date, date_fin)
table emplpoee_hist(emp_emp_id (FK), start_date, end_date, ...)
table department(dep_id(PK), name, date_fin)
table department_hist(depHist_id (PK),dep_dep_id(FK), start_date, end_date, ...)

Истории друг на друга не ссылаются.

Плюсы
1. Нельзя удалить подразделение, если в нем, кто-то когда-то работал. YES. Дополнительная защита от дурака.
2. Нельзя удалить подразделение, если у него есть хоть, какая-нибудь история. YES.
3. Нельзя удалить сотрудника, если есть хоть какая-ниюудь история. YES.
4. Нельзя что-то вносить задним числом. YES. Знаете сколько проблем возникает из-за таких внесений!

Возможные проблемы.
1. Проблема в возможности удаления истории. С ходу не приходит способов гарантирующих невозможность удаления истории.
2. Проблема с большими запросами. Ну в общем и целом это погоды во многих случаях не делает. Почему можно порассуждать отдельно, но не примере из 4 таблиц, поскольку это не смещно.

Минус
1. С ваших слов начинаются проблемы со скоростью работы с историей.

Зачем date_fin? Так вот date_fin, для отображения пользователю и запрета работы изменять какие-либо его данные вообще. Назначать сотрудников и т.д.

Можно еще несколько навороченный вариант для защиты.

table emplpoee_addhist(emp_emp_id (FK), start_date, date_fin)
table department_addhist(depHist_id (PK),dep_dep_id(FK), date_fin)

Остальное в прежней силе.

Если похимичить с данным подходом. При довольно неплохой переносимости для разных БД можно довольно хорошую защиту от дурака сделать. Хотя от м..... все равно не спасет. Поскольку он и триггеры отключит и PK/FK удалит. Только в данном случае он уже занимается модификацией структуры базы данных, а за это уже пора бить по рукам. То есть строчка в договоре, о том что разработчик не отвечает за правильную работу программы в случае ручного модифицирования структуры базы данных ОБЯЗАНА быть ИМХО. Так что сумму можно будет запросить приличную, чтобы отбить желание это делать.

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

Вообще главное, затруднить менять данные ручками, так чтобы отбить к этому желание.

Здравствуйте, Alexey Rovdo, Вы писали:
А>>Но практические эксперименты (с замерами) убедили меня, что существующая практика для решения поставленных задач подходит все-таки лучше высоконаучных (и даже в чем-то даже правильных) концепций "ограничения целостности обязаны быть реализованы штатными средствами СУБД". Я намеренно опустил "любой ценой". Поскольку цена оказывается выше ожидаемой

AR>Поднимись такой вопрос на SQL.RU...
Я там пасусь время от времени. Форум более профильный. Там есть вполне разумнеые люди и профиль создать оказалось не лениво

AR>выбор именно ORACLE в качестве базовой СУБД для этой системы возможно и не был так уж оправдан.
Может быть, Вы и правы. Я не имею опыта работы с нереляционными СУБД (кроме непоказательных экспериментов с cache), поэтому мне сложно судить.
Единственное подобие "контраргумента" звучит так: все "приличные" (с точки зрения объемов/функционала) конкуренты работают на Oracle
С другой стороны, не будь CBOSS на oracle — лет несколько назад я бы сюда не попал и не смог бы принять участия в столь интересной дискуссии

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

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

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

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

У мегафон тоже самое.

Здравствуйте, Аноним, Вы писали:

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

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

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

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

А>У мегафон тоже самое.

Сюда зайди, посмотри: http://www.cboss.ru/products/cbossrtb.html
Приходилось интегрироваться с этим биллингом, биллинг действительно хороший с т.з. real-time оценки.