Есть ли альтернатива Paradox y?

← →
vlad2 (2007-01-16 14:39) [0]

Очень насущная для нас проблема. несколько лет работает сложный вычислительный комплекс на основе СУБД Paradox + BDE. В течение года становится всё больше глюков, работа всё больше становится ненадёжной. Консультации и анализ показал, что проблема в ненадёжности давно уже неподдерживаемого Парадокса.

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

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

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

← →
clickmaker © (2007-01-16 14:45) [1]

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

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

← →
Sergey13 © (2007-01-16 14:49) [2]

> Есть ли альтернатива Paradox"y?

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

← →
sniknik © (2007-01-16 14:51) [3]

> например, тест с использованием Oracle + компоненты прямого доступа работает до 30 раз медленнее,
> чем тот же тест на Paradox + BDE
клиент сервер <> файл сервер, логика разная. а тесты написанные под одну логик гарантированно провалятся на другой.

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

← →
sniknik © (2007-01-16 14:52) [4]

> Оракл маст дай. 8-)
;о))) согласен, но только не потому что тесты на сравнение с парадоксом "провалил", будем объективны...

← →
Sergey13 © (2007-01-16 15:01) [5]

> [4] sniknik © (16.01.07 14:52)

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

← →
Виталий Панасенко © (2007-01-16 16:06) [6]

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

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

← →
Виталий Панасенко © (2007-01-16 16:14) [7]

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

← →
Prohodil Mimo © (2007-01-16 16:20) [8]

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

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

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

← →
Виталий Панасенко © (2007-01-16 16:32) [9]

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

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

← →
evvcom © (2007-01-16 16:36) [10]

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

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

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

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

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

← →
Prohodil Mimo © (2007-01-16 17:16) [12]

это колобок :о)

← →
ANB © (2007-01-16 17:27) [13]

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

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

← →
Виталий Панасенко © (2007-01-16 17:42) [14]

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

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

← →
evvcom © (2007-01-16 17:45) [15]

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

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

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

:)))

← →
vlad2 (2007-01-16 18:28) [16]

Спасибо попытавшимся ответить.

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, конечно же, не использовался.

← →
vlad-mal © (2007-01-16 21:28) [17]

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

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

← →
unknown © (2007-01-17 02:22) [18]

> vlad2 (16.01.07 18:28) [16]

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

← →
Виталий Панасенко © (2007-01-17 10:01) [19]

Можете попробовать ADO+MSAccess
Я не повторяюсь.. Я не повторяюсь.. Я не повторяюсь..
> Виталий Панасенко © (16.01.07 16:06) [6]

← →
Виталий Панасенко © (2007-01-17 10:18) [20]

А вообще, я так и не понял смысл задачи...

← →
Sergey13 © (2007-01-17 10:22) [21]

> [20] Виталий Панасенко © (17.01.07 10:18)

Да программист им нужен, способный перевести прикладу с файл-сервера на клиент-сервер.

← →
vlad2 (2007-01-17 12:38) [22]

Спасибо участникам обсуждения.
В своём постинге (vlad2 (16.01.07 18:28) [16]) я попытался на примере показать проблему. Смысл моего вопроса во в чём: существует ли СУБД, работающая так же как Парадокс и отличающаяся от него только высокой надёжностью? Т.е. можно ли просто заменить Парадокс на другую СУБД, не меняя идеологии (логики) построения программного комплекса? Если это невозможно, то, конечно, придётся переходить на клиент-серверную базу (например, Оракл), но это потребует по сути перепроектирования нашего комплекса, т.е изменения идеологии и логики работы, что повлечёт громадные трудовые и временные затраты из-за большого объёма задач.
Наши специалисты (не самые плохие :) и знакомые с требованиями к нашим задачам) говорят, что ADO+MSAccess нас не спасёт.

← →
evvcom © (2007-01-17 12:53) [23]

> [22] vlad2 (17.01.07 12:38)
> работающая так же как Парадокс

Тогда сначала объясни как работает Парадокс в твоем понимании. Но, думаю, в любом случае ответ будет НЕТ.

← →
Сергей М. © (2007-01-17 13:10) [24]

> vlad2

Ни одна файл-серверная СУБД в условиях многопользовательского доступа не даст гарантий 100%-й надежности, особенно если БД находится не на полноценном сетевом файловом сервере.

← →
sniknik © (2007-01-17 13:13) [25]

> что ADO+MSAccess нас не спасёт.
это самое близкое по идеологии (есть режим аналогичный файл серверному), очень надежное, но с ограничением на размер.

т.е. делаем вывод, вас ничто не спасет... ну, т.к. переход "...повлечёт громадные трудовые и временные затраты..."

← →
DrPass © (2007-01-17 13:18) [26]

> Если это невозможно, то, конечно, придётся переходить на
> клиент-серверную базу

Придется, увы

← →
Sergey13 © (2007-01-17 13:18) [27]

> [22] vlad2 (17.01.07 12:38)

Твоя основная проблема это

> Работают 2-3 пользователя одновременно.

Это значит сеть и конфликты пользователей. Любая замена на аналогичную файл-серверную СУБД сможет лишь отодвинуть решение ваших проблем. Тут многие (очень авторитетные, например sniknik) говорил, что тот-же Аксес с успехом держит до 5 одновременных сессий. Но развивать это все равно не имеет смысла, ИМХО.
Если просто подсунуть (например) ФБ-сервер через БДЕ вместо парадокса, уже будет как минимум надежность. Я не думаю, что сетевые пользователи много проиграют в производительности. Но зато возможна достаточно быстрая адаптация к новой СУБД без значительных переделок приложения. После можно уже настраивать узкие места переделкой логики.
Конечно этот путь все равно здорово попахиает времянкой (уже использование БДЕ чего стоит). Но может быть и стоит попробовать.
Хотя я бы наверное стал полностью переделывать.

← →
tesseract © (2007-01-17 13:34) [28]

> существует ли СУБД, работающая так же как Парадокс и отличающаяся
> от него только высокой надёжностью?

http://www.codebase.com/products/windows/

← →
vlad2 (2007-01-17 13:41) [29]

evvcom © (17.01.07 12:53) [23]
> Тогда сначала объясни как работает Парадокс
Быстро , гораздо быстрее Оракла на живой таблице (см. vlad2 (16.01.07 18:28) [16]). Почему он так работает, не знаю, не уверен, что нужно так глубоко в это вникать, если не собираешься сам писать СУБД. Хотелось бы найти готовое решение типа Парадокса.

> с успехом держит до 5 одновременных сессий
5 сессий на стресс тестировании, таком, что никак в реальных условиях достичь не возможно.
в реальности нагрузки обычно поменьше, у меня программа работает и с 16 (менеджеры уроды расстарались), и вроде претензий нет (я правда заранее открестился, типа если рассчитано на 3... то выше на ваш страх и риск, но они бы все одно приперлись если бы случилось чего)

хотя я то как раз с аксессом работаю в нормальном(имхо ;) клиент серверном режиме (не очень много логики тогда стыковать для mssql)... как оно было бы еслибы делалось аналогом файл серв. х.з.

> http://www.codebase.com/products/windows/
чтото я сомневаюсь что у них логика аналогична работе с парадоксом, скорее она клиент серверная и для сети и для локального использования (как и у аксесс в нормальном режиме, или у персонал файребирд) а это значит, что не подойдет оно ему...

> чтото я сомневаюсь что у них логика аналогична работе с
> парадоксом

У ней таблицы плоские. Т.Е чем-то логика да похожа.

> [31] tesseract © (17.01.07 13:48)

> У ней таблицы плоские.

А у кого они объемные? Я только у Оракла знаю такую возможность.

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

не совсем ясна цель, но в нормальных СУБД это делается одним запросом. Уровень изоляции задается отдельно при необходимости. При настроенных индексах и записях ~ 10-50К работает весьма шустро.

> А у кого они объемные? Я только у Оракла знаю такую возможность.

Имеються в виду *.dbf , а не одним файлом. В некоторых случаях побыстрее однофайловых.

← →
vlad2 (2007-01-17 14:23) [35]

sniknik © (17.01.07 13:13) [25]

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

А какие в MSAccess ограничения на размер?
Обеспечивается ли там совместный доступ автоматически (как в Оракле), чтобы я не заботился об этом при программировании?
По скорости ADO+MSAccess насколько будет (или не будет) уступать BDE+Paradox?

> [35] vlad2 (17.01.07 14:23)
> По скорости ADO+MSAccess насколько будет (или не будет)
> уступать BDE+Paradox?
Бывает, что горбатый запорожец легко обходит 600-го мерина. Особенно если последний припаркован. 8-)

> Быстро , гораздо быстрее Оракла на живой таблице

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

и что понимается под "перестройкой" таблиц

> Обеспечивается ли там совместный доступ автоматически (как
> в Оракле), чтобы я не заботился об этом при программировании?
>

о совместном доступе надо всегда заботиться :)

> Смысл моего вопроса во в чём: существует ли СУБД, работающая
> так же как Парадокс и отличающаяся от него только высокой
> надёжностью? Т.е. можно ли просто заменить Парадокс на другую
> СУБД, не меняя идеологии (логики) построения программного
> комплекса?

Ответ - нет. Нет такой СУБД. Но вот на вторую часть вопроса ответ может быть положительным, с помошью писания сервера приложений. Расплата, как обычно, объемом оперативки. Лучше переделать :)

Есть ли альтернатива Paradox y? Найти похожие ветки