Как работали БД под DOS?
 

Был ли для них какой нибудь "DBEngine" или сервер базы данных, который делал всю сложную работу с доступом и манипуляцие данными?

Gamover jr,
Зачем?
Первый Oracle x86 был под DOS

Зреет идея соорудить программку под DOS, которая будет сохранять инфу в файл. Лучше конечно поручить это какой-нибудь СУБДе, я пока без малейшего представления, как это под DOSом раньше делали и как сегодня это грамотно сделать. Если DOS - нелучший вариант, и вообще за любой совет буду признателен.

1. Чем обусловлен выбор DOS?
2. Зачем вам нужна СУБД? Чем не устроят обычные текстовые файлы или dbf?

1. Посоветуйте что другое, попробую, я пока не определился. Главное покомпактнее.
2. А как из них инфу извлекать? Что такого особого в dbf? Есть компоненты для dbf, которые под DOS можно использовать?
В общем, не хочется изобретать кривой велосипед, если до меня всё нормально изобретено.

Что бы советовать необходимо хотя бы в общих чертах представлять задачу. Из вашего описания абсолютно непонятно почему выбран DOS.

На чем вы писать собираетесь? Под DOS компоненты еще не использовались... Или что вы понимаете под компонентами?

БД для DOS: FoxPro, Paradox. Ищите информацию для них.

1. Из dos-подобного я ничего другого не знаю, потому и спрашиваю. Задача: маленькая БД на одного пользователя.
2. точно, ещё не использовались. посмотрю, что такое Paradox. а писать буду на чём скажете.

Мне очень интересно: чем вас не устраивают современные ОС win/*nix?

Писать нужно на том что знаете...
И выбор под DOS не велик, особенно в части построения пользоватьльского интерфейса. Я кроме Turbo Vision сейчас ничего и не вспомню.

P.S. Если БД действительно маленькая, то я бы не терял время на изучение ненужных вещей, а тупо использовал текстовые файлы.

Что из *nix взять вместо DOS и на чём писать если взяться за задачу грамотно?

Я правильно понял что вас устроит любая ОС, только не виндовс?

Если так, то я бы брал Linux, любой. В качестве СУБД (если уверены что нужна - FireBird )
А клиента писал на Java или С++ (Qt). Если любите паскаль можно посмотреть в направлении Lazarus...

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

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

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

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

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

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

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

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

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

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

А 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)

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