|
>Но если это однопользовательская локальная программулина с нулевым администрированием то тянуть крупную СУБД смысла нет, нет смысла тянуть и MSDE, а бывает и аксесс это много.
Абсолютно не согласен, давайте посмотрим варианты для малых БД, однопользовательских:
1. Текстовые файлы, или типизованные - разница в контексте базы незаметна особо
2. Локальная БД типа PDox, dBase, Fox, Access
3. Легкий SQL-server, однопользовательский
Теперь, что, собственно, требуется от НОРМАЛЬНОГО однопользовательского приложения с БД:
a. Легкость установки и эксплуатации
b. Надежность - если пользователь сказал ОК, данные должны сохраниться в БД, если не было исключений
c. Помехоустойчивость: должна быть предусмотрена система восстановления после сбоев, желательно автоматическая
d. Возможность создания страховочных копий "на лету". Я не говорю о примитивной базе, в которой Вася Пупкин ведет учет своих затрат на интернет, данные, как правило, даже в таких БД достаточно серьезные.
e. Быстрота работы
f. Легкость в сопровождении и по возможности, масштабируемость. Поверьте мне, даже если вы абсолютно уверены, что несколько пользователей НИКОГДА не потребуется, через некоторое время будет немного жалко, когда вы будете встраивать такой же кусок кода в многопользовательское приложение.
g. Низкая стоимость разработки и лицензирования
Теперь варианты:
1. Устанавливать легко, это понятно. Остальные пункты - ручками, как сделаешь, так и полетишь... Разрабатывать долго, ручная работа. e. - Возможно, самая высокая. f - реально никогда. Стоимость разработки самая дорогая, лицензирование - бесплатно
2. Движок, как правило, быть должен. Легкость установки - зависит от среды разработки, но как правило, достаточно легко. Надежность - ручками, как напишешь. c. Либо в своем приложении предусматриваешь, либо ставишь движок, который будет это делать (MS Access например). d. Пишем, архивируем и тд - ручками. e. Быстро, быстрее всего, и писать не надо f. Легкость есть, если dbf или Access, но, как правило, через родное приложение/среду разработки. Масштабируемость - трудновато, приходится предусматривать при разработке. Разработка средней тяжести (с учетом ВСЕХ пунктов), лицензирование - движок, как правило, бесплатен, а вот сервисные службы - плати за лицензию...
3. a. Еще недавно сказал бы - поставка неудобна, ставишь сервер, админишь... Сейчас - так же, как и п.2. b. Надежность - высокая, транзакция прошла - данные сохранены. c. Устойчивость к отказам - имеется, автоматически. d. Ну функции backup также встроены, только интерфейс поудобнее, сделать на порядок проще, чем в п.2 e. Скорость - также, как п.2, или чуть медленнее. f. - Вне конкуренции, поменять что-то в хранимой процедуре довольно просто, в том числе при обновлении, масштабируемость? Ставьте сервер, конфигурируйте соединение - все! (Этот пункт, скажу сразу, действует на заказчика ошеломляюще) g. При разработке просто делайте структуру, планируйте запросы и пишите интерфейс, остальное уже есть. Лицензирование - да, требуется (как правило). Сейчас Yaffil Personal & Firebird Embedded бесплатен, а для 1 dll всегда место найдется. Плюс - весть стандарт SQL92 к Вашим услугам.
Вот так. Так я сопоставил несколько лет назад - и ушел с файл-сервера, чего и вам желаю. Результат - пару лет назад сделал складскую книгу прихода/расхода, там всего десяток табличек, на клиенте - пара десятков форм, плюс, разумеется, считывание штрих-кода и протчее. Срок? 72 человеко-часа от постановки до релиза, потом две недели инструктаж как работать и бекапится, пара багов... Работает. Единственный шанс потерять данные - крах жесткого диска (восстанавливайте из архива). А ведь потеря нескольких записей в этой базе приводит к потере недели работы - инвентаризация нужна.
|
