Если есть возможность, то менять нужно структуру базы, табличка Calls у Вас явно не укладывается даже в 1-ю НФ, поскольку поле DialedNumber содержит составные данные а именно - Код звонка и Номер Звонка. Пэтому и такие трудности с выборкой.

Недообъяснял

Я имел в виду то, что вам нужно как минимум разделить столбец DialedNumber на два, хотя подозреваю что вся схема данных непродумана и несоответствует предметной области. Если Ваша система сейчас только разрабатывается я бы посоветовал серьезно взяться за разработку схемы данных. Почитайте Дейта.

>Идея разделять номер на код+остаток была, но она не годится в силу того что для разных тарифных планов могут использоватся >разные набор кодов, например

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

Вобщем я тут посмотрел внимательно беру свои слова назад, правда не совсем, ошибка все таки у Вас есть, поскольку я не вижу связи Rates c Calls если бы RateID был PK, то все можно было бы сделать просто:

update Calls set Calls.Cost = Calls.Duration * Rates.Rate from Calls, Rates where Calls.RateID = Rates.RateID

В Вашем случае можно обойтись, но не советую, таким запросом:

update Calls set Calls.Cost = Calls.Duration * Rates.Rate from Calls, Rates
where Calls.RateID = Rates.RateID and Rates.DestinationCode = substring(Calls.DialingNumber, 1, len(Rates.DestinationCode))

Вобщем совет - определитесь с ключиками

P.S. Вопрос: а вычисляемое поле сознательно храните?

Да, Вы правы нужно модифицировать Rates, поскольку номер есть номер, но код все равно хранить надо отдельно, вот только непонятно назначение поля RateID.

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

Ууууу, как все запущено дядюшка Кодд учит нас убирать повторяющиеся группы из таблиц
Табличка то Rates у вас в 1-й НФ, вы запихнули две сущности в одну, мой совет, тарифные планы и коды разделить надобно, всей постановки не знаю, но возможно, что код звонка нужно просто атрибутом запихнуть в Call, ну что бы сказать поточнее надо анализировать. Кстати почитайте Дейта, хотя бы до глав по нормальным формам, уделив внимание на аномалим обновления, вставки и удаления в различных формах - гарантирую Вы порадуетесь.

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

Ндааа..... денормализация позволяет ускорить select, а уж никак не update 8-[]
Интересно как Вы себе это представляете? Подумайте сами, вместо обновления одной записи Вам приходится обновлять набор записей.

Запрос щас проверять лень, потом посмотрю, но даже если не работает, ситуация лечится просто
Вопрос: если у Вас в Rates составной PK, то почему FK у вас состоит из части PK????!!!

>Когда идет UPDATE на 1000000 записей то тут не до нормальных форм.
Очепятка что ли?

Насколько я понял отношение между Rates и Calls - один ко многим, соответственно составной PK Rates должен присутствовать как FK в Calls и проблем как не бывало

>Да в этом то задача и состоит чтобы определить какому PK в Rates соответствует запись в Calls.

Уффф... Victor, если бы Вы внимательно читали литературу по реляционным базам, то Вы бы знали, что для этих целей используют связку PK -> FK и не придумывали бы себе проблем.

Да уж, действительно на разных языках

Вот что я хотел сказать:

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

Уфф замаялся я совсем с Вами, по моему я объяснил достаточно подробно. Если непонятно я уже ничего сделать не могу, учите матчасть

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. Как установить связь в СУБД я писал Вам в ответе на Ваше письмо, если оно не пришло, я повторю

2 All
Народ, аууу, либо я ничего совсем не понимаю, либо меня никто не понимает или не хочет слушать
Проблему, после ее рассмотрения на самом деле можно разделить на две:
1. Ошибка проектирования, состоящая в том, что не связаны таблицы, для которых необходимо поддерживать соответствие.
Я честно говоря не представляю как будет выглядеть запрос, о котором я писал в предыдущем постинге, а именно - Выдать суммы потраченные клиентами за месяц по каждому коду (считай тарифу). В случае, если Виктор будет использовать только ваши решения.

2 Проблема разделения разных данных, пришедших одним блоком.
Возможно (но не обязательно) если будет устранена проблема1, проблема2 не будет такой уж страшной, а если нет, то может стоит подумать о решении обеих проблем. Чой то мне кажется, что без устранения проблемы1 у Виктора могут появиться проблема3....проблемаN.

Я не прав?

>Увы, пока остаюсь при своих.

запросов - Выдать суммы потраченные клиентами за месяц по каждому коду (считай тарифу) или подобных у Вас не будет никогда??

А изменения однажды занесенных Rate вы запрещаете?

А Rate у Вас не меняется со временем никогда?? А если меняется, данные по стоимости звонков у Вас лежат только в Cost?

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

>> 2 Проблема разделения разных данных, пришедших одним блоком.
>Что имеется в виду?

О бог мой!!! Я же говорил, что по сути DialedNumber содержит два атрибута - Код и собственно номер. В общем вы можете объявить его одним атрибутом т. е. хранить его просто как номер, но от кода Вам никуда не деться это такой же атрибут звонка как и номер

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

Удачи.