2 SergSuper

Для двух табличек я и написал т. е. в Calls присутствует RateID, а DestinationCode почему то нет.
Чиста канкретна схему данных я написать не могу, для этого анализ ПО нужен, уж пусть Victor этим и займется.

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

>Так его потому и нет, что это часть решаемой задачи - необходимо по номеру определить какай DestinationCode ему соответсвует и >по найденному DestinationCode определить тариф.
А откуда он у Вас берется в Rates?

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

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

2 Victor

Присылайте, у меня power designer, но он по моему умеет открывать ErWin диагграмы

2 SergSuper
>Ну и как тут не вспомнить фразу: "Кто умеет тот делает, кто не умеет тот учит".

Спорить не буду, может быть так и есть.

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

1. Вам не кажется, что таблицы Calls и Rates должны быть связаны?
2. В таблице Calls вы храните вычисляемое поле Cost, с чем это связано?
3. Какое назначение поля RateId? Как я понимаю это идентификатор, идентификатор чего?
4. Каким образом заносятся значения поля DestinationCode?

Удачи

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

Я подожду ответы Victorа, потом отвечу и Вам, ОК?

>Генадий,
>а ERX тоже не открывается?

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

>Они и будут связаны когда в результате расчета станет известно какой тариф применять, т.е. UPDATE будет вида
>set cost=,rateid=,destinationcode=

То есть Вы хотите установить связь программно. А почему Вас не устраивает связь средствами СУБД?

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

Понятно, спасибо.

>Это идентификатор тарифного плана. Если более подробно:
Понятно

>ну и соответственно
>Calls -звонки сделанные клиентами
>(Account,DialedNumber,Duration,-известны
>RateId,Cost,DestinationCode) -вычисляются

На каком этапе вычисляется DestinationCode?
И на каком этапе проводится обновление Calls, я имею в виду поле Cost?

>Rates - детали тарифных планов.

Насколько я понимаю Rates это тоже справочник?

>Есть справочник кодов - из него выбираются.

Дайте пожалйста структуру справочника.

2 SergSuper
>Вроде же они должны быть связаны и понятно как.
>Ну и что по этому поводу в умных книжках пишут?

Как и обещал отвечаю:
Должны быть связаны и связаны все же несколько разные понятия. Понятно кому? И интересно как?

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

>И это тоже Ваши слова:
>", т. е. поля составляющие первичный ключ Rates должны присутствовать Calls, таким образом будет организовано однозначное >соответствие."

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

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

>не совсем понял, что вы имеете в виду под:
>"То есть Вы хотите установить связь программно. А почему Вас не устраивает связь средствами СУБД?"

Программно это то, что Вы показывали ранее, т. е. в момент обновления Calls вы с помошью цикла определяете соответствие двух таблиц, проводите обновление и все, связь теряется, предположите теперь, что Вам нужно выдать отчет по клиенту с данными о том по каким кодам он звонил и например, сумму оплаты по каждому коду, Вы что снова будуте цикл использовать??
Я не знаю динамики Вашей системы, но косвенно по Вашим описаниям предполагаю, что обновление поля Cost происходит пакетно, т. е. обновляются множество записей уже после того как данные по звонкам занесены. Естественно цикл работает на каждой записи и это не повышет быстродействия системы. А теперь предположите еще и такое - значение Rate было введено с ошибкой и спустя какое то время ошибка обнаружена - снова цикл?

Связь обеспечивается СУБД с помощью связки Первичный ключ - Внешний ключ, эта связь обеспечивает однозначную и непротиворечивую связь обеих таблиц. В вашем случае эта связка усложняется из-за поля Cost, значения, которого необходимо проверять с промощью триггеров, как минимум после обновления таблицы Rates. Возможны и другие случаи при которых нужна такая проверка, но это уже виднее Вам, т. к. я не знаю вашей системы в целом. В случае этой связи Вам при занесении записи в Calls необходимо будет записать в нее RateID и DestinationCode как раз именно для установления связи, в этот же момент можно записать и Cost но не обязательно. Проблема определения DestinationCode в этом случае будет не проблемой базы, а скорее проблемой приложения, которое собственно и заносит данные в Вашу таблицу. Сделать это можно будет как минимум не сложнее Вашего решения, однако определение DestinationCode в данном случае будет производиться только один раз!
Как я уже говорил, я не знаю как к Вам приходят номера, но предполагаю, что не по 100 млн. одновременно, соответственно определение DestinationCode пусть даже и в цикле но по мере поступления записей звонков, вероятнее всего не будет сильно сказываться на производительности системы.

Уфф, аж устал набивать
Надеюсь понятно объяснил, если нет, то чесслово понятней не умею

P.S. Как установить связь в СУБД я писал Вам в ответе на Ваше письмо, если оно не пришло, я повторю