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

← →
Satirus (2003-03-13 17:44) [160]

Это тоже самое, что винить топор в том, что с помощью его нельзя точно также аккуратно вырезать заготовки с фанеры, как и с помощью лобзика.
Вместо того, чтобы усовершенствовать свое умение владением топора, лучше освой работу с лобзиком или попроси того, кто уже умеет и владеет.

← →
Style (2003-03-13 18:04) [161]

Anatoly Podgoretsky © >>
Я никого не виню на протяжении всей ветки. А говорю то, не
вместо того чтобы говрить по делу задумайте о самом
вопросе организации БД в данной ситуации.

или попроси того, кто уже умеет и владеет>>
Что я и выпытаваю от вас на протяжении всей Ветки.!

Уже не трудно догадаться до того что я хотел сделать. И если бы
вы хоть въехали в суть самого вопроса. Может ответили бы мне как
настоящие специалисты!

← →
Style (2003-03-13 18:18) [162]

И все таки нашелся один хороший человек. Написал мне письмо.. Хотел на пальцах мне объяснить что я не прав..
Но в итоге со мной согласился. И предложил еще более оптимальное решение!

Люди или я что то не так объясняю или вы так уверены в своей правоте и в своих стандартных подходах...

Самый умный ответ по поводу. Хранения информации в отдельном файле! Это лучшее что я услышал.

А так из темы с которой могут столкнутся другие программеры сделали пустую болтавню...

← →
alxx (2003-03-13 18:18) [163]

Мне влом все это читать, но если не обращать внимания на "надежность" парадокса могу порекомендовать следующее (может быть уже порекомендовали:

Одна таблица

1.<IDENTITY> - автоинкремент
2.Дата и Время - (DateTime)
3.Концентрация U235_1 - (Float 20 знаков после запятой)
4.Концентрация U235_2 - (Float 20 знаков после запятой)
5.Концентрация U235_3 - (Float 20 знаков после запятой)
6.Концентрация U235_4 - (Float 20 знаков после запятой)
7.Oшибка 1 - (SmallInt)
8.Oшибка 2 - (SmallInt)
9.Oшибка 3 - (SmallInt)
10.Oшибка 4 - (SmallInt)

Вторая таблица

1. Номер выборки (Identity из первой таблицы).
2. Спектра (1..4)
3. Номер Double значения (1..256)
4. Само Double значение.

Таблица 2 будет охрененно большой, но ее структура весьма проста. Нужны индексы по 1,2,3 полю.

Ну и пофигу, что нужно будет 1000 апдейтов.

← →
Style (2003-03-13 18:34) [164]

>>>Ну и пофигу, что нужно будет 1000 апдейтов.
Даже если это займет 1 сек. меня это не устроит..

Сейчас Insert в базу, расчеты, удаление из базы! проходит от 100 до 250 милисекунд.

А с Апдейтами быстрее не получится.

Не устраивает такой подход.

← →
Style (2003-03-13 18:36) [165]

>> Просто программа чаще пишет в базу чем читает из нее.!

Поэтому запись должна проходить незаметно!

← →
REA (2003-03-13 18:38) [166]

Все же надо сначала определиться к каким последствиям может привести переполнение "патчука" и что будет, если "эта хрень" все-таки выйдет наружу.
Я ипользую Windows+Delphi+Paradox (хотя и с приседаниями) для систем мониторинга на буровой, но там все не так критично и подстраховка другого железа все-же есть. Темп опроса 100мс, порядка 100 параметров, запись на диск 1сек. В принципе запись в таком темпе работает и с Interbase. Работать в таком режиме можно наверно от недели до месяца - windows все равно-падает, хотя бы по причине игр операторов.
Для более требовательных к надежности систем лучше использовать другие средства, хотя конечно можно поставить 10 компьютеров с windows - один да выживет в каждый момент времени.

← →
alxx (2003-03-13 18:40) [167]

Ну и запросики...

Тогда остается в файл писать.

← →
fool (2003-03-13 18:49) [168]

прикольно в конце рабочего дня расслабиться, просмотрев ветки вроде этой: разговор слепого с глухими; сильного с умными и т.д. и т.п.
"зачем мне книги по БД читать - я привык делать то, что всем нравиться, причем с 8-ми лет, а вам не нравиться, может вы с такой ответственностью не сталкивались или в армии не были"
"зачем мне надо представлять что такое раляционная БД - я на работе это каждый день слышу", может слышать недостаточно?

← →
Style (2003-03-14 07:55) [169]

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

REA>>>и подстраховка другого железа все-же есть. >>
Соответственно и здесь есть подстраховка.
Если Windы повиснут на это предусмотрен аппаратный блок защиты.
>> На счет игр операторов..
Заблокируй им доступ чтоли к ним
EnableWindow(FindWindow("Progman",nil),false);
EnableWindow(FindWindow("Shell_TrayWnd",nil),false);

> Значит ты PARADOX используешь.. Почему люди боятся парадокса и прямой работы с Таблицами. Потому что сложилось общее мнение о том что будут пропадать записи?? Они не будут пропадать если вовремя сделать FlushBuffers -> записать данные на диск и забыть про них.
Программа уже неделями пахала на некоторых рабочих станциях. И все работало быстро и красиво. Единственное что меня волновало как помимо того чтобы быстро записать информацию еще быстро ее и считать. (Даже в момент набора данных и записи в базу)
Да я извратился и сделал так.. Но это работает!

fool © >> "зачем мне надо представлять что такое раляционная БД - я на работе это каждый день слышу", может слышать недостаточно?
>> Как никак я с этим работаю! И потому знаю что SQLSERVER на одну рабочую станцию смысла ставить нет. Конечно запросы будут проходить быстрее, но с 1000 а то и более апдейтами мы не выдем за 1 сек.

alxx ©>> Таков запрос.? И ничего тут не поделать.. А если это стало работать под Paradoxом быстро используя прямую работу с
таблицами... Потому я и отказался от BDEшного SQL, так как 1000 Updatов это слижком долго.. Я думал о том что буду заливать данные в один файл, но в то же время не хотел отказываться от базы данных ( вдруг заказчик затребует какой нибудь отчет из полученной инфы здесь то и понадобится Select..)

← →
KSergey (2003-03-14 08:10) [170]

Если немного по теме, то лично я бы скорее тогда уж состряпал какой-нибудь аппаратный блочек, который бы все делал, в особенности сохранял бы - все просто в ОЗУ (запитаном от аккумуляторов и т.д.). Здесь, на мой взгляд, можно добиться намного бОльшей надежности, нежели на дельфи и иже с ним. Я из всей ветки так и не понял ни разу зафиг вобще нужна БД: объем хранимой информации, как я понял, вообще постоянен. А 192 метра ОЗУ (или сколько там? во всяком случае упоминание каких-то заоблачных объемов я не встречал) сейчас вообще не проблема.
Только не надо говорить про сложные рассчеты. В конце концов, если уж и правда сложноватые, берется микроконтроллер специализированный - и вперед!

← →
Style (2003-03-14 08:24) [171]

KSergey © >> микроконтроллер специализированный - и вперед! >>

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

И всю эту информацию нужно сохранить. И желательно быстро и чтобы можно было выводить из этого отчеты. И вто-же время нельзя забывать про зарисовку.. которая тоже занимает где-то 50 - 100 милисекунд с использованием TDIB..

Нельзя забывать про ограничении в скорости машины. Это ISA плата.. Шины ISA уже давно нет.
Переводить прибор на PCI довольно трудоемко и деталь очень дороги работающие на такой частоте.

А когда ко мне приходит заказчик и говорит что надо собрать 24 компьютера с приборами. ПОтому что он уже их продал :)
Да а программа еще не готова. Да и с Мемо полями ничего не получается.. Остается неделя чтобы собрать компы, поставить приборы, доделать программу что бы она работала (потом уже можно допустить обновления версий)

Что мне тогда надо было делать???

← →
Style (2003-03-14 09:25) [172]

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

Как вам такое решение??

← →
Sergey13 (2003-03-14 09:30) [173]

2Style (14.03.03 08:24)
давай открывай новую ветку "Ядерная безопасность2", а то эту еле дочитал. На моей памяти это рекорд для веток про БД 8-)

По делу.
А эти 10000 записей с подчиненными должны сохраняться после завершения программы (все равно какого)? Или после начала работы сначала накапливается 10000 а потом начинается перезапись?
Если 2, то (просто как идея безумная 8-) можно попробовать использовать таблицы в памяти(Типа RxMemoryData , правда я не уверен в их поведени на таких объемах), т.е. на диск вообще ничего не писать.
Если 1, то можно попробовать тот же способ, но с добавлением записи изменений в рельную БД. Т.е. при добвлении/удалении в "виртуальной базе" идет короткая транзакция в "реальной".

Но по любому - необходимо иметь достаточно ОЗУ, что бы обеспечить расположение данных именно в нем, а не в свопе.

← →
KSergey (2003-03-14 09:33) [174]

> А когда ко мне приходит заказчик и говорит что надо собрать
> 24 компьютера с приборами. ПОтому что он уже их продал :)
> Да а программа еще не готова. Да и с Мемо полями ничего
> не получается.. Остается неделя чтобы собрать компы, поставить
> приборы, доделать программу что бы она работала (потом уже
> можно допустить обновления версий)

Стоп. Проблемы маркетинга мы сейча не обсуждаем.
Отдел маркетинга и его проблемы вообще не имеют ничего общего с качеством разработки чего бы то ни было. У них совсем другая задача: впихнуть покупателю фигню в красивой упаковке и с умными словами в иструкции ("пылесос с микропроцессором").

Года 2 назад видел разработку нашего советского НИИ для измерения жирности молока (заметьте: если что - тут даже не опасно попадание в глаза!). Так она была сделана профессионалами, на порядки качественнее!!! Так что остается лишь согласиться с Anatoly Podgoretsky: "Что то не в порядке в государстве с контролем за ядерной безопасностью если такие вещи имеют место быть".

> А как же все настройки пользователя.

Я не понял в чем проблема. А что им сделается? Настройки хранятся в ПЗУ ("это около 400 пользовательских констант" - да хоть тыща!). Пользователь ну никак не зменяет все эти контанты в течении 1 секунды. Так что это, как раз, можно вынести на комп с красивыми окошечками и на досуге переливать в аппаратную часть.

> Вообще принемаются Спектры с данного прибора.. Рисуются
> на дисплее Спектры умножаются на матрицу. (таким образом
> сглаживаются)..
> И всю эту информацию нужно сохранить.

И в чем проблема? Уточните.

> И вто-же время
> нельзя забывать про зарисовку.. которая тоже занимает где-то
> 50 - 100 милисекунд с использованием TDIB..

Я не понял о какой зарисовке речь. Вообще закралось смутное подозрение, что рисуется на экране, а потом на основании рисунка все вычисляется. Или я то-то недопонял?

> И желательно быстро
> и чтобы можно было выводить из этого отчеты.

Стоп. Давайте так: мухи отдельно, котлеты одтельно. Отчет для кого? Для человека? Человек не может (не способен) прочитывать 4000 чифр за 1 секунду. Я в этом уверен. Следовательно, отчеты для человека - это тоже не критичные по времени вещи (задержка в неск. сек. тут ничего не решает). Если речь, конечно, о неких статистических отчетах, а не о той лампочке, зажигание которой говорит, что через 5 сек. капец. Так что тут опять не понятно зачем торопиться.

> Нельзя забывать про ограничении в скорости машины. Это ISA
> плата.. Шины ISA уже давно нет.
> Переводить прибор на PCI довольно трудоемко и деталь очень
> дороги работающие на такой частоте.

Что такое дорогие?! А на фоне стоимости даже датчиков - тоже дорогие? Не говоря уже о всей установке в целом. Впрочем, при чем тут вообще шины компа IBM PC, когда речь идет о внешнем аппаратном блоке.

Вообще я бы еще раз подвел некое резюме.
Впечатление, что система разработана делитантами (это не оскорбление, это обычное слово из отзыва о проекте), которые не имеют никакого кругозора в своей области деятельности, не имеют никакого опыта, пытабтся лишь известными ими методами решить все. Собственно вся ветка об этом. Ты хочешь услышать конкретный совет, но проблема в том, что проект изначально неверно построен.

← →
app (2003-03-14 09:49) [175]

Sergey13 © (14.03.03 09:30)
На фиг, хватит и одной ветки, что бы еще раз не разводить флейм по новому, а тут все перед глазами.

← →
Style (2003-03-14 10:04) [176]

app © >> Ну хоть бы ответы сохранил!

← →
Style (2003-03-14 10:09) [177]

>> Впечатление, что система разработана делитантами..

Неверное Впечатление. Их Приборы уже лет 7 на производстве.

Просто тут не идет речь о реальной безопасности..
Лишь об организции БД или замены ее на Один файл..

Сама безопасность подстраховывается аппаратно. Т.е. если даже
винт полетит или чего с компом ничего страшного в этом нет.
Процесс остановится.

← →
Style (2003-03-14 10:45) [178]

Я тут стишок сочинил наверное по теме..

Некого просить о помощи в трудную минуту
Наверно только бога но вериш в него смутно
Немного жутко становится если представить
Что ты совсем один и никого нет рядом
Ощущать взглядом по всюду пустоту
Слышать вместо музыки только тишину
Опустить руки закрыть глаза
Хочется отправит душу свою на небеса
Может там найдутся родные голоса
А может лица которые смотрят сверху на тебя
Ужасаются страдают или просто плачут
Как будто понимают что нельзя иначе
Но всеж если поверить что найдутся люди
Тогда они изменят твою судьбу других осудят
Так будет если не сидет на месте
Не загоняться местью лестью всем вместе
Думать о своей полезности в этом обществе
Где нет верности есть одиночиство
Тут просто каждый за себя в точности,
как звери запертые в клетку
и чтобы выйти на свободу готовы грызть решетку
Снять с тебя шмотки продать за сотку баксов
Купить натсов, сникерсов, марсов
Против них нет санкций нет законов
И каждый возомнил себя судьей и прокурором...

← →
KSergey (2003-03-14 10:55) [179]

> Style (14.03.03 10:45)
> Некого просить о помощи в трудную минуту
> Наверно только бога но вериш в него смутно
> Немного жутко становится если представить

Чушь собачья! просто учится надо, вот и все.

← →
Style (2003-03-14 11:04) [180]

KSergey© >> Просто некоторые ставят себя очень умными..
И только твердят что тебе учится надо..

Учится всегда надо.. И учится большинство на своих ошибках.

Самая главная моя ошибка то что я тему ветки не так назвал
После чего попер сплошной негатив!

← →
REA (2003-03-14 11:24) [181]

Проблемы такого плана могут быть:
Paradox иногда при сбоях не убивает файлы блокировки lck, которые могут мешать работе.
Windows увеличивает до беспредела файловый кэш при частой записи, если его не ограничить. А в XP его не ограничить.
Таблицы иногда портятся при сбоях, даже если local cache = true и делать Flush.
Ну и вообще windows не RealTimeOS - какие-то задачи по управлению на нее лучше не вешать.

← →
Style (2003-03-14 14:08) [182]

Paradox иногда при сбоях не убивает файлы блокировки lck>>
Их легко убить перед запуском программы.

>>Таблицы иногда портятся при сбоях, даже если local cache = true и делать Flush.>>
От конкретных глюков не одна база не защищена.

>>Windows увеличивает до беспредела файловый кэш при частой записи, если его не ограничить. А в XP его не ограничить.
Работать будем на 98

>>Ну и вообще windows не RealTimeOS - какие-то задачи по управлению на нее лучше не вешать.>>>

Управление не очень существенное. Программа это инструмент есть человек который, посмотрит, исправит.

Вообще-то не одна база данных не подойдет для этой задачи...
Нужен только своп! Только файл и все...

← →
Anatoly Podgoretsky (2003-03-14 14:20) [183]

Style (14.03.03 11:04)
Кто же это учится на чужих ошибках, учатся на своих

← →
Style (2003-03-14 14:55) [184]

Anatoly Podgoretsky ©>>>
А я что написал :)

Ну согласитесь наконец что
БД и SQL это не для такой задачи. (если оставить компьютер и Windows)

← →
icWasya (2003-03-14 15:22) [185]

ну так нафига база данных вообще??

← →
Style (2003-03-14 16:18) [186]

ну так нафига база данных вообще??>>

Без быза Потеряем быстрый поиск по базе (для создания отчетов)
ПОтому я и работал с Таблицами напрямую.

Конечно нужно взять Кнута и написать все свое.
для этой задачки. Совой поиск в файле сравнения участков времени и изменнеии значений.

Напишу компонент покажу...

← →
AndrewK74 (2003-03-14 16:30) [187]

Сдается мне, что проблема чисто организационная. Вариант решения: сэкономив на датчике, нанять человека с понятием. Тогда и ядреной безопасности прибавится.

← →
Style (2003-03-17 07:59) [188]

>> AndrewK74: человека с понятием.
Это с каким таким понятием!

-- Вот в выходные написал свой форматик.
посмотрите плиз www.sands.nm.ru/swaptable.zip

Наверное для такого рода задач. Это и есть оптимальное решение
Конечно это только локальный своп (не для пользования в сети). Хотя я думаю можно написать и свой сервис.
Код еще сыроват и в компонент его даже вставлять не стал.
Если уж и делать компонент, то наверное лучше наследоваться от TDataSet.
Как вы думаете???

← →
Style (2003-03-17 09:44) [189]

>>TSwapTable

Да и еще вопрос? Наверное лучше создавать Индекс в виде Бинарного дерева. Как вы думаете стоит ли его хранить в оперативной памяти. Или работать с отдельным файлом.??

← →
Andrey (2003-03-17 12:19) [190]

Уф... недумал что дочитаю...

>Работать будем на 98
Ню-ню... Строго говоря операционная система с жесткой многозадачностью (когда основной процесс по таймеру или другим способом принудительно прерывает пользовательские процессы) каковой является MS Windows вообще и Win98 в частности, вообще неприминима для задач требующих обработки данных в реальном времени... ню-ню...

Ладно попытаюсь забыть о словах "ядерная безопасность" и подойти как к задаче организации хранения-обновления-чтения данных.

Если так уж критична скорость, то
1. Весь файл БД должен хранится в памяти ОЗУ.
2. Своп (запись на диск) нужно делать только для измененных участков и только в конце э..абстрактной транзакции (когда все данные полученые от датчика обработаны и записаны в выделеный участок памяти). Возможно в паралельном потоке.
3. Непонятно зачем тебе нужны индексы? Ведь структура БД статична и все данные хранятся в строго определенных местах и следовательно доступ к определенному значению можно получить без использования индекса, просто вычислив смещение элемента относительно э..допустим начала файла БД.
Скорость будет иправду офигительная (не по микросекундам, а по тактам считать прийдется :)). Конечно если нормально реализовать.

Хранение данных: ну это понятно
integer - 4 байта
double - 8 байт
и т.д.

P.S. Блин, если уж люди с такой квалификацией пишут системы "контроля ядерной безопасности"... иправду не все впорядке в у руководства головах...

P.P.S. А как ты "в 16 лет устоился на работу программистом инженером..."? Случаем не "волосатая лапа" тебя продвинула?

> REA
> Для более требовательных к надежности систем лучше использовать
> другие средства, хотя конечно можно поставить 10 компьютеров
> с windows - один да выживет в каждый момент времени.

Так операторы по сети игратся начнут и всю сеть завесят :) Хотя это больше организационный вопрос.

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

>>1. Весь файл БД должен хранится в памяти ОЗУ.>
--Что подразумеваешь под словом БД???
Какую базу данных ты собрался применить
для данной задачи??

>>3. Непонятно зачем тебе нужны индексы? Ведь структура БД статична и все данные хранятся в строго определенных местах...
--Если речь идет о БД. то я их и не использую!
Я написал свой Swap посмотри:
www.sands.nm.ru/swaptable.zip
А индексы я хочу создать в нем чтобы быстро искать нужные значения. Это нужно для создания отчетов...

<<>>>Работать будем на 98
Можно поставить и WinNT.
Только нужно добится от него соответсвующих Привелегий для работы с ISA! Наверное с NT будет несколько надежней.

← →
Andrey (2003-03-17 13:37) [192]

>Style
>Что подразумеваешь под словом БД???
Пардон, неуточнил. В данном конкретном случае под БД я понимаю файл с данными структурированый особым образом.
Тоесть просто файл данные в котором хранятся в твоем формате.

Насколько я понял. Во всех таблицах будет строго определенное количество полей и записей. Тоесть каждая таблица по сути фиксированая матрица. В главной таблице 10000 записей. По заполнении таблици происходит переход на первую запись и на место первой пишется 10001 запись, на 2 пишется 10002 и т.д.
Поправь меня если я нетак понял.

Посмотрел swaptable.zip... хм... почти беру свои слова назад о квалификации. Но IMHO всетаки настолько серьезными проэктами должны заниматся более опытные люди. Опытные не в области физики, а именно в области написания ПО для RealTime работы.

swaptable это почти то о чем я говорил, но я предпологаю что изначально проще сделать фиксированое количество записей в таблицах. Насколько я понял >10000 в главной таблице непонадобится. Хотя конечно если должен быть не фиксированый размер, то твой swaptable (после некоторого тестирования и доводки) вполне удовлетворит такие требования. Я глубоко не вглядывался, но на первый взгляд вполне качественно IMHO

>Да и еще вопрос? Наверное лучше создавать Индекс в виде
>Бинарного дерева. Как вы думаете стоит ли его хранить в
>оперативной памяти
Лучше. Для эксперемента можно попробовать через Move сместить на 1 байт 10Mb-ный сегмент. Именно так и работает TList.
Но заморочаешся при вставке/изменении/удалении записей. Работа с деревьями никогда небыла простой. Теперь стоит ли его хранить в оперативной памяти? Если объем памяти позволяет то стоит, если не полностью то хотябы верхние страници верхних уровней.

← →
Satirus (2003-03-17 13:42) [193]

предлагаю перенести эту ветку назад в "Базы данных".
Как грицца, потрепались и хватить.

← →
Style (2003-03-17 13:55) [194]

Andrey © >> Спасибо наконец за теплые слова.. Я конечно не проффи. Но кое-что делать могу :)
Да в моем случае будет строго фиксированный размер и строго фиксированное кол-во записей..

Сам SwapTable можно описать так

Через каждую запись стоит некий Separator
Соответственно при чтени данных CheckSeparator если байт не равен нужному выдаем Exception о поврежденнии Swap!

Структура записей такая

1. Состояние
2. Предыдущая удаленная
3. Seek следующей записи
4. Seek текущей записи
5. Seek предыдущей записи

сооветственно можно легко воостановить поврежденные данные!

Допустим своп содержит 10000 записей.. то сколько бы я неудалял их. Новые записи он будет вставлять на место удаленных. Соответственно файл не будет расти если не превысить 10000 строк.

Что касается Real-Time программ.
Программа постоянно посылает импульсы на аппаратное устройство.
Если компьютер повис. то устройство включает тревогу через N - установленное время..

Еще немного про SwapTable..
Конечно наверное я еще добавлю свойство у каждому полю... IndexType -
0 - NoIndex
1 - RamIndex
2 - FileIndex

Если не получится с деревьями попробую хотябы дехометрический поиск.. (Я начал делать TMemIndex)

Если будут индексы можно будет написать даже свой интепретатор SQL :)

Соответсвенно желательно сделать компонент TDataSet"ом

А что касается всех моих опытов с Парадоксом . 8) Да выбора у меня не было.. Я просто объснить нормально немогу а меня грязью залили всем форумом!

← →
Style (2003-03-17 13:58) [195]

>> Предлагаю создать новую ветку TSwapTable :)

← →
Style (2003-03-17 14:23) [196]

Может еще чего посоветуете :) А то мы с такими темпами до 200 не дойдем :)))

← →
Andrey (2003-03-17 14:48) [197]

>А что касается всех моих опытов с Парадоксом
:) между прочим (сейчас скажу непроверенную информацию) в некоторых банках в качестве СУБД используется тотже Paradox или DBase исключительно из соображений надежности :) А архитектура такова: несколько самописных модулей на С (отлаженых до предела) для высокоскоростной работы с индексами и таблицами (нижний, физический уровень), большое количесво процедур работающих через эти функции с основной базой (средний, логический уровень), и машина (группа машин) принимающих сигналы (имя процедуры с параметрами) от удаленных филиалов (верхний, интерфейсный уровень)... Это все очень приближенно... так, что-то я отвлекся :)

>....можно легко воостановить поврежденные данные!
Мне пока неочень понятно как можно будет легко востановить данные. Даже если понеряется всего 1 запись, она потеряется окончательно. Предпологаю, отказатся от попыток востановить данные.
Так же для проверки целосности записи в заголовок записи можно внести некую контрольную сумму и при чтении проверять. IMHO это более надежный способ чем CheckSeparator.

> Допустим своп содержит 10000 записей.. то сколько бы я неудалял
> их. Новые записи он будет вставлять на место удаленных.
> Соответственно файл не будет расти если не превысить 10000
> строк.

Тоесть теоретически он может перерости 10000. значит
1. в памяти нужно держать индексы
2. при изменении/добавлении/удалении данных

2.1 считывать изменяемые страници с данными
2.2 изменять данные в таблицах и индексах
2.3 записывать данные на диск (наиболее критические сбои происходят в этот момент)
2.3.1 в заголовок БД записать условный идентификатор обозначающий, что "транзакция #<такой-то> собирается изменить такие-то записи в таких-то таблицах"
2.3.2 поочередно сбрасывать на диск измененные страници (в заголовке записи (и в таблице и в индексе) должен быть идентификатор транцакции которая изменяла эту запись последней)
2.4 Закончена обработка, жду сигнала для перехода на 2.1

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

← →
Style (2003-03-17 15:26) [198]

>>>IMHO это более надежный способ чем CheckSeparator>>
Можно действительно ввести контрольную сумму. Но сумирование займет тоже определенное время чего бы не хотелось.

Наверное достаточно будет CheckSeparator. Хотя контрольную сумму на для RecordHeader можно поставить.

>>При сбое вовремя записи, при следующем запуске программы, можно будет определить какие записи были модифицированы, а какие нет последней транзакцией. >>
Вот это интересная идея..

Наверное лучше написать процедуру Restore которую в случае необходимости пользователь будет вызывать. Сделать пункт Восстановление БД вывести список сомнительных записей...

Сейчас есть TList -> SeeksList - в котором я храню структуры TRecordHeader. Но паралельно хотелось бы создать и индексы Значений.
Ну это всеже будет лучше чем использовать какую-нибудь БД! Это будет быстрее! Да и информацию в своем формате будет проще восстановить!

← →
Soft (2003-03-17 15:28) [199]

>Access и ядерная безопасность.... мда...
Soft, вы никогда не видели в Ваших программах в Access приколов, когда в вычисляемых полях, где использовались только встроенные функции Access, вместо результата выдается #Ошибка? или #Имя?, если закрыть базу, потом опять открыть - все ОК? Или перестают работать запросы, с которыми было все ОК, и лечится все вышеописанным способом? Благо, база просто для облегчения труда нескольких людей, и в случае чего-нить нехорошего миру ничего не угрожает...

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

А друг занимается автоматизацие рассылки почты. Так что используйте ICQ и email, надежная доставка информации:)

← →
Andrey (2003-03-17 16:02) [200]

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

В сравнении с операцией чтения/записи это меньше чем пустяк. Я вообще предпологаю, что для тоего проэкта работа с диском будет занимать ~95% всего времени обработки цикла.
Кстати по поводу времени. Есть такие хитрые IDE-контроллеры которые чтение/запись берут на себя, а не нагружают процессор. Это есть очень гуд т.к. если планируется, что в будущем алгоритмы работы с данными усложнятся (например захочешь хранить записи в упакованом виде) это даст определенный резерв скорости процессорам. Всеравно быстрее чтения/записи ничего неполучится.

> Наверное лучше написать процедуру Restore которую в случае
> необходимости пользователь будет вызывать. Сделать пункт
> Восстановление БД вывести список сомнительных записей...

Вот в упор непонимаю как пользователь будет их востанавливать? Где он возьмет утерянные данные. В том же IB есть понятие версионности с которым можно еще как-то работать (запись имеет несколько версий), но как здесь, одна версия записи и она или верная или не верная, все!

> хотелось бы создать и индексы Значений

Если этого требует задача (т.к. предпологаются отчеты скорее всего требует), значит надо, если не требует нет смысла загромождать проэкт (чем меньше проэкт, тем легче в нем ориентироватся и искать баги).
Хотя конечно ради чисто академического интереса можно, но IMHO не в этом проэкте :) А если такое уже будет, можно будет подумать про организацию собственной СУБД поддерживающей SQL :) Глядишь еще и Oracle с рынка выбьешь :)

> Ну это всеже будет лучше чем использовать какую-нибудь БД!
> Это будет быстрее! Да и информацию в своем формате будет
> проще восстановить!

Скорее всего и лучше и быстрее, но с востановлением информации опять непонимаю...

>Satirus (17.03.03 13:42)
Может быть и пора.

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