Мастера 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?
Может быть, кто-то сталкивался с такими проблемами и с подобной (скорее, нетрадиционной для баз данных) спецификой работы?
Спасибо.

Sergey13 (2007-01-19 15:09:00) [1]
> [57] Anatoly Podgoretsky © (19.01.07 14:42)

Для 2-3 пользователей шибко круто, ИМХО. ИБП конечно нужен и выделенная машина тоже очень желательна. Но можно и на простом железе начинать.
Если же возьмут Оракл (раз пробовали уже), то там зеркалирование вообще мало что дает, лучше дополнительный диск иметь.

Anatoly Podgoretsky (2007-01-19 14:42:00) [2]

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

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

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

Anatoly Podgoretsky (2007-01-19 14:37:00) [3]
> что не найти "такую же", но хорошую

А такой же но с перламутровыми пуговицами

vlad2 (2007-01-19 09:54:00) [4]
Большое спасибо всем участникам обсуждения, вы мне помогли своими советами. Скорее всего, решение будет принято в пользу клиент-сервера.

Одно замечание последнему автору (evvcom © (19.01.07 08:55) [54]):
> хорош нам мозги парить. Уже за 50 постов, а ты все никак не примиришься ...

Я вам тоже благодарен:за участие, но силой не затягивал в эту дискуссию.

Считаю вопрос закрытым. Спасибо.

evvcom (2007-01-19 08:55:00) [5]
> [53] MsGuns © (18.01.07 22:28)
> все равно, что найти жену,

Ну тут ты меня порадовал :-)

Автор, ну чего ты паришься? Или переходи на серверную СУБД и переделывай свою базу или хорош нам мозги парить. Уже за 50 постов, а ты все никак не примиришься с тем, что не найти "такую же", но хорошую и чтоб ничего не делать.

MsGuns (2007-01-18 22:28:00) [6]
>vlad2 (17.01.07 13:41) [29]
>Быстро , гораздо быстрее Оракла на живой таблице.. Почему он так работает, не знаю, не уверен, что нужно так глубоко в это вникать,

А Вы все же узнайте, вникните. И тогда поймете, как поддерживается эта "живость" и что жертвуется ради нее.
После этого быстро убежите с парадокса.

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

В-четвертых, даже для парадокса можно написать достаточно надежную систему. При этом с БД будет одновременно работать 20-30 человек.
И, наконец, никто не запрещает Вам использовать сервер приложений.

Найти же просто "другой" парадокс, который с мимнимумом переделок будет надежно работать со старой "хромой" базой - все равно, что найти жену, такую же как имеется, только не вредную и на 20 лет моложе ;)))

Виталий Панасенко (2007-01-18 20:04:00) [7]

> Anatoly Podgoretsky © (18.01.07 18:18) [51]
>
>
> > Обеспечивается ли в MSAccess и dBase совместный доступ
> автоматически
> > (как в Оракле), чтобы я не заботился об этом при программировании?
>
> >
>
> А что используется?
> Как минимум при БДЕ и TTable совместный доступ для dBase
> обеспечивается автоматически.
> С запросами много сложнее другая идеология.
> Касательно Акцесс он работает исключительно через запросы.
>
>

А если помощь почитать, то там приводятся настройки для TableDirect, без запросов.Насколько помню,ТОЛЬКО при этом раскладе работает Seek - быстрый поиск по активному индексу

Anatoly Podgoretsky (2007-01-18 18:18:00) [8]

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

А что используется?
Как минимум при БДЕ и TTable совместный доступ для dBase обеспечивается автоматически.
С запросами много сложнее другая идеология.
Касательно Акцесс он работает исключительно через запросы.

AndreyV (2007-01-18 17:19:00) [9]
>Хотелось бы всё-таки уточнить вопрос:
>Обеспечивается ли в MSAccess и dBase совместный доступ автоматически (как в Оракле), чтобы я не >заботился об этом при программировании?

Файл/сервер "MSAccess и dBase" и клиент/скрвер "как в Оракле" - это разные парадигмы.
А "чтобы я не >заботился" - так от этого не уйти, или что имеется ввиду?
Если навигация, так уже были ответы.

vlad2 (2007-01-18 16:48:00) [10]
Спасибо участникам за консультацию.
Хотелось бы всё-таки уточнить вопрос:
Обеспечивается ли в MSAccess и dBase совместный доступ автоматически (как в Оракле), чтобы я не заботился об этом при программировании?

Anatoly Podgoretsky (2007-01-17 19:32:00) [11]
> Sergey13 (17.01.2007 14:24:36) [36]

За счет разделения работы с отдельными файлами, например преобразованием индексов. Кроме того многофайловые базы снимают ограничение на размер базы, там действует ограничение на файл, а не на всю базу.

Anatoly Podgoretsky (2007-01-17 19:30:00) [12]
> vlad2 (17.01.2007 14:23:35) [35]

> По скорости ADO+MSAccess насколько будет (или не будет) уступать BDE+Paradox?

Так скорость определяется не столько типом СУБД, сколько оптимальными запросами. Любую базу легко поставить на колени, достаточно правильно сконструировать запросы для этого.

Anatoly Podgoretsky (2007-01-17 19:27:00) [13]
> Sergey13 (17.01.2007 13:18:27) [27]

Не до 5, а до сотни.

Anatoly Podgoretsky (2007-01-17 19:26:00) [14]
> vlad2 (17.01.2007 12:38:22) [22]

Существуют, из распространеных dBase/Access,
только переход на любую другую СУБД обязательно потребует усилий и неизвестно насколько больше, чем при переходе на клиент/сервер. Если Парадокс программа написана с использованием запросов, то полегче, например при переходе на dBase по сути потребуется смена алиаса, если никаких экзотических особенностей не использовано.

AndreyV (2007-01-17 18:04:00) [15]
Смотри ADS.
Есть локальный бесплатный и
Клиент-сервер платный.
Возможность навигационной работы и SQL.
Формат DBF FoxPro, Clipper и ADT свой.

Но лучше, конечно, переделать на архитектуру Клиент-сервер
на том же FB.

Prohodil Mimo (2007-01-17 17:52:00) [16]
лучше день потерять, потом за час долететь (с) Крылья, ноги, хвост.

sniknik (2007-01-17 14:49:00) [17]
> А какие в MSAccess ограничения на размер?
2 gb на файл базы

> По скорости ADO+MSAccess насколько будет (или не будет) уступать BDE+Paradox?
будет медленнее немного, если работать один в один как с парадоксом, при небольших усилиях/переделках возможны варианты, что чтото будет быстрее по сравнению с парадоксом.

evvcom (2007-01-17 14:49:00) [18]
> [29] vlad2 (17.01.07 13:41)
> > Тогда сначала объясни как работает Парадокс
> Быстро , гораздо быстрее Оракла на живой таблице

А... ну если это все критерии работы парадокса, то я даже и не знаю, что тебе ответить. :-)))

Romkin (2007-01-17 14:33:00) [19]

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

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

alex_*** (2007-01-17 14:28:00) [20]

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

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

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

Наверх

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