SergSuperДаже если кому-то и удавалось заставить работать базу размером в гигабайт на SQL сервере быстрее чем файл-сервер, то еще не факт что автор сумеет повторить этот подвиг.
Особо не с чего им быстрее работать, а вот медленне - очень даже есть
Я бы не был так уверен. Все зависит от задач.
1Gb или 1Tb - не столь принципиально, а вот характер данных и требования к системе - факторы определяющие.

Sergey Ch FlareДля "серьезного проекта" , если надежность и безопасность имеют какое-то значение, я бы dbf-файлы не использовал, как настойчиво рекомендует Sergey Ch.
Автор основной упор делал на скорость, да и словосочетание dbf его вроде бы не пугает + размер таблиц просто мизерный... Как тут кто-то справедливо на форуме заметил "зачем городить огород на пустом месте"...
Судя по затребованным автором crete table, drop table, update - данные в базе будут время от времени меняться.
Не знаю каким именно опытом Вы предлагаете обменяться, поэтому рискну предложить свой немудреный: пользователи обычно не очень хорошо относятся к системам, которые могут внезапно погрести под своими обломками гиг данных вместе с последними правками.

ЛПЕще раз - с какой стати локальная однопользовательская база будет падать?
Для тупых повторяю - локальная и однопользовательская.
С какого ляда должно быть преимущество (с т.з. надежности) у (условно) оракла перед (уловно) фокспро? Проблемы с железом или софтом что там, что там - могут привести к сбою базы. И если не научились делать бэкапы, то что там, что там - рано или поздно увидим своими глазами страшную историю про "...под своими обломками..." и прочие ораклоидные сопли.
Ок, я туп, Ваш язык остер как бритва.
Жаль только, что Вы не даете себе труда задумываться о том, что пишете.
Однопользовательские базы независимо от "начинки" время от времени банально рушатся. Я это наблюдал не раз и не два.
Однако промышленные сервера (не только oracle, но и DB2, MSSQL, Informix и многие другие) позволяют восстановиться до последней зафиксированной транзакции . А не на прошлый месяц, когда делался последний бэкап.
И в этом разница.
А сопли вы лучше своим клиентам утирайте.
:/

ЛП Однако промышленные сервера (не только oracle, но и DB2, MSSQL, Informix и многие другие) позволяют восстановиться до последней зафиксированной транзакции .
Если бы все было так шоколадно, то и бекапы бы никогда не делались на "промышленных базах", не правда ли?
Нет, однако же, бекапы делаются. Видать не всегда базы умеют восстанавливаться "до последней зафиксированной транзакции", а только иногда.
ЛП, Вы просто не знаете о чем говорите, и данный пассаж - лучшее тому подтверждение .
Вы не поймете - и даже ответите что-то, на Ваш взгляд, остроумное.
Но есть здесь и специалисты, которые знают о чем речь - они просто над Вами тихонько посмеются.
Удачи.

kdvВы уж если такие утверждения пишете, уточняйте, что будет если побьется база, если побьется лог транзакций, и т.п. Или сами представьте себе эти ситуации.
Ага, весь administration guide сейчас процитирую.
Разница-то тривиальна: в одном случае можно вернуться только к моменту backup, в другом - на любой момент времени после backup.
Кто не видит разницы или спекулирует на необходимости делать backup или ее отсутствии - сами себе утешители :)

kdv авторРазница-то тривиальна: в одном случае можно вернуться только к моменту backup, в другом - на любой момент времени после backup.
Андрей, вы слушаете что я говорю? Если у вас ДИСК умер, СГОРЕЛ СЕРВЕР или еще что - откуда и куда вы "вернетесь"???
kdv, вернитесь плиз в контекст беседы - выбор СУБД, а не регламент резервного копирования.
Или Вы полагаете этот топик правильным местом для рассмотрения вариантов disaster recovery? Если интересно - загляните в доки оракла, найдете и про наводнения, и про пожары ;)

AndrewwЗачем же так достаточно (в Оракле,например,) просто потерять активную журнальную группу
Все до единого файлы группы . Это не так просто :)