| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C++ Builder > Table vs Query |
| Автор: petlyura 28.5.2008, 10:54 |
| Здравствуйте, форумчане! Задача такова. Идет технологический процесс, часто меняются значения параметров. Все изменения необходимо архивировать. К примеру, 1500-2000 параметров за секунду. То есть надо добавить в таблицу локальной БД пару тысяч записей (причем, не за 1 секунду, а гораздо быстрее, так как есть еще приличная визуализация). Причем, мое мнение, не записывать их на диск по отдельности, а сразу пулом (к примеру, 32к записей). Что использовать для этого Table или Query? В книге Архангельского написано: "..при работе с локальными базами данных эффективность Query заметно ниже эффективности Table. Замедление вычислений получается весьма ощутимым." Да, и хотел бы получить дельные советы от Вас, форумчане, как мне принципиально построить этот процесс (технологию) архивирования данных? С помощью промежуточных (виртульных) таблиц, которые потом сливать в реальные? П.С. Использую ЛБД Paradox7 Заранее благодарю |
| Автор: mrbrooks 28.5.2008, 11:08 |
| А что ты собираешься сохранять - дискреты? |
| Автор: petlyura 28.5.2008, 11:49 | ||
И дискретные, и аналоговые. |
| Автор: mrbrooks 28.5.2008, 12:05 |
| если Яковлевич пишет что TTable для локальной БД кайфовей поверим ему на слово. Тебе же предлагаю дискреты упаковывать в слова стояния - так будет рациональней. Считай в одно поле ты запишешь 16 дискретов супротив одного. |
| Автор: petlyura 28.5.2008, 12:29 | ||||
Так и делаю. Меня интересует, не захлебнется ли машина на таком количестве записей? Каждые новые сутки лучше новую БД создавать? А то много сильно записей будет |
| Автор: mrbrooks 28.5.2008, 12:41 |
| Конечно каждые сутки создавай новую таблицу. В этом плане конечно TQuery эротичней. И потом еще не плохо было бы определиться как долго ты ее будешь на харде. За месяц знаешь ли хард может и забиться под завязку. Ты данные сливаешь каким образом - через клиента или по како-му нибудь промышленному протоколу? |
| Автор: petlyura 28.5.2008, 14:39 | ||
Углублюсь еще в проект. До этого я архивировал в файлы (1 файл - 1 сутки) информацию потоком байтов (очень быстро, но сердито в плане извлечения архивных данных). Но большое время извлечения архивных данных заставило меня пересматривать стратегию архивирования. Т.е. наличие индексов в БД, возможность вытянуть информацию по имени сигналов и по времени с помощью несложного запроса - все это натолкнуло меня на мысль поработать с БД. Данные тяну своим верхним уровнем с OPC-клиента. А теперь, почему решил обратиться к форумчанам: 1) боюсь машина захлебнется от записи данных в БД. Хотя надо пробовать и смотреть. Может, кто-то предложит, подскажет, чему уделить внимание? построению индексов, записи сразу в файл большого куска данных (так я делал с обыкновенным файлом)? Еще чему-нибудь? 2) нет опыта работы с БД Paradox7, с этой технологией BDE (с БД работал только с применением технологии ADO.NET). Ну а тут надо под Builder 6 и скорее всего, Paradox7 (т.к. ЛБД). Поэтому думаю, что кто-то подскажет типа, бери Table (Query), создавай еще временный Table... PS С файлами решал проблему заполнения харда след.образом, проверял место на диске, и если оставалось чуток, то удалял самый старый архив (все программно) |
| Автор: mrbrooks 28.5.2008, 15:28 |
| По поводу что машина захлебнется. Пиши значения по изменению. Для этого вводят степень чувствительности для аналогов и изменение по дискретам. Никто не валит такой объем данных как ты гришь 1500 - 2000 значений менее чем в секунду. |
| Автор: petlyura 28.5.2008, 15:55 | ||
Все верно. В реальности до 40 изменений в секунду. Есть и апертура всех сигналов. Пишу естественно по изменению. Но!!! У меня есть демо-режим, где можно экспериментировать без реальных тех.процессов. Аналоговые представлены синусоидой, естественно, постоянно меняются. Так вот в таком случае, доходит до 2000 сигналов в сек. Ну, а для меня, если в таких условиях система выдерживает (пока что так и есть), то все ГУД! Значит, выдержит и на реальных тех.процессах, пока оператор будет в сапера играть или порнушку посматривать... mrbrooks, так что Table vs Query посоветуете. И возможно ли темпово создавать Table без привязки к реальной таблице, и из него заливать в табл. БД. Хотя наверно лучше устанавливать CashedUpdates в true и далее ApplyUpdates и CommitUpdates... Ну а если Table привязана к таблице событий, то к концу суток понадобится слишком много оперативки, чтоб удерживать Table в памяти, а мне это не надо. Короче, что надо сделать (накидать на форму), чтобы таблица событий не занимала оперативки, но иногда можно было дописывать в эту таблицу новые события. Может, временный Table (хранит "свежачок", пока Query не сгрузит в табл.) и с помощью Query дописывать в таблицу "свежачок" из этой Table? И возможно ли в StringGrid выгрузит данные архива? Т.е. определенные сигналы за опр. время (все задается оператором). И что для этого использовать Table vs Query? |
| Автор: mrbrooks 28.5.2008, 18:16 |
| Я бы остановился на TQuery. На мой взгляд это оптимальней при работе с большим колличеством данных. Главное имхо как ты понимаешь для записи в БД не должно быть ни какой визуализации. То есть что бы не было желание посмотреть через DBGrid как оно там добавляется в бд |