Господа! поделитесь опытом.
Вопрос о том как в WINDOWS организовать использование оперативки.
Дело в том, что я почти 10 лет получаю зарлату не за программирование,
но при этом, то и дело, писал программы на "DOS_овском" PASCAL_е(BP7).
Этого хватало пока база была на FOXPRO. Выкладываешь ярлык на рабочий
стол, выделяешь в свойствах EMS, запускаешь программу и то что
официальная программа выполняла за 3-5 часов проходит за 10-15 минут.
Плюс к тому, получаешь любые варианты выборки и анализа, которых нет
в основном проекте.
Собственные наработки позволяли кодировать за несколько часов-дней
(главное идея!). Теперь база на SQL плюс BASIC.
Поставил у себя DELPHI и BUILDER C++, сделал вывод, что "творить"
надо на дельфи, а потом смотреть как это будет на CPP.
Пора начинать, но как в новых (виндовых) условиях рационально использовать оперативку?
Раньше GETMEM_ом брал в основной памяти под буфер размером 3 записи
на каждый файл, буфер 16К для индексирования, все остальное делил
между файлами по принципу: короткий файл (справочник) полностью,
остальные пропорционально заданному при описании минимальному числу
записей.
Все это заполнялось и выбиралось при помощи указателя и специальной
функции, которая сдвигает его, а все файлы не типированы, открыты
с буфером в 1 байт (кроме индексных).
ООП - технологии не применял, желание иметь под руками полную
информацию приводило к написанию собственных процедур и функций взамен
стандартных. Например: при нажатии клавиши всегда имеем код символа, номер клавиши, функциональную клавишу, флаги клавиатуры в момент нажатия (Если кому интересно, могу показать как); прямой вывод на экран,..

Честно говоря это первый мой пост в И-НЕТ_е. Послал ответ, да видно что-то не срослось - не вижу на экране.
Глубинная идея в том, чтобы меньше обращаться к диску, надо наилучшим образом юзать оперативку, и чтобы одна процедура обрабатывала хоть 5 хоть 500 таблиц на машине с памятью хоть 2 Гига, хоть 256 Мег. А чтоб это автоматизировать нужна какая-нибудь стратегия анализа памяти и ее распределения между данными. Вот с этой стратегией и хотелось определиться.

Я имел ввиду оперативную память, а виртуальная, как я понял - файл подкачки на диске. До 4 Гиг совсем не плохо, но не совсем то, хотя случай, если у компа 256 Мег, а хотелось 512 вероятно снимет с повестки дня.

Кроме чужого, не всегда удобного SQL, хотелось своего анализа на станции.

Спасибо Lelikk! Теперь понятно, что мой вопрос не столь актуален для современных ОС.

Processor "Оптимизировать время исполнения надо всегда, а память - только тогда, когда её нехватает".
... оптимизацией тоже надо заниматься только тогда,
когда ожидание результатов запроса вносит дискомфорт в работу пользователя.
В остальных случаях следует стремиться к ясности (простоте) кода.

Мне всегда казалось, что время исполнения зависит от оптимизации памяти,
по крайней мере при частом обращении к зависимому файлу, и я стремился поступать так: для обрабатываемого файла приемлемый буфер, а те на которые он ссылается - максимально в оперативку.

MLeonА если переходите с DOS, то помните, что Вы не один. И если уж на то пошло - распределением физической памяти занимается только Windows. Единственный вариант управлять ей самому - драйвер (не рекомендую).
Раз не один, то тем более, пусть и другие почитают.
Но тем не менее, возможно ли делать комбинированного клент - файл сервера?
База в дюжину гигов, надо запустить сложный процесс, а если их несколько? Ясно, что все они пойдут на сервере, и будут идти более суток, а то и вовсе "подеруться". Так если скопировать часть таблиц на клиента, обработать, и толкнуть обратно на сервер. Конечно, это относится только к тяжелым процессам.

S.G.
Нынешние диски, это совсем не то, что раньше. Последний раз, когда я замерял свою супер-пупер-программу, делающую сортировку большого текстового файла на диске, оказалось, что на диске получается быстрее, чем на виртуальном диске в памяти. Вероятно, кеш дисковой памяти работал лучше, чем организация виртуального диска ;)
Да, в EMS все работает не слишком быстро, скорость на уровне современного винта (поэтому сортировку делал кусками в пределах Conventional quicksort_ом, а затем сливал в один файл). Сейчас об этом у людей вообще голова не болит. Хорошая новость.

softwarer
Главное же - при этом переходе придется забыть о накопленных технических приемах и учиться работать именно на "дельфе под виндой". Со времен выхода BP7 все настолько изменилось, что любые привычки BP7+DOS можно априори считать неудачными.
Вот данный топик и помогает мне развернуть мозги (думать иначе). За что спасибо всем участникам. NotGonnaGetUs и S.G. тоже.

softwarer... - очень похоже на госпредприятие, компьютеризированное в ... - начале девяностых ....

Вы правы! Т.е. программы мы не выбираем, а надо делать выборки со сложными условиями. Пользователь делает это вручную за определенное количество дней, с определенным количеством ошибок. Хочу привести пример, хоть я и понял, что на форуме лучше не выходить за пределы темы. Открыть новый топик? Не уверен, что это можно решть.

1.Таблица с данными - вертикальная (там показатели всех документов всех типов, одним словом винегрет). На самом деле несколько таблиц, где разделены данные документа, плюс все это по годам.
2.Таблица, где описаны строки каждого документа (несколко сотен на каждый)
3.Таблица со списком документов (несколько десятков).

Так вот, выбирать надо из первой горизонтально , сделав примерно 15 граф по условиям из второй и документу из третьей, при этом где-то 7 раз связываю таблицу саму с собой. Делаю запрос.
Результат: 2 "автосвязывания" - 2 минуты;
3 - 35 минут
4,... - вылетает в ошибку минут через 15.

Таким образом возможности сервера по оптимизации вызывают большие сомнения.

Processor...рациональной индексацией никто не занимался.
За счёт каких механизмов ожидается ускорение связывания?
Почитал вот это
synapseтак зачем геморой себе отращивать, раз на sql перешли вот сервак, если толковы будет заботиться о памяти и рациональном использовании ресурсов.
и сформулировал запрос с кучей join_ов.
Механизм для ускорения связывания? Это предварительное создание временной, более короткой таблицы? Или составление такого запроса, что, например, если в нем (запросе) общий Join с третьей таблицей, то все остальные связывания с собой будут происходить с учетом условия этого Join (а может условие сработает только после того, как все соединит)? Или это что-то еще?

Processor Ещё несколько аргументов к теме оптимизации.
В частности, оперативной памяти...
К сожалению не имею интернет. SQL.ru - "все что могу" ((с) -"Гоячий снег").

Processor----- The following addresses had permanent fatal errors -----
<adm6820@r68.nalog.ru>;
(reason: 550 5.7.1 Access denied)
Ящик не у меня. Serg появится в ближайшие дни, обещал разобраться. А вообще -то письма туда приходят.

Processor
www.sql.ru/articles/articles.aspx "Оптимизация – ваш злейший враг".
... Реферат почитал, мысль выражена верно, можно только добавить, что это как шахаты - просчитываешь вперед на сколько фантазии хватает. А потом узнаешь, что пока гонялся за ладьей, потерял территорию.
Жаль, что к моей машине не подключен модем, и сотовый без GPRS, ведь до самой статьи не достучался. Подождем.

Processor
Вышестоящая закрыла все домены, кроме .ru