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

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

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

Вопрос по локальным базам данных [D7, Paradox]

Страницы: 1 2 3 >
snowman2002 © (2005-06-22 14:00:00)
Что лучше использовать в качестве локальной базы данных? Сама БД - простейшая (три таблицы), но будет содержать большое количество записей (в одной из таблиц - около 100-200 тысяч записей). Пока остановился на Paradox через BDE, но там вроде бы есть ограничение по объему данных?

-=XP=- (2005-06-23 15:52:00) [1]
Администрирование требуется в части постоянного сжатия базы.

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.

Anatoly Podgoretsky (2005-06-23 15:11:00) [2]
-=XP=- © (23.06.05 15:02) [51]
MSDE или MS SQL Server - это правильно.

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

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

-=XP=- (2005-06-23 15:02:00) [3]
если почему то понравился формат Акцесс или ФоксПро, то сразу ставим крест на этих форматов

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

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

Anatoly Podgoretsky (2005-06-23 14:36:00) [4]
Отсюда делаем вывод, если почему то понравился формат Акцесс или ФоксПро, то сразу ставим крест на этих форматов, а используем MS SQL (MSDE) как формат хранения и обработки данных. Миграция на полноценный сервер нулевая, меняем только Connection String или UDL файл.

Anatoly Podgoretsky (2005-06-23 14:34:00) [5]
Только серьезная проблема возникнет при миграции на тот же MS SQL. Хотя бы из-за того, что у Акцесса практически нет своих функций, а используются функции Визуал Бейсик. Легче переписать с нуля, чем мигрировать.
Последнее время Микрософт рекомендует не использовать родные форматы в Акцесс и ФоксПро, а использовать для работы MSDE (входит в комплект поставки), вот в этом случае миграция на другой фронтэнд происходит просто, если конечно не будут использованы функции Визуал Бейсик

Anatoly Podgoretsky (2005-06-23 14:31:00) [6]
-=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 пользователях.
При правильной организации, реально сотня пользователей может работать без проблем.

-=XP=- (2005-06-23 14:16:00) [7]
А почему?

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

s999 (2005-06-23 14:10:00) [8]

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

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

msguns (2005-06-23 13:44:00) [9]
>s999 (23.06.05 13:23) [40]

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

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

Anatoly Podgoretsky (2005-06-23 13:36:00) [11]
-=XP=- © (23.06.05 13:34) [42]
А почему?

-=XP=- (2005-06-23 13:34:00) [12]
Вот-вот. Сколько стоит файл-серверных систем на основе dbf (та же 1С, например - у каждого бухгалтера, и, в основном - dbf), и падают очень редко. Так что не согласен.

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

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

s999 (2005-06-23 13:23:00) [14]

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

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

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

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

Anatoly Podgoretsky (2005-06-23 13:01:00) [16]
КиТаЯц © (23.06.05 09:21) [35]
Без проблем и сожалений

Anatoly Podgoretsky (2005-06-23 13:00:00) [17]
ANB © (23.06.05 08:32) [33]
Неправ, есть и персональная версия.

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

КиТаЯц (2005-06-23 09:21:00) [19]
>Sergey13 © (22.06.05 16:18) [23]

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

:)

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

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

Наверх

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