---|Ветка была без названия|---

← →
Style (2003-03-12 10:53) [0]

Уже в течении полугода пишу программу ядерной безопасности. Программа принемает данные с определенной платы и записывает их в базу данных. Я выбрал Paradox. После многих неудачных опытов и попыток сменить базц на другой формат я всеже вернулся к Paradoxу.
Вообще вся база данных должна содержать седующую информацию

Дата и Время - (DateTime)
Концентрация U235_1 - (Float 20 знаков после запятой)
Концентрация U235_2 - (Float 20 знаков после запятой)
Концентрация U235_3 - (Float 20 знаков после запятой)
Концентрация U235_4 - (Float 20 знаков после запятой)
Oшибка 1 - (SmallInt)
Oшибка 2 - (SmallInt)
Oшибка 3 - (SmallInt)
Oшибка 4 - (SmallInt)
И еще четыре поля содержащие Memo данные

1. Моя неудачная попытка - использование Мемо полей.
База стала рости до немеренных размеров по непонятным причинам.
Пробывал разные форматы баз. Все попытки оказались неудачными.
т.к. из базы нужно удалять информацию на совсем!

Я поступил следующим образом: Оставил формат Paradox, А поля Мемо заменил на таблицу -> memos.db а в своей главной базе стал хронить указатили на ID в таблице с мемополями...

Самое страшное что в таблице memos. должны храниться тоже Doubleвские значения т.е. 20 знаков после запятой. т.е. Каждая запись в Base.db Должна хранить в себе 1024 Double значений из memos.db
Структуру memos.db я сделал следующую ID, I1,i2,i3,i4....i254 т.е у меня уместилось только 254 поля с данными.
4 строчки в этой таблице приндлежат 1 строчке в таблице base.db!

+ В программе существуют еще 2 таблицы const.db и const2.db в которых уже хранится около 400 констант программы. Для каждой записи Base.DB!

Так вот появилась следующая проблемма вся эта информация если я использовал QUERY! (так называемый SQL) начитывалась минимум секунд 40!Если использовать Locate то такая же картина.Причем объем memos.DB это 40000 строк по 256 Dooble полей..

Поэтому я отказался от SQL!

Стал использовать TTable и метод MoveBy..

Причем Если курсор находился примеру ближе к началу базы я сначала делал BOF а потом MoveBy дабы ускорить доступ к информации информации в memos.db

На Celerone 600
Получилась следующая картина: Начитка всей инфы если я перемещаюсь из начала в конец занимает меньше секунды, но если я перемещаю курсор в середину минимум секунд 16! Но только первая начитка т.е если я опять перемещаю курсор где нибудь по близости данные загружаются моментом!

Так вот в чем вопрос.. Мою программу юзают и более слабые Компы.. Как бы сделать быстрее.. Есть ли более оптимальное решение моей проблеммы????

P.S. простите меня за мою грамматику :)

← →
Sheriff (2003-03-12 10:56) [1]

мда... начало многообещающее...

← →
Dred2k (2003-03-12 11:16) [2]

"Нииииччччего не понимаю" (c) коллега
К сожалению, суть задачи улавливается с трудом.
Одно могу сказать точно - мемо поля парадокс хранит, скажем, не совсем оптимально. ;) Объем файлов действительно неадекватен объему хранимой инфы. Ну да ладно...
Диагноз - непроработанная структура таблиц.

> Дата и Время - (DateTime)
> Концентрация U235_1 - (Float 20 знаков после запятой)
> Концентрация U235_2 - (Float 20 знаков после запятой)
> Концентрация U235_3 - (Float 20 знаков после запятой)
> Концентрация U235_4 - (Float 20 знаков после запятой)
> Oшибка 1 - (SmallInt)
> Oшибка 2 - (SmallInt)
> Oшибка 3 - (SmallInt)
> Oшибка 4 - (SmallInt)
> И еще четыре поля содержащие Memo данные

Как я понял из вышенаписанного, таблица вообще одна - каждая запись является "неким состоянием некой системы" на момент времени. Ну и все. В чем проблема? Если искать хочешь по полям "И еще четыре поля содержащие Memo данные" - от мемо придется отказаться. Или только перебором.

> (так называемый SQL)

Самый обычный и полезный SQL. Не обижай его! ;))

← →
Соловьев (2003-03-12 11:18) [3]

Парадокс для ядерной безопасности.... а потом Чернобыль. :((((

← →
Style (2003-03-12 11:28) [4]

>> Dred2K
Вся проблемма заключается в быстроте доступа к данной информации.
А тратить время на базу данных мне не охота. Так как там и помимо того очень много математических расчетов и прочей ядерной лабуды.

>>каждая запись является "неким состоянием некой системы" на момент времени
да именно так. вообще в base.db должно максимум храниться 10000 точек. + 4 канала содержащии по 256 точек типа Double! + около 400 констант типа Double!

Меня волнует время получения этой информации и не более.

>>Самый обычный и полезный SQL. Не обижай его! ;))
Да ты прав самый обчный.. Как есть. т.е упрощенный (урезанный) до невозможности. :))

← →
Style (2003-03-12 11:29) [5]

>> Соловьев..

Да.. будем винить в этом Borland :))

← →
Sergey13 (2003-03-12 11:49) [6]

2Style (12.03.03 10:53)
>Уже в течении полугода пишу программу ядерной безопасности
Ты меня извини, но ты пишешь рабочую систему или диплом/курсовик? Если первое то пора отсюда (из России) мотать. Хотя от этого уже не убежишь. 8-(
Если по ядерной безопасности проги пишет человек спрашивающий советов в форуме и использует для этого парадокс... Ну все, край... Это же ядерная угроза!!! 8-) или правильнее 8-(

← →
Dred2k (2003-03-12 11:49) [7]

> Вся проблемма заключается в быстроте доступа к данной
> информации. А тратить время на базу данных мне не охота.
Два взаимоисключающих желания. Поверь мне, забьешь на базу - хлебнешь с лихвой. Не будет радости потом расчеты делать...
> Так как там и помимо того очень много математических расчетов
> и прочей ядерной лабуды.
В идеале, конечно, вас должно быть двое...
Коль ты базы не любишь. ;)

> >каждая запись является "неким состоянием некой системы" на
> >момент времени
> да именно так. вообще в base.db должно максимум храниться
> 10000 точек. + 4 канала содержащии по 256 точек типа Double!
> + около 400 констант типа Double!
Ладно, давай от твоих терминов и толкнемся.
Точка - сущность. Все остальное - атрибуты. Для порядка - суррогатный ключ типа Integer. Вот и вернулись мы к одной таблице. С твоими любимыми блобами (ну или мемо). :)
Искать по каналам и константам ты не сможешь. Да и не нужно, как я понимаю. Возьмешь по периоду времени группу записей, пойдешь по ним и сделашь расчет (тут ты и мемо вынешь, и что угодно - и обработаешь). Вот и все.
> Меня волнует время получения этой информации и не более.
Пройтись даже по всем 10 штукам долго не займет.
И по сотне тоже. Расчет дольше будет ;)

>>Самый обычный и полезный SQL. Не обижай его! ;))
>Да ты прав самый обчный..
>Как есть. т.е упрощенный (урезанный) до невозможности. :))
Ну, в предыдущих вресиях BDE он еще хуже был... ;)
Зато локальный. А прикинь, как без него тяжко было бы. Оракл - муть ведь жуткая! ;)))

← →
Style (2003-03-12 11:51) [8]

Sergey13>> Скажем так это для Докторской десертации отдного человека :)

← →
Dred2k (2003-03-12 11:55) [9]

> Sergey13>> Скажем так это для Докторской десертации отдного
> человека :)

Блин, а я то уж думал - в интересах стратегической безопасности нашей Родины тут кумекаю....
Какой облом!!! ;)))

← →
Style (2003-03-12 12:10) [10]

Dred2k © >>
Наверное я немного не правильно описал свой жуткий вопрос?

От мемо полей я уже давно отказался..
Т.к. приходится делать из базы Delete и причем такой Delete Что бы совсем все данные пропадали в никуда.. А вот с Мемо полями это невозможно ;)

Дальше.. Представь такую картину.

Base.DB: (Максимум 10000 строк Далее удоляеться самая верхняя)
Date,ID, Dbl1, Dbl2, Dbl3, Dbl4, Int1,Int2,Int3,Int4;

Const.DB:
ID(из Base.DB), Dbl1....Dbl254

Const2.DB:
ID(из Base.DB), Dbl1....Dbl254

Memos.DB:
ID
(из Base.DB), Dbl1....Dbl254 (4 строчки для каждой записи в base.db)

т.е. Чтобы начитать информацию мне нужно..

Select * from Const where ID = :ID (ID из base.db)

var
Str: TStringList;

Str := TStringList.Create;

For i:= 1 to ConstQuery.FieldCount-1 do
begin
Str.Add(ConstQuery.Fields[i]
end;

Select * from Const2 where ID = :ID (ID из base.db)
Также начитываем

Select * from Memos where ID = :ID (ID из base.db)

Зачитывем в 4ре StringList-а Для 4 записей

Так Вот если я использую SQL это происходит секунд 40-50
Пришлось юзать MoveBy!

← →
Style (2003-03-12 12:12) [11]

Dred2k >> Да это ж я чтоб народ не пужался :)))
А потом кто его знает куды программа пойдет

← →
Anatoly Podgoretsky (2003-03-12 12:18) [12]

Ядерная безопасность и Парадокс не совместимы

← →
Sheriff (2003-03-12 12:26) [13]

...потому Парадоксом и называется... :)

← →
Style (2003-03-12 12:34) [14]

>> Anatoly Podgoretsky
Спорим совместимы: Программа отлично работает .. Тестируется на нескольких заводах. Я обезопасил все эти глюки сделал и реиндексацию в базе и т.д..
Меня волнует только скорость с таким количеством Double значений.

← →
DarkGreen (2003-03-12 12:35) [15]

2 Style (12.03.03 12:12)
Надеюсь ты не с Семипалатинска....
А то мы тут недалече... ;-))
Звиняюсь за оффтоп

← →
Соловьев (2003-03-12 12:38) [16]

Тут рядом идет обсуждение о крахе Парадокса раз в месяц... О какой безопасности и тем более ядерной можно говорить? Парадокс это настольная БД для хранения картотетки о домашних аудиозаписях. Конечно утрирую, но все-таки. Неужели компания занимающаяся ядерной безопасностью не может раскошелится на лицензионный Oracle, DB2 или хотя бы Interbase, Sybase, MS SQL?

← →
Style (2003-03-12 12:46) [17]

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

Но иногда эту инфу нужно достать оперативно. Если учесть то что в базу она записываеться каждые 10-15 сек.

← →
Anatoly Podgoretsky (2003-03-12 12:53) [18]

Style (12.03.03 12:34)
Во первых признайся в каких городах ты обезопасил нам, некоторые смогут вздохнуть с облегчением.

← →
Соловьев (2003-03-12 12:53) [19]

2 Style (12.03.03 12:46)
Ты хоть не в Украине находишся? Где только дают заказы на разработку ПО для ядерных исследований? Там наверное деньги отмыть хотят. Все и так работает на ЕС-ках.

← →
Sheriff (2003-03-12 12:57) [20]

за безопасность должна отвечать только аппаратная часть, да еще с не менее чем 3-мя уромнями независимого дублирования!
иначе, какое к черту быстродействие!?
а программа - лишь для логов, да для перевода данных в доступный для юзера вид.

← →
Dred2k (2003-03-12 12:58) [21]

> Dred2k >> Да это ж я чтоб народ не пужался :)))
> А потом кто его знает куды программа пойдет

Мда... Опасения за безопасность моей любимой Родины снова усиливаются...
Ты пойми - парадокс в этом плане тебе не подойдет, раз уж все так запущено. Пароли ставить не пытайся - инженерку jIGGAe еще никто не отменял. Ну и многое что можно сказать, да ладно...

> Наверное я немного не правильно описал
Ну как получилось...
> свой жуткий вопрос?
Эээтт точно (c) т. Сухов
С этим уж проблем нет...

> От мемо полей я уже давно отказался..
> Т.к. приходится делать из базы Delete и причем такой Delete
> Что бы совсем все данные пропадали в никуда.. А вот с Мемо
> полями это невозможно ;)
А спорим - возможно! (блин, как все запущено...)

procedure PackTable(Table: TTable);
{ This routine copied and modified from demo unit TableEnh.pas
from Borland Int. }
var
{ FCurProp holds information about the structure of the table }
FCurProp: CurProps;
{ Specific information about the table structure, indexes, etc. }
TblDesc: CRTblDesc;
{ Uses as a handle to the database }
hDb: hDbiDB;
{ Path to the currently opened table }
TablePath: array[0..dbiMaxPathLen] of Char;
Exclusive: Boolean;
begin
if not Table.Active then raise EDatabaseError.Create(SDataSetClosed);
Check(DbiGetCursorProps(Table.Handle, FCurProp));
if StrComp(FCurProp.szTableType, szParadox) = 0 then begin
{ Call DbiDoRestructure procedure if PARADOX table }
hDb := nil;
{ Initialize the table descriptor }
FillChar(TblDesc, SizeOf(CRTblDesc), 0);
with TblDesc do begin
{ Place the table name in descriptor }
StrPCopy(szTblName, Table.TableName);
{ Place the table type in descriptor }
StrCopy(szTblType, FCurProp.szTableType);
bPack := True;
bProtected := FCurProp.bProtected;
end;
{ Get the current table"s directory. This is why the table MUST be
opened until now }
Check(DbiGetDirectory(Table.DBHandle, False, TablePath));
{ Close the table }
Table.Close;
try
{ NOW: since the DbiDoRestructure call needs a valid DB handle BUT the
table cannot be opened, call DbiOpenDatabase to get a valid handle.
Setting TTable.Active = False does not give you a valid handle }
Check(DbiOpenDatabase(nil, szCFGDBSTANDARD, dbiReadWrite, dbiOpenExcl, nil,
0, nil, nil, hDb));
{ Set the table"s directory to the old directory }
Check(DbiSetDirectory(hDb, TablePath));
{ Pack the PARADOX table }
Check(DbiDoRestructure(hDb, 1, @TblDesc, nil, nil, nil, False));
{ Close the temporary database handle }
Check(DbiCloseDatabase(hDb));
finally
{ Re-Open the table }
Table.Open;
end;
end
else if StrComp(FCurProp.szTableType, szDBase) = 0 then begin
{ Call DbiPackTable procedure if dBase table }
Exclusive := Table.Exclusive;
Table.Close;
try
Table.Exclusive := True;
Table.Open;
try
Check(DbiPackTable(Table.DBHandle, Table.Handle, nil, nil, True));
finally
Table.Close;
end;
finally
Table.Exclusive := Exclusive;
Table.Open;
end;
end
else DbiError(DBIERR_WRONGDRVTYPE);
end;

Используешь так:

Что-то делаешь весь день с данными...
Удаляешь...
Удаляешь...
Удаляешь...
Удаляешь...
Удаляешь...
Удаляешь...
ОБА! А секретность!? -[]
И тогда:
Table.DisableControls;
try
Table.Open;
PackTable(Table);
finally
Table.EnableControls;
end;

Не забудь uses BDE, DBConsts.
Компили, дело верное. И будет тебе счастье.
Видишь, как просто открываются по-новой ранее упущенные клевые возможности. ;)

> Дальше.. Представь такую картину.
Да представил, представил...
Тебе один путь - вернуть мемо и не извращаться.
Писать его будешь как FieldByName("SuperMemo").AsString := строка с числами (лучше хранить через интежер, приводи Double к TDateTime - это и так одно и то же, потом изучи как работает
DateTimeToTimeStamp и TimeStampToDateTime). Точность абсолютная, а хранить просто (учитывая список значений ...).
Читать так же.

> Так Вот если я использую SQL это происходит секунд 40-50
Конечно. На каждую запись ты запрос мочишь! Ключи хоть есть по ID? Master-Detail, батенька! И только он для такой системы.
> Пришлось юзать MoveBy!
Это что это за MoveBy?! Ты что, заклыдваешься на прямое соответствие расположения записей в главной и подчиненных таблицах? Блин, трудный случай.

← →
Style (2003-03-12 13:16) [22]

Dred2k>>
Как же думаешь сколько времени займет PackTable

Ты что, заклыдваешься на прямое соответствие расположения записей в главной и подчиненных таблицах? Блин, трудный случай.
->> Именно прямое расположение другое и не нужно.. Представь что это просто некий Кэш.. в котором накапливается 10000 точек и в момент добавления 10001 10000 удаляется...

← →
Style (2003-03-12 13:17) [23]

>> т.е не 10000 а 1 я запись удаляется

← →
Style (2003-03-12 13:23) [24]

Народ и пожалуйста не оспаривайте мое "оптимальное решение"... Наоборот посоветуйте как мне сделать лучше и какую БД использовать в данной ситуации..
И так чтобы все это происходило быстро!

← →
Соловьев (2003-03-12 13:24) [25]

ИМНО, спецБД - написанную серьезной канторой, которые не новички в ядерной безопасноти...

← →
Style (2003-03-12 13:26) [26]

Sheriff -> Сам прибор это новый революционный подход в ядерной безопасности поэтому раскрывать его технологию я не вправе. А то что в аппаратной части есть свои блоки безопасности это естественно. Но изменение концентрации высчитывает сама программа Зате возвращает данные в прибор.. И уж только потом записывает их в базу..

← →
Style (2003-03-12 14:01) [27]

>>Anatoly Podgoretsky
Новосибирск, Омск, Электросталь :)) Страшно...

← →
Soft (2003-03-12 14:02) [28]

Изверг.

Ты хоть не под 95-ткой её ставишь?

А если программа неправильные данные в прибор вернет и что тогда... Скоро эхом грянет Cтрашный Русский ренесанс:(

По своему опыту не рекомендую использовать досявые базы. Выбрал когда-то DBISAM так два месяца работы просто так нафик пропали. Теперь использую Access, вроде не глючит. Программа тоже оборонного значения(для Украины).

Своему знакомому, когда он с таким примерно вопросом ко мне пришел я сказал, чтоб взял Access. Теперь у него все без проблемм работает, быстро и стабильно.

← →
Dred2k (2003-03-12 14:12) [29]

>Как же думаешь сколько времени займет PackTable
Думаю, ты и не заметишь. Конечно, если не собираешься заниматься абсолютно бесполезной упаковкой при каждом удалении записи.
А вот заметишь ты, причем очень быстро, насколько труден и фатален сизифов труд. Это когда тебе пару десятков констант придется добавить или точек штук пять, в крайнем случае... Тут-то ты о мемо и вспомнишь. ;)
(блин, а ведь зря звезды героя не дают за такие подвиги - сотни полей, надеюсь, автоматом создаешь или же все таки ... о, Боже!).
;))

> Именно прямое расположение другое и не нужно.. Представь что
> это просто некий Кэш.. в котором накапливается 10000 точек и > в момент добавления 10001 10000 удаляется...
"Толково придумано." (c) МВИН
Это фифошка, блин, какая-то получается. Сразу обсчитывать вносимую запись и сублимировать в результат не пробовал. На лету?
Зачем иметь только 10000, но последних? Только последних, но 10000?
;)

>Народ и пожалуйста не оспаривайте мое "оптимальное решение"... >Наоборот посоветуйте как мне сделать лучше
Да вот пытался.
>и какую БД использовать в данной ситуации..
>И так чтобы все это происходило быстро!
Мдаа.... Все ясно.
Мой фюрер, предлагаю поправить треуголку и учить матчасть.
;))

>ИМНО, спецБД - написанную серьезной канторой, которые не >новички в ядерной безопасноти...
Я за. И даже без ИМНО...
Думаю, если дисер свет увидет - на парадокс положат и вообще.
Все там по-другому будет и другими...

← →
Sheriff (2003-03-12 14:16) [30]

При таких исходных данных ничего путевого посоветовать нельзя.
А вообще задача разбивается минимум на 3 подзадачи:
- организация данных в БД
- занесение данных в БД
- выборка данных их БД

все это с соблюдением требований:
- надежность
- достоверность
- быстродействие

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

← →
Style (2003-03-12 14:32) [31]

Soft>> Пробывал я на Access переводить. через ADO но база ACCESS тоже стала рости. Delete не всегда удолял на проч запись и в итоге база набирала 1Гб и вставала..

Dred2k © >> Я же писал что Мемо поля работали все было хорошо..
И удалялась инфа из БД вроде бы тоже. Но по абсолютно непонятным причинам База вставала раком.. т.е файлик набирал 2GB. Поэтому я начал извращатся.

Так вот в одних форматах не удалялась инфа вовсе.
В других скорость не устраивала.

Вернулся в парадокс и стал работать напрямую с Table..

← →
Style (2003-03-12 14:40) [32]

Dred2K->>
Зачем иметь только 10000, но последних? Только последних, но 10000?
===
Так хотят заказчики. Именно 10000 точек.. Так именно зарегистрирован прибор. Да и еще со старой программой которая вообще была написана на VisualBasic как раз в Украине не мной :)

← →
Soft (2003-03-12 14:42) [33]

Style>> Пробывал я на Access переводить. через ADO но база ACCESS тоже стала рости. Delete не всегда удолял на проч запись и в итоге база набирала 1Гб и вставала..

Сейчас я на работе, не поленись прислать мне на домашний адресс alife-soft@yandex.ru письмо с напоминанием, я тебе вышлю программный код сжатия базы Acess. А Delete не удаляет записи оно их только отмечает к удалению. Таковы уж заморочки и с Access.

А хочешь совсем просто быстро и стабильно - ставь Oracle Lite, PII-350 256M ОЗУ и полный кайф. Будет летать при любой(даже самой идиотской) конфигурации базы(и пользователей) :)

← →
Style (2003-03-12 14:45) [34]

Dred2K>>
Сейчас заполненная базад данных занимает 192 мега. т.е. сумма всех 4-х файлов.. Самый большой -> Memos.db

Sheriff>> А как мне надо было поступить если не Парадокс то что???
Тем более меня торопил заказчик.. Очень сильно торопил.

← →
Style (2003-03-12 14:48) [35]

Soft >> Представь что программа должна работать непрерывно занося каждые 10 а то и 5 сек данные в Базу (таки громоздые FLoatы), а ACCESS вообще удальть не умеет как ты говоришь.. Поэтому я и отказался от него сразу..

ALL
-->> Кстати с этими опытами постоянной записи в винт и удаления я протер на Винте( Barracuda Seagate 60GB) себе Дырку :)) После чего решил поменять его на новый.. Поэтому с этой прогой наверняка надо еще и менять аппартку к примеру на SCSI

← →
Sheriff (2003-03-12 14:57) [36]

о! уже 5 сек...
а нужно ли постоянно записывать данные в БД, если с ними никто не работает?
или за 5 сек пользователь успеет сделать выборку и принять решение?

← →
Sheriff (2003-03-12 14:58) [37]

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

← →
Style (2003-03-12 15:06) [38]

Sheriff-> Можно и 1 сек.. Можно и меньше секунды.. Я так сделал.. Только Программа Сначала дает считать данные а потом их продолжает записывать в отдельной нити..
Это время измерения для прибора - настройка пользователя.

← →
Style (2003-03-12 15:10) [39]

>>>кстати, вовсе не обязательно вставлять новую запись и удалять ненужную... достаточно вставлять новые данные на место ненужных.

Я думал об этом но так можно конкретно повесить базу. т.е надо постоянно следить за тем ID который надо затирать. (некоторое неудобство), так вот Есть же возможность удалять их Парадокса поэтому я подумал почему бы и нет!

← →
Style (2003-03-12 15:11) [40]

Так все же. Парадокс или Что???

---|Ветка была без названия|--- Найти похожие ветки