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

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

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

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

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

← →
Anatoly Podgoretsky © (2005-06-23 13:31) [41]

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

← →
-=XP=- © (2005-06-23 13:34) [42]

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

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

← →
Anatoly Podgoretsky © (2005-06-23 13:36) [43]

-=XP=- © (23.06.05 13:34) [42]
А почему?

← →
Danilka © (2005-06-23 13:38) [44]

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

← →
msguns © (2005-06-23 13:44) [45]

>s999 (23.06.05 13:23) [40]

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

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

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

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

← →
-=XP=- © (2005-06-23 14:16) [47]

А почему?

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 пользователях.

← →
Anatoly Podgoretsky © (2005-06-23 14:31) [48]

-=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 пользователях.
При правильной организации, реально сотня пользователей может работать без проблем.

← →
Anatoly Podgoretsky © (2005-06-23 14:34) [49]

Только серьезная проблема возникнет при миграции на тот же 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.

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