Вопрос по локальным базам данных

← →
snowman2002 (2005-06-22 14:00) [0]

Что лучше использовать в качестве локальной базы данных? Сама БД - простейшая (три таблицы), но будет содержать большое количество записей (в одной из таблиц - около 100-200 тысяч записей). Пока остановился на Paradox через BDE, но там вроде бы есть ограничение по объему данных?

← →
Digitman © (2005-06-22 14:15) [1]

> вроде бы есть ограничение по объему данных?

цитируй первоисточник этого "вроде" ...

← →
Stanislav © (2005-06-22 14:16) [2]

Paradox потянет 200 тыс.
Access.

← →
Sergey13 © (2005-06-22 14:22) [3]

>Пока остановился на Paradox через BDE
Чем обусловлена эта остановка?

Это что за остановка
Бологое иль Поповка?
А с платформы говорят
Это город Ленинград.
(с)

Короче езжай дальше. 8-)
Мое предложение ФайрБерд Ембеддед+ИБХ.

← →
Rule © (2005-06-22 14:33) [4]

Sergey13 © (22.06.05 14:22) [3]
соглашусь с этим :
ФайрБерд Ембеддед только вот ИБХ поменял бы на Фибы ...

← →
Sergey13 © (2005-06-22 14:37) [5]

2[4] Rule © (22.06.05 14:33)
>только вот ИБХ поменял бы на Фибы ...
Если дополнительных денег не жалко, то почему бы и не поменять. 8-)

← →
Rule © (2005-06-22 14:56) [6]

Sergey13 © (22.06.05 14:37) [5]
я думаю в данном случае тех денег которые они просят не жалко, нервная система и время дороже, ИМХО конешно

← →
Sergey13 © (2005-06-22 15:00) [7]

2[6] Rule © (22.06.05 14:56)
ИМХО, опять же, но работая с ИБХ я на нервы не особо жалуюсь. Может потому что ФИБов в глаза не видел? 8-)

← →
Rule © (2005-06-22 15:05) [8]

Sergey13 © (22.06.05 15:00) [7]
могу сказать сразу, как наркотик, закон такой есть, что к хорошему быстро привыкают ....
очень советую попробовать ...

← →
Sergey13 © (2005-06-22 15:14) [9]

2[8] Rule © (22.06.05 15:05)
Так ведь наркотики не только кайф приносят, но и ломку при их отсутствии. 8-)
Меня например и БДЕ особо не напрягает. При том, что через ДОА с Ораклом например удобнее работать. Ко всему привыкаешь.

Вопрос философский и достоин к переносу в "Потрепаться". 8-)

← →
Rule © (2005-06-22 15:18) [10]

Sergey13 © (22.06.05 15:14) [9]
Вопрос философский и достоин к переносу в "Потрепаться". 8-)
согласен и вроде бы и обсуждается регулярно :-) (могу лишь сказать что на вкус и на цвет ...)

← →
Amoeba © (2005-06-22 15:18) [11]

Если кому надо, могу на халяву поделиться FIBPlus.

← →
Sergey13 © (2005-06-22 15:21) [12]

2[11] Amoeba © (22.06.05 15:18)
Тут все честные и правила форума не нарушают. 8-)

← →
Rule © (2005-06-22 15:29) [13]

Amoeba © (22.06.05 15:18) [11]
на форуме не одобряется, так как многие из участников - разработчики ... на будущее ...

← →
snowman2002 (2005-06-22 15:40) [14]

Спасибо за ответы, друзья! Но хотелось больше конкретики и меньше философии. В чем будут преимущества FireBird по сравнению с Paradox в данном конкретном случае? Желательно описать хотя бы основные плюсы и минусы...

← →
Sergey13 © (2005-06-22 15:49) [15]

2[14] snowman2002 (22.06.05 15:40)
>В чем будут преимущества FireBird по сравнению с Paradox в данном конкретном случае?
Во всем. Минусов не будет точно.

← →
snowman2002 (2005-06-22 15:51) [16]

Sergey13
Чуть конкретнее. Скажем, три наиболее важных преимущества FireBird над Paradox?

← →
Anatoly Podgoretsky © (2005-06-22 15:54) [17]

По степени уменьшения мощности
DB2, Oracle, MSSQL, Interbase, БДЕ (как движок) - список можно продолжать.

← →
Johnmen © (2005-06-22 15:58) [18]

>Anatoly Podgoretsky © (22.06.05 15:54) [17]
>По степени уменьшения мощности

Что за мощность ? В киловаттах ? :)))))))))

← →
snowman2002 (2005-06-22 16:02) [19]

Anatoly Podgoretsky
Нужна простая ЛОКАЛЬНАЯ БД! Я конечно понимаю, что можно и микроскопом гвозди забивать, но хотелось бы получить рекомендации по выбору молотка...

← →
snowman2002 (2005-06-22 16:06) [20]

Господа! Можно все-таки поконкретнее. На вроде бы простой вопрос уже написано около 20 ответов, из них конкретное предложение только одно - FireBird. Отлично, но возникают два законных вопроса:
1. Чем хорош FireBird по сравнению с BDE в моем случае?
2. Есть ли еще варианты?

← →
Stanislav © (2005-06-22 16:11) [21]

ACCESS+ADO. Зачем Interbase для 3-х таблиц, тем более, которые используются локально.

← →
Johnmen © (2005-06-22 16:13) [22]

>snowman2002 (22.06.05 16:06) [20]

1. Писать пространные трактаты по поводу лучшести/хужести здесь вряд ли кто-то будет. В [3] уже сказали, что тебе подойдёт. Лучше по всем критериям...
2. Есть. "А впрочем тебе ещё рано об этом" (с)
:)))

← →
Sergey13 © (2005-06-22 16:18) [23]

2[16] snowman2002 (22.06.05 15:51)
>Чуть конкретнее. Скажем, три наиболее важных преимущества FireBird над Paradox?
1. Это нормальный СКЛ сервер, с ХП и тригерами и прочими преимуществами.
2. Это надежный сервер не требующий админа.
3. При перерастании задачи из локальной в сетевую (почти все перерастают со временм 8-) ничего не надо переделывать.
4. Установка проги - просто копирование файлов без установки в систему ничего "лишнего".
5. Это практика работы с п.1 для дальнейшей жизни.
6. Он бесплатен.
7. Он постоянно развивается
8. Он кросплатформенный.

N-1. Он мне нравится. 8-)

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

← →
Anatoly Podgoretsky © (2005-06-22 16:29) [24]

Johnmen © (22.06.05 15:58) [18]
В килобаксовости

← →
snowman2002 (2005-06-22 16:34) [25]

Sergey13
Большое спасибо за ответ! Честно говоря единственное преимущество в моем случае - это п.4... Так как база простейшая и она 100% не перерастет в сетевую (в виду специфики), мне вполне достаточно индексов, фильтров и поисков обычного Paradox - BDE... Что касается опыта работы с нормальными SQL-серверами, он имеется и так (Oracle и MySQL). Но все-таки FireBird"ом Вы меня заинтересовали - уже качаю дистрибутив!

← →
Johnmen © (2005-06-22 16:36) [26]

>Anatoly Podgoretsky © (22.06.05 16:29) [24]

А...Понятно :)

← →
Rule © (2005-06-22 16:56) [27]

Stanislav © (22.06.05 16:11) [21]
а тут не про интербейз идет речь, а о всраиваемом фаерберде, помоему ACCESS+ADO не лучшее решени в плане своей универсальности, не на всех машинах пойдет, нужно иметь соответствующий драйвер АДО на машине и производительность, там (фаерберд) прямой доступ а тут через несколько технологий, что естественно влечет кучу проблеммасов ....

snowman2002 (22.06.05 16:34) [25]
один из критериев написания ПО - это расширяемость, вот в данном случае она реализуетья с лихвой, а вот БДЕ - это умирающая технология, я если встречаю новый продукт под БДЕ то плююсь даже патолок весь грязный, обычно такое ПО изготовляют голодные студенты ....

← →
snowman2002 (2005-06-22 17:52) [28]

Rule
В отношении BDE я согласен с Вами полностью! Именно поэтому и возник данный вопрос... С одной стороны база данных и работа с ней - простейшие и не хочется усложнять проект серьезными базами данных... А с другой стороны хочется использовать достойную альтернативу. Но не "перегибать палку"!

← →
Rule © (2005-06-22 18:09) [29]

snowman2002 (22.06.05 17:52) [28]
ну дык чем тебе фаерберд не нравится, помоему здорово в твоем случае ...

← →
s999 (2005-06-22 19:45) [30]

>Так как база простейшая и она 100% не перерастет в сетевую (в виду специфики)

Если это действительно так, то возьми Halcyon или TDBF и не мучайся с советами, которые тебе здесь надавали.

← →
ANB © (2005-06-22 20:00) [31]

> Если это действительно так, то возьми Halcyon или TDBF и
> не мучайся с советами, которые тебе здесь надавали.
- и мучайся потом с их использованием. Оракл рулез.

← →
Anatoly Podgoretsky © (2005-06-22 22:42) [32]

Вообще то DB2 рулез

← →
ANB © (2005-06-23 08:32) [33]

> Вообще то DB2 рулез
- ну, DB2 уже не настольная система.

← →
Sergey13 © (2005-06-23 09:07) [34]

2[33] ANB © (23.06.05 08:32)
> Вообще то DB2 рулез
>- ну, DB2 уже не настольная система.
Напольная? 8-)

← →
КиТаЯц © (2005-06-23 09:21) [35]

>Sergey13 © (22.06.05 16:18) [23]

Касательно FireBird...
+ п.9 "Попробовав это Вы уже не сможете отказаться",
(с) реклама для Жиллет.

:)

← →
msguns © (2005-06-23 12:08) [36]

Я бы выделил из всех преимуществ SQL-серверов над Paradox (именно) всего 4, но зато КАКИХ :
1. Таблицы не падают с регулярностью роста цен. В день по нескольку раз.
2. Полноценная транзакционность. В парадоксе для того, чтобы обеспечивать защиту целостности приходится создавать целые таблицы для хранения промежуточных итогов (типа сальдовых остатков) и писать монстроидальные кросс-расчеты (типичный пример - склад), которые к тому же требуют блокировки основных таблиц и продолжительны по времени. В сиквелях этого не требуется. Любое сложное изменение данных (как пример, при правке фактуры накладной идет пересчет текущего остатка, суммы в целом по накладной, отметка в журнале заказов и т.д.) либо выполняется полностью, либо не выполняется совсем. При этом за корректностью последовательных конкурентных изменений следит сам сервер.
3. Возможность выноса бОльшей части бизнес-логики из клиентских приложений на сервер (триггера, процедуры, представления, генераторы, форейн-кеи и т.п.)
4. Наличие полноценного генератора уникальных ID, что позволяет строить все межтабличные связи (и не только), даже не подозревая о каких-то конфликтах.

← →
Anatoly Podgoretsky © (2005-06-23 13:00) [37]

ANB © (23.06.05 08:32) [33]
Неправ, есть и персональная версия.

msguns © (23.06.05 12:08) [36]
Насчет Парадокс - перед ним имеют преимущества все остальные системы, у Парадокса только одно преимущество, примеры у Архангельского сделаны на нем.

← →
s999 (2005-06-23 13:23) [40]

> 1. Таблицы не падают с регулярностью роста цен. В день по
> нескольку раз.

Гм.. Откудаж такая уверенность, что все файл-серверные системы все время падают, сыпятся... Имея опыт разработки и сопровождения dbf-ной тиражной системы (более 10-ти лет) могу сказать, что индексы падают не чаще, чем "сыпится" gdb-файл от IB/FB (типа "wrong page type" и т.п.). Разрушений самих dbf вообще наблюдал от силы раза 2-3, при этом данные достаточно просто восстанавливались. Другое дело, что "защита от дурака" в SQL серьезно выше, но ведь это уже другой срез проблемы? :)))

2-4. Учитывая, что "Так как база простейшая и она 100% не перерастет в сетевую (в виду специфики)" - то все это нафиг не нужно.

s999 (23.06.05 13:23) [40]
Это относится только к Парадокс. Такой же опыт по дбф есть и у меня, крутится несколько сетевых баз в необслуживаемом режисе уже 7 лет. Случаи порчи индекса были только в версиями БДЕ16 и версиями БДЕ32 до 3.5
Точно такую же высокую, если не выше, надежность имеет и Акцесс.

Вот-вот. Сколько стоит файл-серверных систем на основе dbf (та же 1С, например - у каждого бухгалтера, и, в основном - dbf), и падают очень редко. Так что не согласен.

Но dbf не люблю.
По другим причинам.

[42] -=XP=- © (23.06.05 13:34)
Про 1С ненадо. :)) Чем больше активных пользователей - тем больше вероятность разваливания базы. После какого-то критическоко соотношения колво_пользователей*размер_базы с ней на ДБФ-ках невозможно работать, приходится переносить на скуль-сервер, несмотря на то, что сиквельный вариант 1с77 намного более тормозной, чем на ДБФ-ках.

>s999 (23.06.05 13:23) [40]

Я же не случайно подчернул в посте, что имеется в виде именно парадокс (с учетом сабжа).
На счет того, что не нужно 2-4..
В принципе не согласен. Какая разница, на сколько персон готовить шашлык - мясо все равно должно быть свежим :))

← →
s999 (2005-06-23 14:10) [46]

> Какая разница, на сколько персон готовить шашлык - мясо
> все равно должно быть свежим :))

А зачем одной персоне сразу 5 килограмм шашлыка? :)) Пропадут же попусту. А про "свежесть" dbf-ов уже сказал не только я.

А почему?

1. Слишком много файлов - таблицы, индексы.
2. Файловый доступ к данным (хотя, в некоторых случаях, например, для локальных приложений, это - плюс).
3. Из (2) - некоторые проблемы при работе в сети, в частности - бОльший траффик и пр.
4. Отсутствие "правильных" :) транзакций, ХП, триггеров, функций управления правами доступа, шифрования и пр.
5. Трудность миграции на другие форматы (сравнить, хотя бы, с миграцией MS Jet -> MSDE, MS SQL Server).

Точно такую же высокую, если не выше, надежность имеет и Акцесс.

На самом деле весьма стОящая разработка. Заслуживает внимания и уважения. Для локальных приложений, я думаю, лучшего не найти. Есть все (за исключением, правда, триггеров) - и шифрование, и ХП, и пользователи, и пр. Транзакции работают хорошо (правда, только 5 уровней вложенности). Надежность - очень высокая. На моей памяти, за много лет "падала" только один раз - из-за сбоя питания. Но Access восстанавливает поврежденные БД "с полоборота". Администрирования не требует никакого. А если и захочется что-то сделать - Access предлагает очень удобный интерфейс. Среди локальных СУБД поставлю MS Jet 5+ :)

В одной организации стоит сетевое приложение на основе MS Jet - БД больше 200 МБайт, в среднем, растет в месяц на 10-15 МБайт. 10 пользователей в сети. До 2000 транзакций в день. Размещается на "расшаренной" "флешке" 512 МБ :))))) (Поубивал бы руководителей за такое!). Не "падала" ни разу, даже при аварийном выдергивании "флешки". Это, правда, один из самых "крупных" :) проектов на основе MS Jet. Обычно - до 5 пользователей. Хотя, MS обещает максимум 255, и "нормальную" работу при 50 пользователях.

-=XP=- © (23.06.05 14:16) [47]
1. Слишком много файлов - таблицы, индексы.
Это хорошо, повышает надежность и снижает требования файловой системы на размер файлов

2. Файловый доступ к данным (хотя, в некоторых случаях, например, для локальных приложений, это - плюс).
У всех данные хранятся в файлах, плохо только другое - одновременный файловый доступ с разных машин.

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

4. Отсутствие "правильных" :) транзакций, ХП, триггеров, функций управления правами доступа, шифрования и пр.
У некоторох клиент-серверных систем аналогично, так что критерий не формата, а движка/сервера.

5. Трудность миграции на другие форматы (сравнить, хотя бы, с миграцией MS Jet -> MSDE, MS SQL Server).
Наиболее распространеный формат при импорте/эксторте, ничто не имеет такой широкой поддержки как дбейс, даже Эксель с ним может работать напрямую.
JET не формат, а движок, прекрасно работает как с дбейс, так и с MS SQL. Поэтому утверждение выглядит абсурдом. Если же ты имел ввиду Акцесс, то миграция чрезвыяайно тяжела. Это топ вопрос в форумах.

Надежность - очень высокая.
За счет трансакционной модели работы с файлом. Последствия резкое разрастание файла, а учитывая ограничение в 2 гб это очень серьезно. Этому же способствует все в одном флаконе. Эта проблема менее остро стоит в многофайловых системах.

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

А если и захочется что-то сделать - Access предлагает очень удобный интерфейс. Среди локальных СУБД поставлю MS Jet 5+ :)
К MS Jet не имеет никакого отношения. Это заслуга Акцесс, при том задолго до появления Jet. Я первый раз столкнулся с Акцесс 2 еще на Win16 - так вот вхождения не потребовалось, просто сразу стал работать.

Хотя, MS обещает максимум 255, и "нормальную" работу при 50 пользователях.
При правильной организации, реально сотня пользователей может работать без проблем.

Только серьезная проблема возникнет при миграции на тот же MS SQL. Хотя бы из-за того, что у Акцесса практически нет своих функций, а используются функции Визуал Бейсик. Легче переписать с нуля, чем мигрировать.
Последнее время Микрософт рекомендует не использовать родные форматы в Акцесс и ФоксПро, а использовать для работы MSDE (входит в комплект поставки), вот в этом случае миграция на другой фронтэнд происходит просто, если конечно не будут использованы функции Визуал Бейсик

Отсюда делаем вывод, если почему то понравился формат Акцесс или ФоксПро, то сразу ставим крест на этих форматов, а используем MS SQL (MSDE) как формат хранения и обработки данных. Миграция на полноценный сервер нулевая, меняем только Connection String или UDL файл.

если почему то понравился формат Акцесс или ФоксПро, то сразу ставим крест на этих форматов

А если не понравился - крест можно не ставить? :)

MSDE или MS SQL Server - это правильно.
Но тут речь, все же, идет о локальной СУБД, не требующей установки на компьютере пользователя. MS Jet - одно из возможных, и весьма оптимальных решений. mdb - "родной" формат MS Jet. Так что, советую автору вопроса взглянуть, в частности, и в сторону этой СУБД.

-=XP=- © (23.06.05 15:02) [51]
MSDE или MS SQL Server - это правильно.

Это одно и тоже, просто разные редакции, первая предназначена для локального использования, как локальная СУБД, но не запрещено использовать в серверном режиме. Кроме него также есть редакция MS SQL Personal Edition, рекомендуется в первую очередь для мобильных компьютеров, класса ноутпад или кпк.

Насчет MS Jet - после версии 2.5 уже не включает в себя JET, надо качать отдельно и устанавливать. Jet не имеет никаких родных форматов, это всего лишь движок, поддерживающий неограниченое количество форматов. Обычно с ним работают не напрямую, а через ADO OLE DB

Администрирование требуется в части постоянного сжатия базы.

The 4.0 provider now exposes a provider-specific interface called IJetCompact that can be used to compact databases and manage compaction-related properties, such as database encryption and database repair.
http://msdn.microsoft.com/library/en-us/oledb/htm/oledbprovjet_compacting_jet_databases.asp?frame=true

Отсутствие "правильных" :) транзакций, ХП, триггеров, функций управления правами доступа, шифрования и пр.
>>У некоторох клиент-серверных систем аналогично, так что критерий не формата, а движка/сервера.

50/50

Jet не имеет никаких родных форматов, это всего лишь движок, поддерживающий неограниченое количество форматов

Microsoft Jet database
A database created with the Microsoft Jet database engine. The file name extension for a Microsoft Jet database is .mdb.
http://office.microsoft.com/en-us/assistance/HP010441931033.aspx

В контексте этого "сравнить, хотя бы, с миграцией MS Jet -> MSDE, MS SQL Server" - корректное утверждение.

Насчет MS Jet - после версии 2.5 уже не включает в себя JET

Имеется в виду MDAC? C XP идет MS Jet 4.0.

Вопрос по локальным базам данных Найти похожие ветки