powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Ответ разработчика
25 сообщений из 127, страница 5 из 6
Ответ разработчика
    #37082777
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergeyAKM А если серьезно, то данный документ просто курам на смех. Но хорошо хоть последнее предложение все объясняет:
автор ...среда разработки Delphi хорошо известна IT-специалистами...

читать как - "а больше все равно нечего и не знают". С этого и надо было начинать.
На счет 2-звенки вот например статья , где приводятся некоторые аргументы которые в рамках полного жизненего цикла ПО более значимы, чем " среда разработки Delphi хорошо известна IT-специалистами ". Может сменить таких специалистов .

а может не слушать таких советчиков? Что сказать то хотели, кроме ссылок на статьи, которых масса (сколько авторов - столько и мнений)?
...
Рейтинг: 0 / 0
Ответ разработчика
    #37082795
GregTk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PanshinKachalov,

авторМоя личная точка зрения - обработки больших объемов данных(таких которые система не может обработать за приемлемое время) вообще быть не должно
Я бы не стал так говорить. Не должно быть таких систем, которые за приемлемое время не могут обработать большие объемы данных. Хочу спросить знает ли кто как идет обработка телефонных звонков в биллинговых системах? Ведь там ежечасно нужно обрабатывать миллионы записей иначе большие объемы данных.

Какое решение приемлемо? Трехзвенка? DBA?

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

А собственно по делу то в чем проблема для трех-звенки в вашем приведенном случае, что это за такая невероятна обработка? Может поделитесь о чем речь?
...
Рейтинг: 0 / 0
Ответ разработчика
    #37083038
rilio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergeyAKM А насчет Delphi было бы интересно узнать вот что: на сколько я знаю за бугром Delphi скорее мертв чем жив. То есть мощного сообщества вокруг этого добра нет.
Не скажу про европу, но в USA Delphi (точнее, C++ Builder, но это одно и то же :) вполне себе неплохо поживает. Ниша примерно та же, что и у нас - небольшие (2-10 чел.) софт-компании, "самописки" на предприятиях, разработчики shareware. А их там очень много.

"Мощного сообщества", действительно, нет. И "множества каркасов на все случаи жизни" тоже нет. IMHO, в этом и плюс. Delphi устоялся как продукт, цели ясны, задачи определены, проблемы решены... Да, стоит недешево, но быстро окупается.

PS: мне лет 10 назад пришлось дорабатывать одну систему на COBOL-е, которая была написана еще лет за 15 до того (VAX, OpenVMS)... Ну так она и до сих пор прекрасно себя чувствует, кто-то ее там развивает.
PPS: кстати, "трехзвенка"
...
Рейтинг: 0 / 0
Ответ разработчика
    #37083188
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PanshinЯ бы не стал так говорить. Не должно быть таких систем, которые за приемлемое время не могут обработать большие объемы данных. Хочу спросить знает ли кто как идет обработка телефонных звонков в биллинговых системах? Ведь там ежечасно нужно обрабатывать миллионы записей иначе большие объемы данных.

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

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

По моему опыту, эффективную трехзвенку просто сложнее сделать. Хорошая архитектура предполагает, что ее разработчик умеет обращаться и с БД, и с AppLayer и понимает, какие задачи где должны быть. Таких архитекторов довольно мало. А остальные так и сваливаются - либо в тотальный ORM либо в двузвенку.

И, да, горизонтальное масштабирование БД заметно проще (и на порядке дешевле) делать через applayer. Впрочем, это уже относится к нагруженным системам, явно не относящимся к топику.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37083194
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Panshinя спрашивал о решении задачи обработки звонков в реальном времени.

Ну, средствами БД реальное время, конечно, не получить.
Как бы я делал эту систему (при требованиях по масштабированию до 10M одновременных звонков, например):

1) Персональные данные по счету (это не всегда номер телефона) - в БД. БД шардится по счетам, понятное дело.
Стратегия шардинга - решается отдельно, через applayer, конечно (а других возможностей и нет сейчас).
2) При появлении звонка - подгружаем на сервер из AppLayer необходимые данные из БД
Тут можно поиграть с кэшированием этих данных и решить, выгоднее использовать кэш БД или что-то внешнее. Ну и поиграть с логикой хранения данных в БД, например, денормализация в блоб может обеспечить чтение всех данных по счету за одно физическое чтение. Сильно зависит от конкретной БД.
3) Обеспечиваем, что бы все операции с конкретным счетом в конкретный момент времени выполнял только один appserver (скорее всего через аналог шардинга, тут есть множество тонкостей). Это нужно для гарантии правильности при одновременных действиях со счетом (типа, во время разговора человек еще и в инете сидит и через него же докидывает денег на счет).
4) В процессе звонка ведем учет изменения счета (да хоть раз в секунду пересчитываем остаток).
Тут куча возможных оптимизаций, например, считать, на сколько при текущем тарифе хватит разговора и пересчет делать только по исчерпанию срока.
5) Промежуточные данные - в распределенном дублированном кэше (ну, еще можно в локальный лог на диске писать изменения - для гарантии. Потоковая запись - это быстро). Зависит от заявленных требований по надежности.
6) По окончании звонка - изменяем БД.

На вскидку, один сервер приложений стандартного вида (где-то на 3k$) будет держать до 100K одновременных разговоров (если не заводить по треду на разговор. Если заводить - то гораздо, гораздо меньше - но зачем делать глупости).
БД - один дешевый шард где-то на 50K одновременных разговоров (если разговор - где-то минута), лимитируется скоростью дисковой подсистемы (и, в конечном счете, скоростью seek и надежностью кэша на запись).

Все железо - стоит дешевле, чем лицензия на один Oracle EE :)
Лицензии - можно вообще обойтись бесплатными БД. Я бы взял DB2 Express C с поддержкой, это, конечно, каких-то денег стоит, но все равно дешевле, чем покупка старших лицензий с партишонингом и прочими радостями жизни...

А, отчеты - конечно, строим по standby базам. Ну, там куча разных стратегий - надо смотреть на конкретные требования. Может, будет выгодно сливать в какую-то общую БД (но вряд ли, разве что откат хороший предлагают).
И, разумеется, никакого ORM.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37083357
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Ну, архитектура биллинг-систем известных мне телекомов - это тихий ужас. Там все очень медленно, не слишком надежно и неимоверно дорого. Собственно, неумение сотовых операторов рассчитывать остаток на счете в процессе разговора - замечательное свидетельство плохой архитектуры.
...
По моему опыту, эффективную трехзвенку просто сложнее сделать.

а зачем что-то делать? Все это можно покрыть, например, за счет молодоженов . А в форумах, важно поправляя пенсне на носу, рассуждать какой крутой биллинг...
...
Рейтинг: 0 / 0
Ответ разработчика
    #37083522
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PanshinKachalov,
Опять двадцать пять. Хотя я спрашивал о решении задачи обработки звонков в реальном времени. Но можно говорить и о массиве за 5 лет.
Разве вы решаете абсурдна обработка пятилетнего массива или нет?
Вы должны это сделать.
При такой постановке задача с программистской территории явно склонилась в сторону DBA. Или вы будете писать под эту задачу трехзвенку с клиентом?
- Вы умело проигнорировали мой ответ:
Kachalov Более подробно о возможном решении задачи в Гугле - партиционирование (partitioning).
...
мне кажется более логичным когда задача партиционирования ложится не на СУБД, а на архитектора проекта, который исходя из предполагаемого объема данных и связанных с ними задач осуществляет партиционирование на этапе планирования структуры данных

- поясняю: когда требуется обрабатывать большие объемы данных этот вопрос должен быть решен на уровне архитектуры (структуры данных) таким образом чтобы не приходилось обрабатывать больших объемов данных. Когда база данных представляет собой одну таблицу в которую тупо валятся все данные очевидно что в дальнейшем будут проблемы при обработке этих данных (имеющих разную востребованность и актуальность). Разбор данных по таблицам меньшего объема желательно производить еще на этапе занесения данных, либо как вариант осуществлять периодическую процедуру "архивации" (переноса данных с низкой актуальностью в архивные таблицы) и предварительного анализа "архивируемых" данных
...
Рейтинг: 0 / 0
Ответ разработчика
    #37083702
Фотография quaid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergeyAKMЕсли взять например платформу .NET, то она может похвалится достаточно динамично развивающимся C#... А у делфей как?У Дельфей хорошо. По сравнению с "семеркой" Delphi XE - это земля и небо. Вкратце - введены расширения синтаксиса, введены новые интерфейсные и проектные плюшки IDE, введен юникод, дженерики, нехило обновлена стандартная библиотека.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37084015
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kachalov,

насколько понимаю, речь всё-таки идёт о том, что объем оперативных данных, требующий обработки - довольно велик
Поэтому давайте забудем навечно об огромном массиве за 1-2-5 лет и т.д. (хотя в некоторых случаях и такие периоды используются при оперативных расчетах)
...
Рейтинг: 0 / 0
Ответ разработчика
    #37084143
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lockyнасколько понимаю, речь всё-таки идёт о том, что объем оперативных данных, требующий обработки - довольно велик
Поэтому давайте забудем навечно об огромном массиве за 1-2-5 лет и т.д. (хотя в некоторых случаях и такие периоды используются при оперативных расчетах)
- хорошо, "забыли" про 5-2-1 лет, ну тогда что нам мешает "забыть" и про 6-3-1 мес, и про 30-15-1 дней? Или "забыли" про РФ-губерния-город и т. п. Иначе говоря что мешает оперативно работать с тем объемом данных который реально обработать в приемлемый интервал времени, дробя входящие данные на отдельные таблицы? Усложнив структуру данных вполне можно уменьшить объем данных с которым приходится работать.

Обработать данные за 5 лет можно путем обработки 5 таблиц содержащих данные за год :)
...
Рейтинг: 0 / 0
Ответ разработчика
    #37084606
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kachalovlockyнасколько понимаю, речь всё-таки идёт о том, что объем оперативных данных, требующий обработки - довольно велик
Поэтому давайте забудем навечно об огромном массиве за 1-2-5 лет и т.д. (хотя в некоторых случаях и такие периоды используются при оперативных расчетах)
- хорошо, "забыли" про 5-2-1 лет, ну тогда что нам мешает "забыть" и про 6-3-1 мес, и про 30-15-1 дней? Или "забыли" про РФ-губерния-город и т. п. Иначе говоря что мешает оперативно работать с тем объемом данных который реально обработать в приемлемый интервал времени, дробя входящие данные на отдельные таблицы? Усложнив структуру данных вполне можно уменьшить объем данных с которым приходится работать.

Обработать данные за 5 лет можно путем обработки 5 таблиц содержащих данные за год :)
Ну, про 6-3-1 месяц нам мешает забыть хотя бы наличие годового-квартального-месячного отчета. Как минимум.
Во вторых, задача "работать только с тем объемом данных, который мы можем обработать за указанное время" - немного неправильно поставлена.
правильно, с моей т.з. - обработка всего необходимого объема данных должна происходить не более чем за указанное время.
Более того, иногда (зачастую) - невозможно усложнить структуру данных, раздробив данные на отдельные таблицы - в силу того что это уже было произведено, но и каждая "дробная" часть сама по себе вельми велика.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37085033
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
немного не в тему, но предполагаю, что здесь есть гуру реализации сложных запросов... :)

как запихать в CASE подзапрос?
т.е.

SELECT
CASE doclist.kodreg
WHEN 48 THEN '48'
WHEN 62 THEN '62'
ELSE 'Not yet known'
END AS rjl
FROM doclist

работает
...
Рейтинг: 0 / 0
Ответ разработчика
    #37085059
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Chopнемного не в тему, но предполагаю, что здесь есть гуру реализации сложных запросов... :)

пардонте...
разобрался - пытался запихать разнотипные значения...
...
Рейтинг: 0 / 0
Ответ разработчика
    #37085511
trdm_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
W3571С отметается по идеологическим причинам. :)
Мы от неё как раз отказались.
озвучте причины пожалуйста?
...
Рейтинг: 0 / 0
Ответ разработчика
    #37085528
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Раз уз пошел холивар на тему - где делать бизнес-логику - в БД или в app-слое -
вставлю свои 5 коп.
Вот текст процедуры оптимальной группировки (ящичных партий в полные паллеты)
на языке Progress 4GL.
Завидуйте, прогресисты могут решить, кто именно будет отрабатывать их логику -
основной процесс клиентского приложения, app-сервер или триггер в БД в любой
момент ЖЦ системы. Делается простой настройкой типа строчки в ini-файле.
А код будет одинаковым !!!
При этом исполнение и оптимизация операций с БД (for each, find first, запись и пр.) работает
одинаково, независимо от того, какой брокер запросов это исполняет.
Также в текст можно вставлять операции на диалекте sql89. В этом фрагменте их нет,
так как SQL-брокер Progress не умеет работать с временными таблицами.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
DEFINE TEMP-TABLE Result3 NO-UNDO 
FIELD warecode as character
FIELD rid-cell as integer  
FIELD rid-lots as integer  
FIELD quan as decimal      
FIELD quan-pal as decimal  
FIELD cell as character    
FIELD koef as decimal
FIELD n-pal as integer
FIELD warename as character
FIELD fullwarename as character
INDEX i1 warecode cell DESC
INDEX i2 n-pal
INDEX i3 warecode warename koef desc cell.

procedure SortOnGroup :
def var iPallete as integer.
def var stGoods as character.
def var stGroup as character.
def var fVolumeCurrent as decimal.
def var stGoodsCurrent as character.
def var stGroupCurrent as character.
def var fKoefCurrent as decimal.
def var bGoodsExist as logical.

iPallete =  1 .
stGoods = '0'.
stGroup = ''.
bGoodsExist = true.

repeat while bGoodsExist:

   /* вычисляем, сколько уже на текущей паллете занято места */
   fVolumeCurrent =  0 .
   for each result3 where result3.n-pal = iPallete no-lock:
      fVolumeCurrent = fVolumeCurrent + result3.koef.
   end.

   /* ищем текущий товар */
   find first result3
      where result3.warecode = stGoods and result3.n-pal =  0 
      use-index i3 no-error.
   if available result3 then do:
      stGoodsCurrent = result3.warecode.
      stGroupCurrent = result3.warename.
      fKoefCurrent = result3.koef.
      if fVolumeCurrent + fKoefCurrent <=  1 . 05  then do:
         result3.n-pal = iPallete.
         stGoods = stGoodsCurrent.
         stGroup = stGroupCurrent.
      end.
      else do:
         /* Весь товар этого наименования не вмещается на эту паллету. */
         /* Проверить, в этой паллете только текущий товар ? */
         find first result3
            where result3.n-pal = iPallete and result3.warecode <> stGoods
            no-lock no-error.
         if available result3 then do:
            /* Есть и другой товар в этой паллете, убрать текущий товар из нее. */
            for each result3
                where result3.warecode = stGoods and result3.n-pal = iPallete:
               result3.n-pal =  0 .
            end.
            fVolumeCurrent =  0 .                                           
            for each result3 no-lock                                      
                where result3.warecode = stGoodsCurrent and result3.n-pal =  0 :
               fVolumeCurrent = fVolumeCurrent + result3.koef.           
            end.
         end.
         else do:
            fVolumeCurrent =  0 .                                           
            for each result3 no-lock                                     
                where result3.warename = stGroupCurrent and result3.n-pal =  0 :
               fVolumeCurrent = fVolumeCurrent + result3.koef.            
            end.
         end.
         /* Начать новую паллету или перейти к существующей. */
         run GetPalleteNumber(fVolumeCurrent, output iPallete).
         stGoods = stGoodsCurrent.
         stGroup = stGroupCurrent.
      end.
   end.
   else do:
      /* ищем текущую группу */
      find first result3
          where result3.warename = stGroup and result3.n-pal =  0 
          use-index i3 no-error.
      if available result3 then do:
         stGoodsCurrent = result3.warecode.
         stGroupCurrent = result3.warename.
         fKoefCurrent = result3.koef.
         if fVolumeCurrent + fKoefCurrent <=  1 . 05  then do:
            result3.n-pal = iPallete.
            stGoods = stGoodsCurrent.
            stGroup = stGroupCurrent.
         end.
         else do:
            /* Начать новую паллету или перейти к существующей. */
            fVolumeCurrent =  0 .                                          
            for each result3 no-lock                                     
                where result3.warename = stGroupCurrent and result3.n-pal =  0 :
               fVolumeCurrent = fVolumeCurrent + result3.koef.           
            end.
            run GetPalleteNumber(fVolumeCurrent, output iPallete).
            stGoods = stGoodsCurrent.
            stGroup = stGroupCurrent.
         end.
      end.
      else do:
         /* ищем следующий нераспределенный товар */
         find first result3
              where result3.n-pal =  0 
              use-index i3 no-error.
         if available result3 then do:
            stGoodsCurrent = result3.warecode.
            stGroupCurrent = result3.warename.
            fKoefCurrent = result3.koef.
            if fVolumeCurrent + fKoefCurrent <=  1 . 05  then do:
               result3.n-pal = iPallete.
               stGoods = stGoodsCurrent.
               stGroup = stGroupCurrent.
            end.
            else do:
               /* Начать новую паллету или перейти к существующей. */
               fVolumeCurrent =  0 .
               for each result3 no-lock
                   where result3.warename = stGroupCurrent and result3.n-pal =  0 :
                  fVolumeCurrent = fVolumeCurrent + result3.koef.
               end.
               run GetPalleteNumber(fVolumeCurrent, output iPallete).
               stGoods = stGoodsCurrent.
               stGroup = stGroupCurrent.
            end.
         end.
         else do:
            /* больше товаров к группировке нет */
            bGoodsExist = false.
         end.
      end.
   end.

end.

end.

Похоже сделано в мире Foxpro, но это файловая СУБД, и сервер приложений на Foxpro - это
как-то ...
...
Рейтинг: 0 / 0
Ответ разработчика
    #37085788
warhead2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
strizhРаз уз пошел холивар на тему - где делать бизнес-логику - в БД или в app-слое -
вставлю свои 5 коп.
Вот текст процедуры оптимальной группировки (ящичных партий в полные паллеты)
на языке Progress 4GL.


В этой процедуре есть кусочуки кода с коментариями, которые, по моему мнению, могут быть кандидатами на выделения в подфункции. Почему их не выделили - ограничение языка или предпочтения?
...
Рейтинг: 0 / 0
Ответ разработчика
    #37086751
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
warhead2В этой процедуре есть кусочуки кода с коментариями, которые, по моему мнению, могут быть кандидатами на выделения в подфункции. Почему их не выделили - ограничение языка или предпочтения?

Предпочтения конкректного программера.
И, кстати, из-за предпочтений же процедура сделана циклом, а не с помощью рекурсивных вызовов.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37087539
svcoder
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
strizhРаз уз пошел холивар на тему - где делать бизнес-логику - в БД или в app-слое -
вставлю свои 5 коп.
Вот текст процедуры оптимальной группировки (ящичных партий в полные паллеты)
на языке Progress 4GL.
Завидуйте, прогресисты могут решить, кто именно будет отрабатывать их логику -
основной процесс клиентского приложения, app-сервер или триггер в БД в любой
момент ЖЦ системы. Делается простой настройкой типа строчки в ini-файле.
А код будет одинаковым !!!

1. Использование идентификаторов с символом "-" и обозначение окончания строки с помощью "." снижает читабельность сего кода.
2. 2 процедуры (текущая и GetPalleteNumber) зависят от существования временной таблицы Result-3 -> высокая связанность кода
3. Сама реализация весьма неоптимальна с точки зрения дублирования кода. Рекурсия бы как раз помогла.
Думаю вы привели не самый лучший пример реализации бизнес-логики на СУБД
...
Рейтинг: 0 / 0
Ответ разработчика
    #37087548
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svcoder1. Использование идентификаторов с символом "-" и обозначение окончания строки с помощью "." снижает читабельность сего кода.

странно слышать про читабельность от 1С-ника. Хоть не с этого начитайте.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37087552
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svcoderДумаю <....> привели не самый лучший пример реализации бизнес-логики на СУБД
привели пример на 4GL, который может быть выполнен любым "уровнем", в зависимости от настройки. Вы не совсем поняли суть примера, похоже.
...
Рейтинг: 0 / 0
Ответ разработчика
    #37089065
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmsvcoderДумаю <....> привели не самый лучший пример реализации бизнес-логики на СУБД
привели пример на 4GL, который может быть выполнен любым "уровнем", в зависимости от настройки.
Вы не совсем поняли суть примера, похоже.
Совершенно верно, Искра. Я привел пример кода, который можно исполнить:
1) В триггере для таблицы документов на событие OnModify
2) В клиентском приложении при нажатии на кнопочку формы ...
3) На сервере приложений при запуске по расписанию
...
Рейтинг: 0 / 0
Ответ разработчика
    #37089067
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
strizhЯ привел пример кода, который можно исполнить:
И везде выполнится одинаково плохо :)
...
Рейтинг: 0 / 0
Ответ разработчика
    #37094741
aquino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DPH3Ну, архитектура биллинг-систем известных мне телекомов - это тихий ужас. Там все очень медленно, не слишком надежно и неимоверно дорого. Собственно, неумение сотовых операторов рассчитывать остаток на счете в процессе разговора - замечательное свидетельство плохой архитектуры.
В тех телекомах, чью архитектуру я видел (их, впрочем, не слишком много) - асинхронный сбор данных, загрузка в разные промежуточные БД и расчет средствами БД. Дорого и долго.

Ой. Это у кого из сотовых операторов такое?

DPH3Я вот решал задачи биллинга с аналогичной нагрузкой и с кучей дополнительных сложностей...
На сколько миллионов абонентов? :)
...
Рейтинг: 0 / 0
Ответ разработчика
    #37095423
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
strizhЯ привел пример кода, который можно исполнить:
1) В триггере для таблицы документов на событие OnModify
2) В клиентском приложении при нажатии на кнопочку формы ...
3) На сервере приложений при запуске по расписаниюИ толку ?
Почему то Прогресс не захватил ИТ-мир, а остался экзотикой. Не знаете почему ?
...
Рейтинг: 0 / 0
Ответ разработчика
    #37095560
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aquinoОй. Это у кого из сотовых операторов такое?

Хм. NDA. А что, тебе известны более удачные схемы в реальном телекоме?

DPH3Я вот решал задачи биллинга с аналогичной нагрузкой и с кучей дополнительных сложностей...
На сколько миллионов абонентов? :)[/quot]
По ТЗ - единицы миллионов, тестировали на десять миллионов. Сколько реально набрали на данный момент - не знаю. Но какое значение имеет число абонентов? Количество транзакций в секунду и их сложность - это еще сколь-нибудь существенный показатель (у меня был не телеком).
...
Рейтинг: 0 / 0
25 сообщений из 127, страница 5 из 6
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Ответ разработчика
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]