Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Есть ли альтернатива Paradox'y? [D7, Paradox]

Страницы: < 1 2 3
vlad2 © (2007-01-16 14:39:00)
Очень насущная для нас проблема. несколько лет работает сложный вычислительный комплекс на основе СУБД Paradox + BDE. В течение года становится всё больше глюков, работа всё больше становится ненадёжной. Консультации и анализ показал, что проблема в ненадёжности давно уже неподдерживаемого Парадокса.

Условия работы: несколько таблиц уже по 300-500 тыс.записей и множество небольшых (по нескольку тыс. записей) таблиц. Работают 2-3 пользователя одновременно. Работа заключается в интенсивном поискенужных записей (по значению полей) в упорядоченныхпо ключу таблицах, навигация по ним и модификацияэтих упорядоченных таблиц. Используются компоненты TQuery и TTable (здесь есть очень удобные и эффективные методы, такие, например, как FindNearest и BatchMove). Paradox + BDE обеспечивают высокую, устраивающую нас - это очень важно - производительность. Проблема только в нестабильной и ненадёжной работе Парадокса, что стало уже критичным.

К большому сожалению, переход на клиент-серверные СУБД (например, Oracle) нас не спасёт, т.к. при всей супернадёжности работы и "бесплатного" обеспечения совместного доступа, они не обеспечивают необходимого быстродействия в условиях нашей конкретной работы (например, тест с использованием Oracle + компоненты прямого доступа работает до 30 раз медленнее, чем тот же тест на Paradox + BDE, конечно при идентичных начальных условиях и полном совпадении результатов в обоих случаях) из-за отсутствия поддержки двунаправленных курсоров, поэтому на каждый "чих" таблица, по определению упорядочивается заново.

Вопрос такой (самый тяжёлый): существуют ли СУБД, подобные Парадоксу с набором удобных методов и компонент, не уступающие ему по быстродействию, но надёжно работающие в условиях совметного (для 2-5 пользователей) доступа с учётом конкретной специфики нашей работы, кратко описанной во 2 абзаце? Есть ли сейчас надёжные сетевые СУБД под Windows?
Может быть, кто-то сталкивался с такими проблемами и с подобной (скорее, нетрадиционной для баз данных) спецификой работы?
Спасибо.

unknown (2007-01-17 02:22:00) [41]

> vlad2 (16.01.07 18:28) [16]

DDL и тексты запросов приведите. Очень любопытно.

vlad-mal (2007-01-16 21:28:00) [42]
Переход на FireBird "просто так" ничего не даст.
Если идет интенсивное обновление данных в многопользовательской среде, то можно схлопотать такие "глюки" - мало не покажется.
А если Вы выполняете частое создание/удаление таблиц в процессе работы - то тут вообще полный атас может приключиться, вплоть до разрушения базы.
А понятие "положение записи в таблице" в FireBird вообще нет (и по науке не должно быть).
Насчет чтения из таблички одновременно с записью - FireBird под это отлично заточен.

Но без понимания принципов работы FireBird скорее всего может получиться фигня.

vlad2 (2007-01-16 18:28:00) [43]
Спасибо попытавшимся ответить.

clickmaker © (16.01.07 14:45) [1]
> да ну.. правда, что ли?
Увы, чистая правда :)
Вот маленький и самый простой частный пример работы программы. Из таблицы вырезается фрагмент с учётом значений каких-то полей (select ... where ...), полученная таблица (вырезанный фрагмент) упорядочивается (order by ...), а потом просто выбираются записи, скажем, по номерам (положению в этой таблице), например, 10-я, 11-я, 12-я, ... Но в промежутках между этими выборками эта же таблица модифицируется(добавление, удаление, редакция записей). Понятно, что результат выборки может отличаться от того, что был бы в случае неизменной таблицы. Парадокс очень легко, просто и быстро проделывает эти манипуляции на живойтаблице. Ораклу же нужно каждый разперестраивать эту таблицу, чтобы взялась нужная запись. В этом одна из проблем клиент-серверных СУБД применительно к нашей конкретной задаче.

sniknik © (16.01.07 14:51) [3]
> клиент сервер <> файл сервер, логика разная. а тесты написанные под одну логик гарантированно провалятся на другой.
> p.s. вам нужен программист.
Философски вы правы. Программисты у нас есть, но надо понять, можно ли перейти на другую, надёжную СУБД "малой кровью", не меняя логики, - слишкоб большой объём уже созданных и заточенных под Парадокс программ.

Виталий Панасенко ©
На Оракле никакой FindNearest вместо select, конечно же, не использовался.

evvcom (2007-01-16 17:45:00) [44]
> [13] ANB © (16.01.07 17:27)
> Эта работа выполняется на оракле за милисекунды

Это как написать! А то ж видишь автор уже писал:

> [0] vlad2 (16.01.07 14:39)
> тест с использованием Oracle + компоненты прямого доступа
> работает до 30 раз медленнее, чем тот же тест на Paradox
> + BDE

:)))

Виталий Панасенко (2007-01-16 17:42:00) [45]

> Prohodil Mimo © (16.01.07 17:16) [12]
> это колобок :о)

Ты тоже заметил ?!..:-)

ANB (2007-01-16 17:27:00) [46]

> Работа заключается в интенсивном поиске нужных записей (по
> значению полей) в упорядоченных по ключу таблицах, навигация
> по ним и модификация этих упорядоченных таблиц.

Эта работа выполняется на оракле за милисекунды, причем можно написать одним SQL оператором.
А на таких микро-объемах вообще все летать будет.

Prohodil Mimo (2007-01-16 17:16:00) [47]
это колобок :о)

Виталий Панасенко (2007-01-16 17:00:00) [48]

> evvcom © (16.01.07 16:36) [10]
> > [9] Виталий Панасенко © (16.01.07 16:32)
> > Они (руки) уже пишут по другому...:-))
>
> У них, наверное, голова выросла? :))

Голова-не голова.. Самому тяжело судить. Но в зеркале вижу какой-то нарост на шее сверху...Глаза, уши, нос и прочее..:-))

evvcom (2007-01-16 16:36:00) [49]
> [9] Виталий Панасенко © (16.01.07 16:32)
> Они (руки) уже пишут по другому...:-))

У них, наверное, голова выросла? :))

Виталий Панасенко (2007-01-16 16:32:00) [50]

> Prohodil Mimo © (16.01.07 16:20) [8]
> Виталий Панасенко © (07.01.16 16:14) [7]
> Да нафиг он такой нужен, если в тестовой таблице из 200000
> записей ищет по ключу (Table.FindKey(...)) последние записи
> минут по надцать(покурить можно было(это я тогда еще курил)).
> ..
>
> Нафиг такие руки, которые так пишут.
>
> А вообще FB, намного шустрее и стабильнее Paradoxа, особенно
> если на пару с HP.

Это было лет 7-8 назад. Они (руки) уже пишут по другому...:-))

Prohodil Mimo (2007-01-16 16:20:00) [51]
Виталий Панасенко © (07.01.16 16:14) [7]
Да нафиг он такой нужен, если в тестовой таблице из 200000 записей ищет по ключу (Table.FindKey(...)) последние записи минут по надцать(покурить можно было(это я тогда еще курил))...

Нафиг такие руки, которые так пишут.

А вообще FB, намного шустрее и стабильнее Paradoxа, особенно если на пару с HP.

Виталий Панасенко (2007-01-16 16:14:00) [52]
Я сам, когда лет 7-8 назад "наткнулся" на InterBase был очень раздосадован: писали, что "производительный, надежный!" Да нафиг он такой нужен, если в тестовой таблице из 200000 записей ищет по ключу (Table.FindKey(...)) последние записи минут по надцать(покурить можно было(это я тогда еще курил))... Пока не допер, что select ... from table where key=key_value ищется так же шустро, как и Table.FindKey() для Paradox.. Грубо описал, но где-то так дело обстояло...

Виталий Панасенко (2007-01-16 16:06:00) [53]

> Работа заключается в интенсивном поиске нужных записей (по
> значению полей) в упорядоченных по ключу таблицах, навигация
> по ним и модификация этих упорядоченных таблиц. Используются
> компоненты TQuery и TTable (здесь есть очень удобные и эффективные
> методы, такие, например, как FindNearest и BatchMove). Paradox
> + BDE обеспечивают высокую, устраивающую нас - это очень
> важно - производительность. Проблема только в нестабильной
> и ненадёжной работе Парадокса, что стало уже критичным.

Небось и на Оракле использовали FindNearest вместо select ... from where УСЛОВИЕ...
Можете попробовать ADO+MSAccess

Sergey13 (2007-01-16 15:01:00) [54]
> [4] sniknik © (16.01.07 14:52)

Да ты, помню, расказывал как то про свои эксперименты. Но это тоже не показатель, согласись.

sniknik (2007-01-16 14:52:00) [55]
> Оракл маст дай. 8-)
;о))) согласен, но только не потому что тесты на сравнение с парадоксом "провалил", будем объективны...

sniknik (2007-01-16 14:51:00) [56]
> например, тест с использованием Oracle + компоненты прямого доступа работает до 30 раз медленнее,
> чем тот же тест на Paradox + BDE
клиент сервер <> файл сервер, логика разная. а тесты написанные под одну логик гарантированно провалятся на другой.

p.s. вам нужен программист.

Sergey13 (2007-01-16 14:49:00) [57]
> Есть ли альтернатива Paradox'y?

Откуда. Что ты. Это вершина человеческой мысли. Оракл маст дай. 8-)

clickmaker (2007-01-16 14:45:00) [58]

> из-за отсутствия поддержки двунаправленных курсоров, поэтому
> на каждый "чих" таблица, по определению упорядочивается
> заново

да ну.. правда, что ли?

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »