Господа, столкнулся я с биллинговой системой 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.
Большая просьба отвечать под цитируемым текстом и выкидывать из ответа лишние цитаты.