powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Система с изменяющимися алгоритмами расчета.
25 сообщений из 159, страница 3 из 7
Система с изменяющимися алгоритмами расчета.
    #32199551
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Папа Карло

что лизинг кластерного апплекейшен сервера стоит 375 доллраов в месяц, лизинг кластерного датабаз сервера с тем-же числом процов и памяти и единственным отличием raid10 стоит 3500 долларов в месяц...

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

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

Это кто Вам такую глупость сказал??? Cost Cutting вещь очень лукавая - в долгосрочной перспективе можно бизнес загубить.

И лично к Вам вопрос: вами была реализован проект расчета Российской з/п?

2 ASCRUS
.... по которым например сотрудники вошедшие в одну ведомость не имеют права входить в другую

В бытность работы на гос предприятии я получал з/п по нескольким ведомостям....
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199587
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нет, ну просто не могу не удержаться от комментария...
Человек довольно грамотно и инженерно описывает выбранную им технологию с учетом постановки задачи. А в ответ несется - да это все фуфло, если на сто тыщ человек запустить, долго будет, а вот 3-х звенка - магическое слово! - все летать будет!!!
Как будто от одного названия уже все ускоряется. И - интересно услышать - где это у нас есть организации в которых 100 000 чел работает? Даже на Форде, кажется, порядка 40 тыс. - но это консорциум из нескольких компаний, филиалов и пр., и уж явно зарплата там не считается сразу для всех.

2 ASCRUS
Меня интересовало несколько иное. Как я понял, в описанной вами реализации, история ведется по отдельным независимым сущностям, включающим один измен. атрибут - ставка, тариф и пр. Это относительно просто. Сложнее, когда есть набор атрибутов (полей), каждое из которых может изменяться отдельно от остальных. Пример - атрибуты сотрудника - ФИО, паспортн. данные, место жительства, должность. Каждое это поле меняется независимо от др. А получать надо связанный набор. А если учесть, что поля могут менять задним числом, то вообще кавардак. Напр., у Иванова задним числом поменяли адрес, а потом - еще более ранним - паспорт. Необходимо на заданную дату вернуть правильные значения. Общим решением явлется хранение атрибутов по записям, - однако.... Это сильно усложняет.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199590
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Varivan
Угу, есть такое дело. Имелось в виду, что необязательно например в середине месяца, после выдачи приказа о начислении и выдачи межрасчетов какой то премии все сотрудники тут же попадут в ведомость и получат деньги в кассе. Нормальная ситуация, когда по мере пополнения денег в кассе они будут ее получать, причем не обязательно целыми отделами - например в тех же гос. конторах реальна ситуация, когда впервую очередь денежки получит начальство. С другой стороны человек, уже попавший в ведомость начинает считаться как деньги получивший по данной ведомости и соотвественно при дальнейшей порционной распечатке оставшихся сотрудников войти уже в такую ведомость не может, иначе бы такую ведомость пришлось бы депонировать. С другой стороны любая попытка изменения размера премии сотрудника, уже вошедшего в ведомость приведет к запросу о подтверждении аннулирования ведомости, что приведет к тому, что вся ведомость, в которой этот сотрудник входил будет считаться не действительной, и все сотрудники, которые в нее входили окажутся в статусе не получивших деньги, и при любой попытке запуска окончательного расчета система выдаст ошибку о невыдаче денег перечисленным сотрудникам и расчетчику зп придется сделать выбор между снятием межрасчетных выплат с этих сотрудников или же распечаткой требуемой ведомости. То же самое касается и окончательного расчета, пока все что должно быть распечатано не будет распечатано и все деньги не будут полностью распределены по всем потокам оплат (касса, кредитки, сбербанк, почта и т.д.), расчетчик зп не сможет закрыть текущий расчетный месяц и перейти на следующий. Однако это ограничение не повлияет на тех бухгалтеров, которые во время уже распечатали отчетные формы - в системе поддерживается ввод данных и будующим числом, так что они спокойно даже при открытом пока предыдущем расчетном месяце смогут начинать вносить входящие данные нового расчетного месяца, пока их нерасторопный коллега будет печатать отчетные формы.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199614
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aag
Для меня все таки самое простое решение хранить аттрибуты в одной таблице. Все таки они все описывают изменение свойств одного обьекта и на любой промежуток времени однозначно будут его характеризовать. Т.е. у меня например на код дохода реально получается 2 таблицы:
1. Сам обьект дохода, в котором стоит его ID и логическое наименование
2. Таблица аттрибутов кода дохода, в которой на каждый ID кода может существовать запись, хранящая с указанного периода времени аттрибуты обьекта - налоговый код дохода, код материальной скидки и сумму материальной скидки. Фактически любой из этих параметров может измениться вне зависимости от остальных. Физически получается что изменение например суммы скидки приведет к появлению еще одной записи с дублирующими полями кода дохода и кода скидки и новым значением суммы скидки. Можно ли это считать денормализацией данных ? Честно говоря не знаю. Тут уже все зависит только от предполагаемого обьема данных. Для обьектов с нечасто изменяющимися аттрибутами это нормально. Указанный Вами пример тоже идеально подходит под такую модель - ФИО или номер паспорта меняются настолько редко и у малого кол-ва граждан. Если бы была постановка с частыми изменениями некоторого числа аттрибутов, то скорее всего для таких аттрибутов пришлось бы делать свои таблицы, где в каждом конкретном случае решать как их хранить - по записям или же по таблице на конкретный аттрибут.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199622
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ASCRUS

если честно, то почти ничего не понял :)) но к этому и не стремился :) Главное, что Вас не смутило найденное дилетантом в расчете з/п противоречие :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199673
vic123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А мне нравится. Попытаюсь приложить данную идею немного в другом разрезе. Есть ПО обеспечивающее несколько организаций, в каждой из которых свои особенности. Попытка сделать программу универсальной и разбежаться за счет параметризации на этапе инициализации сегодня привела к диким затруднениям на этапе сопровождения. Здесь вопрос решается на уровне запуска своего алгоритма, реализующего особенности данной организации в ПО, имеющем 90% общего программного кода.
С точки зрения сопровождения это хорошо тем, что в общую часть ПО изменения вносятся крайне редко, а отладка каждого отдельного алгоритма позволяет работать с одной организацией.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199699
Gt_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gt_
Гость
Еще дополнение - зп не большая, а сложная система. У любой системы должны быть границы. Чисто теоретически я мог бы изначально проектировать зп для расчета заработной платы всех жителей Китая, но такой задачи слава тебе господи и не ставилось

чо то не совсем понял почему все привязалась именно к з/п предприятия ? или система не предназначена только для РФ и только для ЗАО такое-то ?? а зарплата в финансовых пирамидах, там 40 тыс участников - детство ...
ИМХО примерно то же самое я наблюдал у кабельной сети, у них там так-же куча услуг, туча клиентов которые оплачивают часть , по ценам зависещим от погоды на этой неделе со скидками от балды. может логика менее сложная но суть таже.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199720
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Расчет заработной платы - вполне конкретная часть трудового кодекса РФ, регулирующего трудовые отношения между работодателями и работниками, и описывающего порядок расчетов за выполненные обьемы работ, удержания действующих налогов и соц. норм. Насколько я понимаю клиенты кабельного телевидения или же финансовые пирамиды регулируются другим законодательством, описывающим отношения на договорной основе как юридического и физического лица, со всеми вытекающими отсюда условиями. Нельзя же в самом деле тех же клиентов банка причислить к числу его сотрудников только за то, что они хранят в нем свои вклады и получают с этого проценты. Это другая постановка, соотвествующе и другая задача. При всем желании универсально сделать бы и не получилось. Наглядный пример попыток универсальной постановки можно легко наблюдать в комплексных бух. системах, в которых расчет зп всегда являлся самым слабым местом и мягко говоря расчитан на "идеальное" предприятие без отклонений от схемы "все положенное время отработал, деньги получил", только по той причине, что реализован в них расчет зп на основе движков, расчитаннных на бухгалтерию. Это конечно круто начисления и удержания хранить и обрабатывать дебетом и кредитом, но ни к чему хорошему это не приводит. Мое мнение - программа должна быть гибкой в реализации и сопровождении, но с четко описанной постановкой и областью применения.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199895
Gt_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gt_
Гость
а я то не в РФ, что из-за этого я не могу применять твои методы для решения задач вне РФ ? ну законодательство чуть другое, ну не сотрудников а клиентов общитываю ... не вижу принципиальной разницы.

ну да ладно, дальше вижу только религиозный спор ...
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199909
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так а кто мешает написать свою задачу, пользуясь приведенными мною решениями, если они конечно понадобятся в контексте поставленной задачи ? Насчет же распостранения проекта зп вне России я честно говоря не уверен, что может получится. Одно дело, когда просто расчеты изменяются, другое дело, когда структура входящей, расчетной и исходящей информации будет своей для каждой страны.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32199922
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот! Свет истины. :-)
Именно такую стуктуру я и пытался обрисовать. Но, недостатки данного подхода также очевидны.
Напр., сделать селект по таблице кода доходов - со всеми атрибутами. Это выливается в необходимость конструирования такой таблицы - через врем. таблицы, update полей и пр. Если нет возможности дать гранты на паблик на все треб. таблицы (а как правило ее нет) - динамический SQL невозможен.
Итого - куча кода, медленные запросы.

Поскольку в недалеком будущем это предстоит и мне, вот я и жалуюсь :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200013
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Именно такую стуктуру я и пытался обрисовать. Но, недостатки данного подхода также очевидны.
Напр., сделать селект по таблице кода доходов - со всеми атрибутами. Это выливается в необходимость конструирования такой таблицы - через врем. таблицы, update полей и пр. Если нет возможности дать гранты на паблик на все треб. таблицы (а как правило ее нет) - динамический SQL невозможен.
Итого - куча кода, медленные запросы.


Наверное мы все таки друг друга не поняли. Приведу пример использования справочника кодов доходов:
Код: 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.
145.
146.
147.
148.
 -- Доходы
 
create table Income (
  Income_id int not null identity primary key,  -- id дохода
 
  Name varchar( 50 ) not null  -- наименование дохода
 
)

 -- Значения доходов
 
create table IncomeValue (
  CalcDate date not null,  -- дата начала действия
 
  Income_id int not null,   -- id дохода
 
  Income_Num int not null,  -- код дохода
 
  Dicount_Num int null,  -- код налоговой скидки
 
  Discount_Value numeric( 15 ,  2 ) null,  -- сумма налоговой скидки
 
  primary key pk_IncomeValue (CalcDate, Income_id)
)

 -- Напишем вьювер (UDF), показывающий состояние кодов дохода 
 
 -- на указанный период
 
create view pv_IncomeValue
 /*
  Используется глобальная переменная $CalcDate для указания расч. месяца
*/ 
as
  select 
    iv.CalcDate, iv.Income_id, iv.Income_Num, iv.Discount_Num, iv.Discount_Value
  from IncomeValue iv
    inner join (
      select Income_id, Max(CalcDate) as MaxCalcDate
      from IncomeValue
      where CalcDate <= $CalcDate
      group by Income_id
    ) as m on m.Income_id = iv.Income_id and m.MaxCalcDate = iv.CalcDate

 -- Занесем код дохода
 
insert into Income (Name)
values ('Суммы материальной помощи')

 -- Занесем аттрибуты кода дохода на 2003/01/01
 
insert into IncomeValue 
  (CalcDate, Income_id, Income_Num, Discount_Num, Discount_Value)
values
  ('2003/01/01',  1 ,  2760 ,  503 ,  2000 )

 -- В феврале изменился код дохода 2760 на 3000
 
set $CalcDate = '2002/02/01'

insert into IncomeValue 
  (CalcDate, Income_id, Income_Num, Discount_Num, Discount_Value)
select $CalcDate, Income_id,  3000 , Discount_Num, Discount_Value
from pv_IncomeValue
where Income_id =  1 

 -- В марте изменился код налоговой скидки 503 на 600 и 
 
 -- ее сумма с 3000 на 5000
 
insert into IncomeValue 
  (CalcDate, Income_id, Income_Num, Discount_Num, Discount_Value)
select $CalcDate, Income_id, Income_Num,  600 ,  5000 
from pv_IncomeValue
where Income_id =  1 

 -- Можно сделать ХП, реализующую изменения любого аттрибута
 
create procedure sp_IncomeValue_Set (
  in @CalcDate date,
  in @Income_id int,
  inout @Income_Num int default null,
  inout @Discount_Num int default null,
  inout @Discount_Value numeric( 15 ,  2 ) default null
)
begin
  declare @RealDate date;

   -- Получаем значения предыдущего текущего состояния кода дохода
 
  set $CalcDate = @CalcDate;

  select
    CalcDate,
    case when @Income_Num is null then Income_Num 
      else @Income_Num end,
    case when @Discount_Num is null then Discount_Num 
      else @Discount_Num end,
    case when @Discount_Value is null then Discount_Value 
      else @Discount_Value end
  into @RealDate, @Income_Num, @Discount_Num, @Discount_Value
  from pv_IncomeValue
  where Income_id = @Income_id;

   -- Если полученная дата не установлена или меньше указанной, 
 
   -- значит записи на указанный месяц нет и ее просто нужно добавить
 
  if @RealDate is null or @RealDate < @CalcDate then
    insert into IncomeValue 
      (CalcDate, Income_id, Income_Num, Discount_Num, Discount_Value)
    values
      (@CalcDate, @Income_id, @Income_Num, @Discount_Num, @Discount_Value)
  else
   -- Иначе обновляем запись
 
    update IncomeValue
    set 
      Income_Num = @Income_Num,
      Discount_Num = @Discount_Num,
      Discount_Value = @Discount_Value
    where Incomt_id = @Income_id;
  end if;
end

 -- Посредством ХП добавляем новые аттрибуты скидок кода дохода
 
 -- на апрель
 
call sp_IncomeValue_Set ('2003/04/01',  1 , null,  700 ,  6000 )

 -- Также изменяем код дохода в апреле
 
call sp_IncomeValue_Set ('2003/04/01',  1 ,  3500 , null, null)

 -- Смотрим состояние аттрибутов кода дохода на январь
 
set $CalcDate = '2003/01/01'
select *
from pv_IncomeValue
where Income_id =  1 

 -- Смотрим состояние аттрибутов кода дохода за апрель
 
set $CalcDate = '2003/04/01'
select *
from pv_IncomeValue
where Income_id =  1 


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

Как видно ни о каком динамическом SQL, конструировании таблиц, и т.д. тут речи и не идет. Основными недостатоками моей модели являются избыточное хранение аттрибутов и некоторая сложность в их обработке. Однако все равно это не идет ни в какое сравнение с хранением аттрибутов по записям, где действительно все будет выглядеть, как стоп-кран в СУБД.

Предложенная мной модель не позволяет хранить обьекты с изменяющимся и неизвестным кол-вом аттрибутов, однако мое личное мнение, что если такое требование существует, то это скорее всего указывает на неправильно спроектированную архитектуру БД. Реально при описании базы данных можно редко встретить необходимость хранения обьектов с неизвестным кол-вом аттрибутов и прикручивать это на СУБД печально, так как под это релляционные СУБД не предназначенны. В основном я встречал с попытками сделать такое людей, у которых была "светлая мечта" сделать универсальный проект, не зависящий от постановки.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200017
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хех - вроде все проверил, но все равно ошибки в скрипте допустил.
После
Код: plaintext
1.
2.
 -- В марте изменился код налоговой скидки 503 на 600 и 
 
-- ее сумма с  3000  на  5000 

необходимо поставить
Код: plaintext
set $CalcDate = '2003/03/01'

Вместо
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 -- Иначе обновляем запись
 
    update IncomeValue
    set 
      Income_Num = @Income_Num,
      Discount_Num = @Discount_Num,
      Discount_Value = @Discount_Value
    where Incomt_id = @Income_id;

Конечно же
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
 -- Иначе обновляем запись
 
    update IncomeValue
    set 
      Income_Num = @Income_Num,
      Discount_Num = @Discount_Num,
      Discount_Value = @Discount_Value
    where 
      Income_id = @Income_id and
      CalcDate = @CalcDate;

Вроде больше ошибок нигде, кроме очепяток :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200045
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Varivan

что лизинг кластерного апплекейшен сервера стоит 375 доллраов в месяц, лизинг кластерного датабаз сервера с тем-же числом процов и памяти и единственным отличием raid10 стоит 3500 долларов в месяц...

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

В Российском банке мы тоже техники на поллимона покупали в год. :) На Западе не везде тратят деньги как в России. :)

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

Это кто Вам такую глупость сказал??? Cost Cutting вещь очень лукавая - в долгосрочной перспективе можно бизнес загубить.

Загубить можно что угодно. :) Давайте лучше посчитаем. :)

Пусть издержки на производство продукта А составляют 1000 рублей в месяц. Мы прибыльная компания и продаем на 1500 рублей в месяц. Итого мы имеем 50% прибыли от вложенных денег. Теперь представим что мы продали на одну копию больше и теперь у нас не 1500 рублей, а 1700 рублей. Итого мы получили 70% процентов от вложения наших средств. Теперь предположим что мы уменьшили издержки на ту же сумму. Т.е. теперь мы тратим 800 рублей на производство и получаем все те-же 1500. Мы получили 87% прибыли. Что в принципе далеко не плохо. :) я, разумеется, могу ошибаться. :) ко всему надо подходить с головой. при верхних расчетах подразумевается что уменьшение издержек произошло за счет изменения дизайна системы на начальном уровне. вроде вот так. теперь с примерами если можно "почему это глупость". прошу прояснить ситуация не для того чтобы спорить, просто хочу знать больше подходов и получить больше опыта.

И лично к Вам вопрос: вами была реализован проект расчета Российской з/п?

нет. в России я работал в банке но занимался другими вещами... хотя те же грабли с постоянно изменяющимяся положениями ЦБ. Переводил банк на новый план счетов и деноменированные рубли. Именно поэтому я не говорю что хорошо и что плохо в той конкретной реализации что сделана ASCRUS. Он сам кузнец мне все равно. Просто в этом треде спорят о том что лучше трезвенка или двузвенка. Ответ мой будет такой: когда как. Как я уже писАл все зависит от конкретной задачи. :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200047
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aag

Нет, ну просто не могу не удержаться от комментария...
Человек довольно грамотно и инженерно описывает выбранную им технологию с учетом постановки задачи. А в ответ несется - да это все фуфло, если на сто тыщ человек запустить, долго будет, а вот 3-х звенка - магическое слово! - все летать будет!!!
Как будто от одного названия уже все ускоряется. И - интересно услышать - где это у нас есть организации в которых 100 000 чел работает? Даже на Форде, кажется, порядка 40 тыс. - но это консорциум из нескольких компаний, филиалов и пр., и уж явно зарплата там не считается сразу для всех.

не надо быть таким радикальным. :) да каждый использует то, что он уже знает. знает только трезвенку будет только трезвенка. :) У меня был плохой опыт с двузвенной технологией когда был куплен софт в бан за 1млн. баксов и он не смог потянуть 150 (сто пятьдесят) операционистов. вот это был сакс. :( трезвенки пока всегда работали. следует ли из этого что трезвека лучше двузвенки? НЕТ! :) Это как в анекдоте:

- Вы любите кошек?
- Нет!
- А! Вы их просто готовить не умеете. :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200086
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Реально при описании базы данных можно редко встретить необходимость хранения обьектов с неизвестным кол-вом аттрибутов и прикручивать это на СУБД печально, так как под это релляционные СУБД не предназначенны. В основном я встречал с попытками сделать такое людей, у которых была "светлая мечта" сделать универсальный проект, не зависящий от постановки.

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

это было так к слову. :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200121
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 папа Карло

При наличии одного компьютера на сервере приложений очевидного (!) выиграша в производительности трехзвенки нет. Это по-моему, если есть - поправьте. Более того, при отсутствии правильного кеширования данных на сервере приложений будет явный проигрыш (но при наличии может быть выигрыш). Преимущества трехзвенной архитектуры в скорости (масштабируемости) неоспоримо проявляются ИМХО только при наличии параллельно работающих серверов приложений. При этом опять же, необходимо правильно спланировать кеши данных, иначе один медленный сервер БД съест весь выигрыш. Но планировать кеш на параллельных серверах, это та еще задача, покруче даже расчета зарплаты, особенно при лоад балансе. Этот кэш ведь нужно постоянно реплицировать между серверами. И потом масштаб задачи явно не тот, чтоб ставить параллельные сервера приложений. В общем большая куча дополнительных проблем, которых уважаемый докладчик счастливо избежал. Так что по-моему по архитектуре все сделано правильно.

Насчет гугла, работающего на четверках. Этот аргумент я слышал много раз. Но это же вообще другой класс задач: чистый ОЛТП, медленно меняющаяся база данных, которую можно реплицировать раз в неделю, поток данных в одну сторону - только селекты, об актуальности данных речи нет вообще, более того, никаких пользовательских сессий, прав доступа, транзакций, целостности данных и т.д. Машины гугла просто работают параллельно ничего не зная друг о друге. Вот потому и четверок достаточно, нужно только, чтоб их было достаточно много.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200685
Gt_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gt_
Гость
При наличии одного компьютера на сервере приложений очевидного (!) выиграша в производительности трехзвенки нет.

итак у меня выделеный AS, в нем в виде объекта в памяти наш кеш. думаю этот кеш весь влезет в гиг памяти, если нет покупаем еще, благо цена памяти в районе цены мешка картошки. в крайнем случае сваливается в своп который имхо для подобной задачи более эфективен субд. dom-xml например забавно кеширует свои объекты. А в субд это у нас плоские таблицы которые нада считать с диска и преоброзовать чтобы провести вычисления.

p.s. а про гугл вы не в ту степь, во первых это не рсубд, во вторых думаю там объем такой что о репликации речь не может идти ...
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32200883
xtony
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>> При наличии одного компьютера на сервере приложений очевидного (!)
>> выиграша в производительности трехзвенки нет.

Возьмем более сложный вариант. Два компьютера.
Имеются расчеты, которые выполнить за короткое время почему-то не удается.
Пусть даже кривые руки программиста в этом виноваты. Но такие расчеты имеются.
Что мы при этом имеем на клиент-сервере: один пользователь запускает такой расчет и идет пить кофе, а второй может спокойно составить ему компанию, потому-что радости от тормозов на сервере он явно не получит.
Что мы имеем с 3-х звенкой: один пользователь выгребает на свою тачку (где у него установлен средний слой) нужные ему данные запускает расчет и идет пить кофе, а второй продолжает работать как ни в чем ни бывало.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201161
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 папа Карло
каждый использует то, что он уже знает. знает только трезвенку будет только трезвенка
Именно поэтому, руководитель проекта должен четко представлять где, что использовать и подбирать людей с соответствующими знаниями. Хотя, по-моему, если человек знает 3-х звенку - но при этом не знает обычного клиент-сервера, это не есть хорошо.
Что касается вашего опыта - видимо, был закуплен такой удачный софт. Могу привести обратный пример - MSSQL 6.5 тянул порядка 400-500 клиентов, до 20 активных.
2 xtony
Кривые руки программиста что угодно загубят. На практике, в правильно спроектированных клиент-серверных системах, такого влияния одного расчета на всех нет.

Я не против 3-х звенки! Но данная тема переросла в споры о ней, хотя посвящена была системам с гибким алгоритмом.

2 ASCRUS
Да, в вашем случае, наверно достаточно обойтись такой реализации истории. Однако необходимость же хранения сущностей с произвольным кол-вом атрибутов весьма актуальна - если не рассматривать такую сущность как основу базу, а напр., как вспомогательный информ.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201338
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Папа Карло

Загубить можно что угодно. :) Давайте лучше посчитаем. :)

Давайте, считаем:

Пусть издержки на производство продукта А составляют 1000 рублей в месяц.

Затраты постоянные или переменные?

Мы прибыльная компания и продаем на 1500 рублей в месяц. Итого мы имеем 50% прибыли от вложенных денег. Теперь представим что мы продали на одну копию больше и теперь у нас не 1500 рублей, а 1700 рублей.Итого мы получили 70% процентов от вложения наших средств.

А это зависит от вида затрат.

Теперь предположим что мы уменьшили издержки на ту же сумму.

За счет чего?

Т.е. теперь мы тратим 800 рублей на производство и получаем все те-же 1500.

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

Мы получили 87% прибыли. Что в принципе далеко не плохо. :)

Опять же зависит от вида издержек.

я, разумеется, могу ошибаться. :)

Ваш расчет верен только математически (при вычислении процентов). К реальной жизни он имеет очень слабое отношение.

теперь с примерами если можно "почему это глупость". прошу прояснить ситуация не для того чтобы спорить, просто хочу знать больше подходов и получить больше опыта.

см. выше. Если интересно развить тему с целью получения опыта - предлагаю вынести в отдельный топик.

нет. Именно поэтому я не говорю что хорошо и что плохо в той конкретной реализации что сделана ASCRUS. Он сам кузнец мне все равно....

Вопрос снят :) Значит мне показалось, что Вы слишком уж рьяно критиковали решение ASCRUS :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201388
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Varivan:

Ну как всегда! :) читаем только то, что хотим прочитать.

написал же: "при верхних расчетах подразумевается что уменьшение издержек произошло за счет изменения дизайна системы на начальном уровне"

Вы меня спрашиваете про качество итд. Ответ такой: При моделировании ситуации мы отбрасываем все не нужное, то что в рассмотрении ситуации роли не играет. Надеюсь с этим никто спорить не будет? ;) Так вот когда я "смоделировал" ту ситуацию то посчитал (принял за условие) что все остальное что не оговорено в условиях остается в том-же состоянии (это у меня по дефолту). Т.е. качество не страдает. разумеется. :) Почему качество не страдает? Ответ очевиден: у любого нормального продукта есть требования. Когда продукт отвечает тем требованиям то он качественен. Пример: по требованиям система должна иметь максимальное время запроса-ответа до 10ти секунд. Система при проектировании человеком А показывает величину 1 секунда за запрос-ответ и операционная стоимость состовляет 1000 рублей в месяц. Система при проектировании человеком Б показывает величину 1.5 секунды за запрос-ответ и операционная стоимость состовляет 800 рублей в месяц. Как Вы понимаете быджет на разработку фиксированный и равен в случае А и Б. У меня вопрос к Вам: по какому пути Вы пойдете?

Ваш расчет верен только математически (при вычислении процентов). К реальной жизни он имеет очень слабое отношение.

Так-же... примеры расчетов Вы мне так и не привели. Хотябы даже очевидных для меня. :( Где пример из жизни: типа мы снизили - получилось вот так?
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201390
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Папа карло

"при верхних расчетах подразумевается что уменьшение издержек произошло за счет изменения дизайна системы на начальном уровне"

Мы вроде говорили про производства абстрактного продукта "А"? ПРичем тут дизайн системы?

Так вот когда я "смоделировал" ту ситуацию то посчитал (принял за условие) что все остальное что не оговорено в условиях остается в том-же состоянии (это у меня по дефолту). Т.е. качество не страдает. разумеется. :)

Вы поставили очень серьезное ограничение для своей модели. Издержки всегда снижаются за счет чего-то. Другое дело, что мы можем осознанно пожертвовать чем-то для снижения издержек, но каждый конкретный случай надо рассматривать отдельно. Правила тут, к сожелнию не выведешь.

Так-же... примеры расчетов Вы мне так и не привели.

посмотрите на наши (Российские) продуктовые бренды (хотя, ИМХО, сейчас ситуация меняется....). Есть период вывода бренда на рынок, когда соотношение цена/качество очень привлекательное. Когда бренд раскручивается и пользуется популярностью, резко снижают издержки (и как следствие качество) и бренд "выдаивается". Через какое-то время бренд с рынка уходит, собрав сливки и выпускается новый.

Но эта процедура вполне осознанная и просчитанная программа. А если мы снизим издержки не вовремя?
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201404
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Varivan:

Удивительная способность игнорировать вопросы..... :(

так по какому пути Вы пойдете?

Для того, чтобы говорить что внутри бренда уменьшались издержки надо было там быть. Я там не был, поэтому говорить так не могу. У вас есть конкретные примеры из Вашей практики? Если есть то хотелось бы услышать "без имен" как это было, если нет, то так и скажите что то что вы говорить основано на теории и практики нет. Ну дык? Да, дабы не быть голословным можно обозначить Ваше положение в компании чтобы понять угол зрения с которого сделанны выводы.

Спасибо!
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201405
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да..... я могу снижать издержки на столько на сколько смогу в рамках бюджета и требований проекта. Т.е. я не могу перерасходовать бюджет. И могу "ухудшать" продукт в рамках требований (пример что я привел).
...
Рейтинг: 0 / 0
25 сообщений из 159, страница 3 из 7
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Система с изменяющимися алгоритмами расчета.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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