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

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

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 , целостность на тригерах, и все нормально работало

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