Обращение к БД из потока

[xStill]

Добрый день! С базами данных работал не много, поэтому уперся в одну ситуацию:

Есть сервер (на TServerSocket), при подключении нового клиента - выделяется отдельный поток (одновременно работают около тысячи потоков).
Раньше все клиенты обращались к одной базе данных (открытой на главной форме сервера) каждый из своего потока - это работает прекрасно, но на данный момент возникла необходимость вести отделюную БД для каждого из клиентов (БД на парадоксе, работаю с ней через TTable).

Проблема состоит в том, что загромождать форму тысячей тэйблов - как минимум не логично, а обращение из разных потоков (каждый к своей БД) через один компонент будет создавать перекрестные запросы.

Вопрос: как организовать работу с большим количеством баз данных (по одной на каждого подключенного клиента)?

Буду благодарен за любую информацию. Заранее спасибо.

[Stilet]

А ты в каждом потоке создавай свой компонент для работы с БД.
Я лично так и делаю.
Например

unit Unit1;

interface

uses activex,
  Classes,adodb;

type
  wqeqwe = class(TThread)
  private    ado:TADOQuery;
    { Private declarations }
  protected
    procedure Execute; override;
  end;

implementation

{ wqeqwe }

procedure wqeqwe.Execute;
begin
 CoInitialize(0);
 ado:=TADOQuery.Create(self);
 ado.ConnectionString:=...
  { Place thread code here }
 CoUninitialize;
end;

end.

Ну и используй его. При освобождении потока компонент тоже освободит память.

[xStill]

Сообщение от Stilet

А ты в каждом потоке создавай свой компонент для работы с БД.
Я лично так и делаю.
Ну и используй его. При освобождении потока компонент тоже освободит память.

Спасибо, я об этом почему-то и не подумал
Но тут возникает другой вопрос: как быть со скоростью выполнения?
Create ведь займет довольно много времени. (возможно я не прав, если что поправьте) Проблема в том, что пока сервер будет создавать компонент и работать с ним, клиент будет ожидать ответа, что замедлит работу - поэтому время очень важно.
Вот если бы это:

 ado:=TADOQuery.Create(self);

выполнялось еще до старта потока... только не могу придумать как это организовать. Ночь не спал, голова плохо работает

[soleil@mmc]

придумай веселую заставочку с викториной и ценными призами
тогда никто тормозов не заметит

[Stilet]

Create ведь займет довольно много времени.

Чего это? Ниразу. Тормозить будет при получении набора по запросу, если СУБД настроена неоптимально, если набор огромен и прочие если, но никак не при создании объекта.

Да, поскольку это в потоке, я свой пример поправлю чуть, выделив моменты, без которых может заругаться.

[xStill]

Сообщение от Stilet

Чего это? Ниразу. Тормозить будет при получении набора по запросу, если СУБД настроена неоптимально, если набор огромен и прочие если, но никак не при создании объекта.

Я немного кажется ошибся Тут дело не совсем в конструкторе, а в работе компонента в целом. Дело в том, что я имел подобный опыт с другими компонентами. Может быть с компонентами БД совсем другое, но вот к примеру StringList сильно затормаживает подобные процессы даже при незначительном количестве данных.
Однако, попробую создать в потоке, может что и выйдет. Спасибо!

Сообщение от soleil@mmc

придумай веселую заставочку с викториной и ценными призами
тогда никто тормозов не заметит

Задумка конечно хорошая, однако в данном случае это не применимо. Это будет все равно что 3 секунды рекламы перед отправкой и получением каждого сообщения в ISQ.

[Stilet]

но вот к примеру StringList сильно затормаживает подобные процессы даже при незначительном количестве данных.

Ниразу не нарывался на тормоза при его создании. И ниразу не нарывался на тормоза при загрузке файла, даже были файлы по миллиону строк.
Ты что-то путаешь, либо программы пускаешь на слабеньких машинах.

[xStill]

Сообщение от Stilet

Ниразу не нарывался на тормоза при его создании. И ниразу не нарывался на тормоза при загрузке файла, даже были файлы по миллиону строк.
Ты что-то путаешь, либо программы пускаешь на слабеньких машинах.

Странно, может быть у меня что-то не то с системой (хотя машина более чем сильная). Сейчас начну старые проекты просматривать, может ошибку найду

[soleil@mmc]

в каждой шутке есть доля шутки
прежде чем критиковать предложенное (см. пост Stilet-а) стоит его опробовать

а тестировать лучше всего на самой слабой тачке
тогда вылезут косяки, которые на быстрой тачке вряд ли появятся при тестировании (собсна из-за несовершенства самого тестирования)