[Borodunter]

мне кажется, что FireBird слишком громоздка для простой задачи на одного пользователя...
почему бы не использовать тот же MySQL?

[BlackEric]

1. У FireBird есть embedded версия.
2. Это смотря что делать: если нужны хранимки, параллельные транзакции и прочее то MySQL уже не не подходит. IMHO, конечно.
3. Если писать на Java, то можно использовать Apache Derby (Java DB).

Поскольку автор точно задачу так и не описал, то я привел FireBird лишь как пример легкой, кроссплатформенной и не требовательной СУБД с широкими возможностями.

[Gamover jr]

Задачу сейчас можно описатьтак: сначалак минимальная автоматизация, а потом в соответствии с ростом потребностей. Аппетит как известно приходит во время еды. Одно будет неизменно: один пользователь, небольшой объём данных, данные только цифры и текст, графика или звук не нужны. Отказываться от SQL не хочется, потому что даные со временем накопятся до объёмов, из которых можно будет извлекать новую инфу.

[BlackEric]

Ну тогда, как я писал, берите любую понравившуюся СУБД и пишите к ней клиента на чем нравится.
Только не берите DOS - это путь в никуда. Он уже 10 лет как умер. Начинать новый проект на тех технологиях означает заранее обречь его на недолгую и мучительную жизнь, да и полученные знания врядли пригодятся в дальнейшем.

[Gamover jr]

Ещё вопрос на будущее.
Имхо существует тенденция, что слабые компы становятся очень интересны многим заказчикам. Народ начинает автоматизировать производства и ставить компы где только можно так выгадать. И чем меньше мегабайт и мегагерц нужно тем интереснее.
Вопрос: какая комбинация ОС+СУБД лучше всего вписываются в эту тенденцию?

[BlackEric]

1. Вообще-то СУБД как правило лежит на сервере.
2. Инструмент (средства разработки и железо) выбираются под задачу, а не наоборот.
3. Везде нужно смотреть по конкретной задаче и ситуации, как правило используются уже использующиеся технологии и имеющиеся на предприятии наработки, поскольку плодить зоопарк различного софта себе дороже.

[Gamover jr]

1. Подключение к Интернету ещё долго будет слабым и ненадёжным, т.е. разумнее подключаться чтобы выложить "готовые" данные.
2. Прооект имеет больше шансов, если позволяет съэкономить на железе.
3. Учтите специфику, как средний и мелкий бизнес собирает и обрабатывает хозяйственную информацию.

[BlackEric]

1. Подключение к Интернету ещё долго будет слабым и ненадёжным, т.е. разумнее подключаться чтобы выложить "готовые" данные. »

Если вы имеете в виду распределенную БД, то тогда встает проблема репликации данных между филиалами, что значительно усложняет разработку и сопровождение системы.
Здесь есть небольшое описание проблем возникающих при репликации данных http://replication.chat.ru/.
Я здесь вообщето имел ввиду, что ОС клиента и сервера могут быть различны.

2. Прооект имеет больше шансов, если позволяет съэкономить на железе. »

Cогласен, но все должно быть вмеру.

3. Учтите специфику, как средний и мелкий бизнес собирает и обрабатывает хозяйственную информацию. »

Я знаю что такое наличие на предприятии двух не сильно стыкующихся между собой инфомационных систем. Это вынуждает как правило писать какой либо костыль для перекачки данных между ними и не позволяет скучать администраторам.

Непродуманное решение 1 и 3 пункта очень позитивно влияет на зарплату админа. Т.е. cтоимость обслуживания системы тоже нужно учитывать при проектировании и принятии решения о внедрении.

[Dr. Freeman]

А SQLite не подойдёт?

При попытке перехода на SQLite.ru вышел такой текст:

Query failed: select * from wakka_sqlite_pages where supertag='homepage' and latest = 'Y' limit 1 (1146: Table 'mithraenwiki.wakka_sqlite_pages' doesn't exist)

Не иначе, как они тесные отношения с последней версией Ваки имеют.