Предисловие:
Любая более менее серьезная программа имеет какие-то внутренние константы необходимые для ее работы. Часто эти константы необходимо изменять без внесения изменений в код программы. Для этого большинство юзают ini или реестр.


К примеру я в своих проектах себя приучил хранить такие константы в таком виде (если кому не понравилось сильно не пинать, ну можете положительно оценить задумку :), ниже описанное привожу скорее для новичков может кому навеет свежие мысли):
1. Храню константы (да и переменные) программы в древовидной структуре созданной с помощью Record;
2. Создаю отдельный юнит в котором описываются все типы и больше ничего:

пример

unit Unit_MyClass;

interface
uses Classes, SysUtils;
type
// куски записей основной записи настроек
TMessageRec = record        // параметры системных межпрограмных сообщений
WM_LogUpdate: Integer;
end;
//
TDB_one = record                // параметры подключаемых баз данных
DBType,
Path,
UserName,
Pass,
Note    : String;           // описание базы
end;
//
TDB_many = record                // параметры подключаемых баз данных
Num        : Integer;     // к-во подключаемых БД
Settings   : array of TDB_one;
end;

TAutoCallSettings = record      // параметры отзвона
ServerEnable    : boolean;
ServerPort      : integer;
URLBack         : string;
Retry_Count,
Retry_Timeout,
LifeTime,
Msg_NoCar,
Msg_CarWaiting  : integer;    // код сообщения
end;

/////////////////////

TSettingsRec = record
FTerminal  : record         // параметры формы терминала
Active   : boolean;
Left,
Top      : integer;
end;
AutoCallSet  : TAutoCallSettings;
DB_Orders    : TDB_many;      // параметры удаленной БД
DB_CC        : TDB_one;          // параметры локальной БД
DB_Log       : TDB_one;          // параметры локального лога
end;

implementation

end.

Обычно сначала описываю подтипы которые могут использоваться для передачи параметров процедурам и объектам (TMessageRec, TDB_one, TDB_many) а потом описываю основную запись которая хранит в себе все параметры программы TSettingsRec.
Чем удобно: а)описание типов и констант сведено в одном месте,б) при добавлении изменении констант все делается в одном юните с) «маленькие» собственные типы (н-р TDB_one) очень легко используются в процедурах функциях как параметры д) быстрое написание кода т.к. необязательно помнить дословно название переменных достаточно начать вводить и делфя сама будет показывать какие переменные у тебя есть и т.д. и т.п. для себя нашел неоспоримое преимущество такой организации хранения констант и переменных.
3. Объявляю в проге в одном месте (обычно var PS : TSettingsRec) от слова програм сетингс :) т.е. достаточно ввести PS. и интерпретатор вывалит что у тебя там есть.

Но это так лирическое отступление.

Программа уже давно выросла из пеленок и уверенно лопатит кучу баз данных и хочется хранить все константы программы не в ини файле а БД. У этого тоже есть ряд плюсов. Один из них это изменение констант в реальном времени без останова программы. Вот и начал я размышлять как бы это сделать чтобы было очень удобно и код проги значительно не менять.

Вариант первый.

Идея следующая (а вот тут жду жесткой критики или рац предложений :) ) :
В бд параметры хранятся в след виде:
FNAME FVALUE FTYPE
ServerEnable 0 b
ServerPort 80 i
URLBack http://forum.chertenok.ru s
LifeTime 10 i
Msg_NoCar 10 i
Msg_CarWaiting 10 i

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

function pp(name:string):variant;
begin
// здесь правда придется все время пробегаться циклом по єтому двумерному массиву в поисках имени а потом из соседнего столбца присваивать result значение
//красивее внутренностей процедуры не придумал, смущает этот цикл поиска т.к. констант может быть 30-40 штук и все время их лопапить как то не то, дырку в память протереть можно :--D
end

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

Итого: Хочется услышать ваши варианты хранения констант программ в БД в реальных проектах … и услыхать критику первого варианта, он вообще жизнеспособен?

Как Вы чаще всего храните настройки программы?

Результат

Загрузка ... Загрузка ...