1С на Delphi

← →
Serginio (2002-10-11 12:29) [0]

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 12:37) [1]

ну ничего не понятно.
Но могу предложить вопрос.
А на больших объемах данных проверяли быстродействие?
Ведь запросы в базу будут очень сложными и далеко не оптимальными а отсюда тормоза пойдут нешуточные на больших объемах. Вот эта проблема выходит на первое место по построении ОО-надстроек над реляционными базами данных.

← →
Нуралиев (2002-10-11 12:43) [2]

Не лезь в мои базы!
Слышишь? Не влезай, убьет!

P.S. Извини, отвечаю так, как принято
в большинстве случаев отвечать на том
форуме, что ты указал...

← →
Serginio (2002-10-11 12:46) [3]

Для примера Отчет движения товаров и продаж по дням с условием (для оптимизации торговли) обрабатывающий порядка 500 000 записей и на выходе содержащий порядка 300 000 записей на Athlon 900 формируется за 6-12 сек.
А после полной обработке 10 000 записей которые и отправляются клиенту Скорость очень высокая.
В SQL без ХП нужно тащить более 100 МБ на клиента. А затем еще и обрабатывать. Интересно за какое время такого типа запрос пройдет на SQL

← →
Alexandr © (2002-10-11 13:04) [4]

ты про что?
Ты что, сам с собой разговариваешь?
А нормальные программисты и огранизации на 1С, тем более FoxPro версии НЕ РАБОТАЮТ.
Постольку это тормоз.
А про клиент-серверные базы данных ты слышал? Ну так вот реальные программисты только их и используют.
И никаких 100МБ на клиента тащить не нужно.
И обрабатывать там уже ничего не нужно.

← →
Serginio (2002-10-11 13:16) [5]

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:23) [6]

как это через BDE напрямую без Tfield?

← →
Serginio (2002-10-11 13:31) [7]

Selected:=DbiGetRecordForKey(SpCursor,True,0,0,NewID,ActiveBuffer)=0
Через курсоры BDE

← →
Johnmen © (2002-10-11 13:33) [8]

>Alexandr ©

Ты зачем вклиниваешься в монолог чела ? Дай ему выговориться !

← →
Mick (2002-10-11 13:33) [9]

Знаешь, Sergino, идея-то у тебя бредовая, извини. Прежде всего, вопросик: ты реально написал хоть одну внешнюю компоненту?

← →
Alexandr © (2002-10-11 13:37) [10]

просто 1С в качестве ОСНОВНОЙ программы на предприятии у меня вызывает улыбку и мысли об скором банкротстве этого предприятия.

← →
Serginio (2002-10-11 13:40) [11]

Все это работает у меня на фирме и люди очень довольны.
Любой отчет компоненты Торговля и склад сделать без проблем. При применении клиент серверного приложения немного нужно попотеть над передачей данных неоднородных данных.

← →
Jeer © (2002-10-11 13:43) [12]

Не хочу касаться 1С, т.к. меня она мало волнует, но технология объектного доступа из Дельфи к реляционным базам имеет право на жизнь и живет.
Достаточно долго для работы с DBISAM мной используется, в том числе, и такой путь.
Описание классов генериться из CASE, где моделирование таблиц ведется исходя из их иерархического(объектного) описания.
Примерно так:
// Base Tables
TIdTable = class;
TZeroTable = class;
TChildTable = class;
TChildNameTable = class;
TNameTable = class;
TTreeTable = class;
TTreeChildTable = class;
//********
TIdTable=class(TObject)
private
tmpSQL: TStringList;
protected
fID: integer;
//
fLocateFieldName: string;
fDBName: string;
fTbName: string;
fQuery: TDBISAMQuery;
procedure SetDBName(dbN: string);

public
constructor Create( AOwner: TObject ); virtual;
destructor Destroy; override;
procedure PreSetSQL(ins: boolean); dynamic;
procedure pushSQL;
procedure popSQL;
function PostSetAndExecSQL: boolean; dynamic;

Дело не в этом, а в том, что заниматься подобными вещами далеко не все хотят. За что же деньги брать как не за Оракл ?
А то, что собственно SQL или ХП - это своего рода ассемблер - привыкли.
Давно и хорошо известно, что клиент-сервер вовсе не панацея.
В моем случае, используя терминальный режим проблема трафика снимается. (сервер-приложений).
И подавляющее большинство потребителей - это вовсе не терабайтные базы и 200 users.

← →
Serginio (2002-10-11 13:43) [13]

Alexandr таких предприятий оссобенно малых и средних к твоему сожалению очень много и живут. Но я веду речь немного о другом
На сколько нужно ООП баз данных 1С это 1 из примеров.

← →
Alexandr © (2002-10-11 13:44) [14]

достало

← →
Serginio (2002-10-11 13:49) [15]

Jeer При моем подходе зная правильно составленный словарь БД можно легко построить объектную модель. Единственный минус из за реляционности нужно посылать кучу маленьких запросов. Терминал сервер тоже не выход

← →
Jeer © (2002-10-11 13:54) [16]

Я не хочу обсуждать и осуждать 1С - у них свой путь, у меня свой.
Всего лишь уточнил, доступ к данным через объектный механизм в Дельфи вовсе не бредовая идея.

← →
Serginio (2002-10-11 14:00) [17]

Передавая не структурированные данные мкжду Сервером и Клиентом,
начинаешь строить объекты которые записывают и читают себя в Stream и приходишь к выводу
, что не так уж сложно сделать свою ООП БАЗУ ДАННЫХ с ранним связыванием, например вместо ID (если не нужен обмен между базами) прописовать смещение в файле объекта (очень сильно тормозят индесы не только поиск, но и его перестроение). Например строчная часть документа может сохраняться как список и не нужен огромный индес на всю строчную часть документов. Транзакции и блокировки тоже не такая большая проблема. Научить базовые объекты записывать, проводить, и считывать себя, обмениваться между клиентом и сервером только измененные части объекта.И все это делать как Клиент - Серверное приложение. Только так можно сделать корпоративное решение и скорость будет просто бешенная. А то в 1С думаешь кто быстрее посчитает я на счетах или она.

← →
Alexandr © (2002-10-11 14:02) [18]

это мне чертовски напоминает COM...

Ну, я думаю, что индекс на длиннострочные поля никто и не делает:))
Технология ISAM(index search..), применяемая в подавляющем большинстве СУБД пока себя еще оправдывает.
Транзакции и блокировки обеспечиваются СУБД.
Обсуждать создание своих СУБД вряд ли здесь целесообразно:))

← →
Serginio (2002-10-11 14:12) [20]

Alexandrу. Это не COM а самые настоящие иерахические объекты с огромой (если не бесконечной т.к дочерний объект может содержать родительский) вложенностью.
и еще 1С программисты говорят, что это очень сложно и никто так не будет программировать.

Вот Я и хотел узнать Нужнали скорость и облегчение ООП программирования или это очень сложно и пусть каждый занимается теми средствами которые дают производители.

http://www.kuban.ru/cgi-bin/forum/forum9.cgi?page=3&ask=68618

Да, уж...
"А программистов на Delphi думаю будет побольше, чем "программистов" 1С". - Ваши слова.
Однако, на "Кубани" дискуссия как-то оживленнее была.
Да и поглубже, повыше уровнем, пожалуй... Возможно, пока!
Не стал Вам отвечать на форуме Территории 1С, но раз Вы
сюда пожаловали:
Serginio, дело не в моих личных симпатиях или антипатиях
(в смысле к софту и программированию), но там, на Территории 1С,
эта тема, думаю, актуальнее.
И дело не в том, что Вы сделали что-то не так или плохо.
Просто идея все-таки довольно туманна, и, пока, сыровата,
на мой взгляд. Именно идея, а не ее реализация (это дело
будущего и это дело далеко не одного дня).
Видимо, не находит она еще отклика в умах и сердцах
Ваших слушателей. Думаю, Вы пытаетесь замахнуться на довольно
серьезную разработку, а ее необходимо продвигать
аккуратно и нежно, а не выкладками исходного текста как
обухом по голове.
Прислушайтесь к словам toypaul об инертности и т.п.
Примерно это я и хочу сказать. До того, что Вы предлагаете
необходимо созреть, дойти до необходимости подобного подхода
самому, или многим из нас. Чтобы он де-факто становился
потихоньку подобием стандарта, "средством выживания", как
пишут в "умных книжках", которые все мы читаем.

Бессмысленно человеку из средневековья, размахивающему
двуручным мечом предлагать пользоваться банкоматами и
кредитными карточками. Ну, тут я краски сгустил, признаю,
но что-то в этом духе.

Прошу не принимать мои слова как критику, в штыки,
это просто попытка порассуждать вместе с Вами на эту тему.

Если говорить о Дельфи, то вот это
Jeer © (11.10.02 13:43)
позволяет создавать готовые структуры и классы из нескольких десятков таблиц за 1 день.

← →
Serginio (2002-10-11 14:28) [23]

LordOfSilence Большое спасибо все о чем ты сказал првда на 80 процентов. Тогда другой ворос 1С создала свой язык доступа к БД и открыла к себе доступ и люди потянулись. Я предлагаю по сути тоже самое но завернутое в Delphi с полным отходом от IDispatch.
И получать имена процедур и объектов через точечку. Многие пользуются объектами абсолютно не зная их начинки

← →
Serginio (2002-10-11 14:36) [24]

Jeer © (11.10.02 14:12) Я с тобой полностью согласен. Но из 1С я получаю описание объектов за 1 сек через их метаданные и зная наперед структуру легко с ними работать.
А создание ООП базы давно назрел, но только ввиде DLL.

Есть такой обьектно-ориентированая СУБД Cаche так там примерно все так и реализовано. Создаешь класс в его обьект инспекторе, при этом он позволет обращатся и через SQL в табличном виде при этом описание класса он умеет экспортировать в tlb (или можно обращатся через позднее связывание) и с CASE средствами интерфей есть. Сам только начинаю разбиратся в нем (хорошая книга изд Питер "Cache чего то там" (название не помню) с ней и диск с 1-пользовательской версией)).
А попытки работать с табличной реляционной СУБД с собиранием в своей клиентской программе обьектов сильно напоминает способ парковки автомобиля когда в гараже он разбирается по винтикам и убирается в ящички, затем когда возникает необходимость ехать он собирается снова. Такой способ имеет право на жизнь, но эффективность его вызывает большие сомнения (это цитата из руководства по Cache)

← →
Serginio (2002-10-11 15:07) [26]

По СУБД Cаche первый вопрос в tlb он предоставляет COM объекты или dispinterface. Второе она компилирует исходный код или работает с поздним связыванием. А на счет "А попытки работать с табличной реляционной СУБД " если создал структуру то изменять надо только после реструктуризации БД

1С на Delphi Найти похожие ветки