Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Вычисляемое поле

Fynjy1984 © (2006-02-06 10:45:00)
Есть вычисляемое поле, которое вычисляется по формуле: если
запись первая А=0, иначе А=B+C (для простоты) , где C тоже вычисляемое поле (но из предыдущей записи), где в вычислениях используется A. Т. е первая запись получается нормальной: A=0, C=f(A=0)=x1, а во 2-й записи должно быть A=B+x1.

Я получал С из другого набора, когда поле не было вычисляемым, т.е. переходил на предыдущую запись в другом DataSet, а теперь походу влип.

Fynjy1984 (2006-02-06 12:36:00) [1]

> Просто я такую функуцию реализовал.
> Это м.б. и A := Sin(A) и тд.Суть(я так понял) сводится к
> тому, что данные для расчета бертся из предыдуще итерации.
> Хотя, может ты и прав и человек так себе нумерует записи.
> Кто его знает ?

Ну функция не синус, а данные для расчета берутся действительно из предыдущей итерации.

> Что-то сильно много понакручено, ИМХО.
> Может стОит завести отдельный Датасет типа CDS и один раз
> заполнить его ручками в цикле.

Согласен, наверное так и сделаю.

Sergey13 (2006-02-06 11:56:00) [2]
2[8] msguns © (06.02.06 11:50)
Я тоже не понимаю, зачем юзерам некоторые навороты. Самое печальное в этом, что деньги платят нам те самые юзера. 8-)

msguns (2006-02-06 11:50:00) [3]
>Sergey13 © (06.02.06 11:40) [7]
>А как подсчитать, например, итог по нарастающей? Подход нормальный, ИМХО. Просто пользоваться им надо осторожно и к месту.

Вот никогда не понимал и не понимаю, зачем в динамически меняющихсяданных при отображении надо обязательно в каждой записи показывать сумму (например) этой записи (или какого-то ее поля) с другими.
Итог - это ясно. А зачем нарастающий? Ну, иногда бывает, согласен (например, при анализе динамики продаж внутри групп товаров или торговых точек), но это нужно делать в отчете, но зачем В ГРИДЕ ?

Sergey13 (2006-02-06 11:40:00) [4]
2[6] msguns © (06.02.06 11:31)
>порочность самого подхода
А как подсчитать, например, итог по нарастающей? Подход нормальный, ИМХО. Просто пользоваться им надо осторожно и к месту.

msguns (2006-02-06 11:31:00) [5]
>Виталий Панасенко (06.02.06 11:22) [5]

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

Виталий Панасенко (2006-02-06 11:22:00) [6]

> msguns © (06.02.06 11:06) [4]
> >Виталий Панасенко (06.02.06 10:57) [3]
>
> 1. Для определения порядкового номера записи в отображаемом
> НД, можно вполне обойтись без этих изгаляций, "положившись"
> на RecNo.
> 2. Ты уверен, что ему нужен № порядковый ?

Не уверен, но
> Fynjy1984 © (06.02.06 10:45)
> Есть вычисляемое поле, которое вычисляется по формуле: если
> запись первая А=0, иначе А=B+C (для простоты), где C тоже
> вычисляемое поле (но из предыдущей записи), где в вычислениях
> используется A. Т. е первая запись получается нормальной:
> A=0, C=f(A=0)=x1, а во 2-й записи должно быть A=B+x1.

Просто я такую функуцию реализовал.
Это м.б. и A := Sin(A) и тд.Суть(я так понял) сводится к тому, что данные для расчета бертся из предыдуще итерации. Хотя, может ты и прав и человек так себе нумерует записи. Кто его знает ?

msguns (2006-02-06 11:06:00) [7]
>Виталий Панасенко (06.02.06 10:57) [3]

1. Для определения порядкового номера записи в отображаемом НД, можно вполне обойтись без этих изгаляций, "положившись" на RecNo.
2. Ты уверен, что ему нужен № порядковый ?

Виталий Панасенко (2006-02-06 10:57:00) [8]
Только интересно, что делать после вставки/упорядочивания ?

unit Unit1;

interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Db, Grids, DBGrids, DBTables, StdCtrls;

type
TForm1 = class(TForm)
DataSource1: TDataSource;
Table1: TTable;
DBGrid1: TDBGrid;
Table1NAME: TStringField;
Table1SIZE: TSmallintField;
Table1WEIGHT: TSmallintField;
Table1AREA: TStringField;
Table1BMP: TBlobField;
Table1F: TFloatField;
Button1: TButton;
procedure Table1BeforeOpen(DataSet: TDataSet);
procedure Table1CalcFields(DataSet: TDataSet);
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
A : Variant;
public
{ Public declarations }
end;

var
Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.Table1BeforeOpen(DataSet: TDataSet);
begin
A := null;
end;

procedure TForm1.Table1CalcFields(DataSet: TDataSet);
begin
if A=null then
A := 0
else
A := A + 1;
DataSet.FieldByName('F').AsFloat := A;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
Table1.Open;
end;

end.

msguns (2006-02-06 10:54:00) [9]
Если алгоритм вычислений построен на порядке следования записей в таблице(не НД !), то в такую таблицу надо добавить поле, задающее явно порядковый номер записив таблице. Алгоритм же должен "плясать" от значения этого поля. При этом записи должны следовать строго в порядке возрастания. Правда непонятно, причем здесь "другой набор" ?

Хотя все это довольно странно. Подобный алгоритм расчета, ИМХО, явно порочен, т.к. совершенно непонятно, ЧТО делать при добавлениях или удалениях записей (пересчитывать калк-поля ?).

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

Sergey13 (2006-02-06 10:51:00) [10]
Что-то сильно много понакручено, ИМХО.
Может стОит завести отдельный Датасет типа CDS и один раз заполнить его ручками в цикле.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »