На текущий момент есть набор таблиц TClientDataSet, которые не подключаются ни к какой базе данных. Т.е. то что в них заполняют просто сохраняется на диск в виде файлов. При начале работы приложения эти данные загружаются в память. Причем во время работы приложения обращение к данным таблицам не происходит постоянно. По данным таблицы создаются объекты классов которые и используются в процессе работы программы (т.е. когда все объекты созданы, база просто занимает память). Объект класса создается в момент его первого вызова, т.е. если в процессе работы программы какой то объект долгое время не вызывается, то и объект этого класса создан не будет, а это значит, что обращение к базе может произойти не только при запуске программы, но и очень потом, причем неизвестно когда, в том числе и вообще никогда.

Задача: Хранить данные базы данных на удаленном сервере в интернете. На сервере есть FTP,MySQL(В принципе возможен вариант и с msSQL но не желателен), Apache. (хотя это может быть любой хостинг/сервер который продают в инете, предложения также приветствуются)

Варианты которые я вижу:

1) Хранить файлы, которые ныне хранятся локально на фтп и при старте программы скачивать их и загружать в программу. Проблема: эти файлы не должны сохраняться на локальном жестком диске пользователя, как бы этого достичь? Как сделать так, чтобы скачивать могли лишь те кто получил на это разрешение, а не все подряд кто знает по какому адресу лежат эти файлы(защита фтп паролем не вариант, сегодня ему можно качать, а завтра уже нельзя. Но программа которая будет качать написана мной). Опять же, если узнать пароль к фтп, то можно стырить все базы сторонней программой, что есть катастрофа.

Второй вариант для меня темный лес, я даже не знаю возможно ли это, но:

2) Хранить данные в MySQL и: выдавать их при запросе конкретного объекта? или при старте загружать сразу все таблицы?
Проблема: Количество баз MySQL на сервере очень ограничено, а количество наборов таблиц, которые необходимо хранить как раз таки ничем не ограничено. Значит все наборы нужно хранить в одной базе, как бы это вообще организовать. Та же проблема с доступом - т.е. сначала клиент должен получить подтверждение, что имеет право получать эти данные, а уж потом получать их. Что если таких наборов будет 1000+(и не меньшее количество клиентов будет их регулярно запрашивать, ну не так что бы целый день, но столпотворение возможно) как это все будет выживать? Реальное количество баз и количество ломящихся пользователей на данный момент оценить невозможно, но нужно быть готовым к тому, что количество пользователей будет измеряться в тысячах.

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

Каким путем пойти? и как к этому подступиться(если с первым вариантом более менее понятно, то со вторым нет)?
Какие еще есть советы, идеи, предложения?

> дабы сразу начать копать в правильном направлении.
правильных направлений много... неправильно "копать" поперек, из направления в направление, а не к цели.

вообще плевать в чем/где на сервере лежат данные, главное механизм получения унифицировать. типа трехзвенки что-то сделать (скрипт/ы на выдачу данных по запросу). по доступу вообще проблем нет, протокол будет использоваться http, раз инет, в нем есть стандартная авторизация... или можно https с сертификатом "вшитым"(/выдаваемым клиенту) в программу, а не сервером в процессе работы как обычно делается.
выдавать сертификат тем кто получил разрешение, стало нельзя - отозвать.

ftp лучше не использовать, ИМХО. будет невозможно изменить серверное место/способ хранения без изменений в клиенте. и возможность преобразований/динамических данных теряется.

> Хранить данные в MySQL и: выдавать их при запросе конкретного
> объекта?

если объект каждого класса представлен в одном экземпляре, то это напоминает синглтон с созданием по запросу.
Т.е. что-то типа
function GetInstance: TSomeClass;
begin
 if (FInstance = nil) then
   FInstance := CreateObjectFromDB;
 Result := FInstance;
end;

>а количество наборов таблиц, которые необходимо хранить как раз таки ничем не ограничено.
Каждому пользователю - свои таблицы?

> Каждому пользователю - свои таблицы?


нет. Есть некоторый набор баз данных 1 база это строго 4 таблицы (но он не фиксированный, и базы могут добавляться в неограниченных количествах, хотя думаю что скорей всего 100 таких баз это уже будет большое достижение, очень хорошее). Соответственно в разных базах разные данные на разные темы, хоть структурно они идентичны(базы эти). И пользователи получают данные из той базы, данные которой их интересуют. Т.е. к одной базе могут подключатся несколько пользователей.

Но если мы это храним в 1 базе MySQL, то получается все будут ломиться в 1 базу скульную (. А если еще и все базы свалить в 4 таблице на MySQL, то еще и к одним и тем же таблицам....при обращении к базе что блокирует MySQL - всю таблицу или запись? если таблицу, то видимо лучше на каждую базу отдельные таблицы делать.

> если объект каждого класса представлен в одном экземпляре,
>  то это напоминает синглтон с созданием по запросу.


Всего из данных базы создаются объекты не более 10 классов(в будущем это количество может сильно вырасти). Но в 90%, а то и в 99% все объекты относятся к одному из этих классов(и когда количество классов вырастет эта пропорция существенно врядли сильно  изменится).

>  к одному из этих классов


в том смысле, что почти все объекты это один и тот же класс и всегда одинаковый, т.е. типа TMyClass - вот большая часть объектов это он, всегда во всех базах )

>Sandro   (22.09.14 12:28) [4]
>Но если мы это храним в 1 базе MySQL, то получается все будут ломиться в 1 базу скульную
это нормально.

>при обращении к базе что блокирует MySQL - всю таблицу или запись?
рекомендую почитать документацию на используемый инструмент
напр., здесь: http://www.mysql.ru/docs/

и любой букварь по проектированию БД
и по реляционным базам, в принципе

2Sandro   (22.09.14 12:28) [4]
"Читатели", как правило, ничего не блокируют. "Писатели" блокируют не надолго, если правильно работать с транзакциями. И блокируют только изменение.
А как вы собираете и обрабатываете изменения разных пользователей?
MySQL - не единственная СУБД на свете.

>хоть структурно они идентичны
Я конечно всех тонкостей не вижу и потому знать их не могу, но, как мне кажется, добавив к 4 таблицам еще один справочник "тем" и таблицу "пользователи-темы" получится вполне тривиальная БД-шная задача.

>Sergey13 ©   (22.09.14 13:56) [8]
вводите в заблуждение неокрепший ум)

>"Читатели", как правило, ничего не блокируют.
это не так
кроме версионников есть блокировочники

>"Писатели" блокируют не надолго, если правильно работать с >транзакциями.
это не так, в общем
иногда возникает необходимость длительной блокировки записи

>И блокируют только изменение.
это не так, ибо - опят-таки - имеют место быть блокировочники

в частности, InnoDB Lock Modes:
http://dev.mysql.com/doc/refman/5.1/en/innodb-lock-modes.html

опят-таки)

> это не так

ключевое слово "обычно" :)

>Styx   (22.09.14 14:30) [11]
т.е. блокировочник - это "необычно"?)

С базами данных я таки работал, по большей части можно сказать как пользователь (ну то есть как программист, но в скуль я не лазил при этом) Поэтому как все может быть в хлам заблокировано, что никто не может достучатся я себе представляю. Так что учитывая что пользователей может быть тьма, то "не надолго" меня не успокаивает )


> Я конечно всех тонкостей не вижу и потому знать их не могу,
>  но, как мне кажется, добавив к 4 таблицам еще один справочник
> "тем" и таблицу "пользователи-темы"

об этом я уже задумывался


> "Писатели" блокируют не надолго


писателей по идее 1 штука на 1 логическую базу(ну то есть не скульную, а мои 4 таблицы), т.е. это не ограничивается, но скорей всего так и будет. Кроме того писать писатели будут крайне редко(я на это очень надеюсь, в противном случае сами дураки, я им так и скажу прям), и на это время базу лучше вообще сделать для читателей нечитаемой. Если часть данных загрузятся из старой версии базы, а часть из обновленной, то последствия могут быть непредсказуемыми.

Таким образом вариант читать каждый объект отдельно при возникновении необходимости на это - отпадает (а читать каждый объект из скуля при каждом к нему обращении в программе и пересоздание объекта класса вообще неприемлемо, т.к. скорость работы программы это ее главная фишка).
Т.к. когда считывается сразу вся база, то дальше программа может нормально работать, но если читаем пообъектно, и тут приходит писатель и шлет всех в сад, то программа зависает или вылетает по ошибке.  Минус же этого в том, что база висит в ОЗУ при этом....хотя можно переделать логику программы и выгружать ее после того как она уже не нужна.


> MySQL - не единственная СУБД на свете.


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

>Sandro   (22.09.14 14:58) [13]
MySQL вполне себе живёт в highload-системах
всё дело в ручках
но, впрочем, - "пилите, Шура, пилите"

Всë необходимое описано в [1].

2Sandro
>я на это очень надеюсь, в противном случае сами дураки, я им так и скажу прям
Это недальновидно, как минимум. Особенно в коммерческих системах.

2Кщд
Да много чего есть. Просто, ИМХО, уходить ТУТ в подробности конкретных реализаций пока (по крайней мере) не уместно. На данном этапе мне кажется, что сам подход "каждому пользователю по базе" не очень (мягко говоря) правильный.

>Sergey13 ©   (23.09.14 09:19) [16]
>сам подход "каждому пользователю по базе" не очень (мягко говоря) правильный.
такой подход, мягко говоря, неверный в корне)

такой подход мягко говоря единственно возможный ) В базе той содержится данные для скрипта который будет исполнятся. Каждый писатель пишет свой скрипт, он может сохранить его локально, а может на сервере, и как же я скрипты разных писателей в одну базу объединю?

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

> я скрипты разных писателей в одну базу объединю?

всмысле в одну логическую базу как объединю, да и смысла в том никакого нет, все равно нужно 1 от другого отличать.