![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
1С на Delphi
Serginio © (2002-10-11 12:29:00)1С на Delphi.
Уважаемые Мастера хочу предостваить вам на обсуждение такую вещь.
Обсуждение этой темы 1С программистов на http://www.kuban.ru/cgi-bin/forum/forum9.cgiза 10,10
Очень хотелосьбы узнать насколько это нужно. И еще, что такой подход применим не только к 1С но и с любой базой дающей прямой доступ к файлу.
Почти 6 лет занимаюсь 1С FoxPro версии и столько же занимаюсь ее ускорением с помощью BDE, и столько же пытался строить объекты на таблицах. Идея 1С очень понравилась, но очень хотелось настоящих объектов, а не диспачных. Плоское программирование реляционных баз утомительно, а описание вручную всех объектов базы проблематично. Но с помощью Rainbow все проблемы решаемы.
С ее помощью можно выдрать Id объектов базы, а с помощью метаданных их описание и тип.
Автоматическое Описание объектов выглядит примерно так:
//--------------------------------------------------
TKomplektaciyarec=record
deleted:char;
SpId: TIDField;//ID
Code: array[0..4] of char;//CODE
Descr: array[0..24] of char;//DESCR
Owner: TIDField;//PARENTEXT
IsMark: char;//ISMARK
VERSTAMP: array[0..5] of char;
Tovar: TIDField;//SP683
Kolichestvo: array[0..10] of char;//SP684
end;
//---------------------------------------------------
TSpKomplektaciya=Class(TSptCastomObj) //Комплектация
SpRecord:TKomplektaciyarec;
Private
FOwner:TSpNomenklatura;
FTovar:TSpNomenklatura;
Protected
Function getSpId:String;
Function getOwner:TSpNomenklatura;
Function getCode:Integer;
Function getKolichestvo:Integer;
Function getDescr:String;
Function getIsMark:Boolean;
Function getTovar:TSpNomenklatura;
Public
Constructor Create;
Property SpId:String read getSpId;
Property Owner:TSpNomenklatura read getOwner;
Property Code:Integer read getCode;
Property Kolichestvo:Integer read getKolichestvo;
Property Descr:String read getDescr;
Property IsMark:Boolean read getIsMark;
Property Tovar:TSpNomenklatura read getTovar;
end;//TSpKomplektaciya
а доступ к полям:
function TSpKomplektaciya.getTovar:TSpNomenklatura;
begin
If Not Assigned(FTovar) Then FTovar:=TSpNomenklatura.Create;
FTovar.PID:=@SpRecord.Tovar;
result:=FTovar;
end;
и на более низком:
procedure TSptCastomObj.SetId(newId: PIdField);
begin
If not (Selected and (FPID^=NewID^)) Then
Selected:=DbiGetRecordForKey(SpCursor,True,0,0,NewID,ActiveBuffer)=0
// ActiveBuffer:=@SpRecord определяется в конструкторе
end;
Получается Объекно ориентированная база данных очень сходная по синтаксису с внутренним языком 1С, но реализованная на могучем компиляторе со всеми возможностями.
Скорость в 30 раз превышает самые несложные запросы 1С при некэшируемых файлах и при кэшировании еще на порядок, да и программирование становится более легким и Взрослым а не детским лепетом на встроенном языке 1С.
А если использовать DCom или Socket (серверное приложение) то приходим к Клиент серверной системе, что более предпочтительнее в многопользовательской среде и уменьшения трафика. При создании выходных данных (отчетов) они строятся в памяти с использованием очень быстрого индекса типа Б дерева поэтому лимитирующим процессом является доступ к диску.
Alexandr (2002-10-11 13:23:00) [21]как это через BDE напрямую без Tfield?
Serginio (2002-10-11 13:16:00) [22]Alexandr прочитай пожалуйста получше.
На Sql это приблизительно выглядит так
Select TovId,Date,Sum(Kolichestvo) From Rg99
Group by TovId,Date
Кроме того нужно получить остатки и получить продажи
Select TovId,Date,Sum(ProdKolichestvo) From Rg99
Where PriznakProd=1
Group by TovId,Date
обрабатывающий порядка 500 000 записей и на выходе содержащий порядка 300 000 записей
Еслиже через BDE напрямую без TField работать с записью,
то FoxPro оказывается очень быстрым.
Alexandr (2002-10-11 13:04:00) [23]ты про что?
Ты что, сам с собой разговариваешь?
А нормальные программисты и огранизации на 1С, тем более FoxPro версии НЕ РАБОТАЮТ.
Постольку это тормоз.
А про клиент-серверные базы данных ты слышал? Ну так вот реальные программисты только их и используют.
И никаких 100МБ на клиента тащить не нужно.
И обрабатывать там уже ничего не нужно.
Serginio (2002-10-11 12:46:00) [24]Для примера Отчет движения товаров и продаж по дням с условием (для оптимизации торговли) обрабатывающий порядка 500 000 записей и на выходе содержащий порядка 300 000 записей на Athlon 900 формируется за 6-12 сек.
А после полной обработке 10 000 записей которые и отправляются клиенту Скорость очень высокая.
В SQL без ХП нужно тащить более 100 МБ на клиента. А затем еще и обрабатывать. Интересно за какое время такого типа запрос пройдет на SQL
Нуралиев (2002-10-11 12:43:00) [25]Не лезь в мои базы!
Слышишь? Не влезай, убьет!
P.S. Извини, отвечаю так, как принято
в большинстве случаев отвечать на том
форуме, что ты указал...
Alexandr (2002-10-11 12:37:00) [26]ну ничего не понятно.
Но могу предложить вопрос.
А на больших объемах данных проверяли быстродействие?
Ведь запросы в базу будут очень сложными и далеко не оптимальными а отсюда тормоза пойдут нешуточные на больших объемах. Вот эта проблема выходит на первое место по построении ОО-надстроек над реляционными базами данных.