Идея такая: засунуть в базу всё, кроме исходников компонентов, даже иконки. Кроме того, сделать список компонент общим для всех пакетов, с возможностью назначать компоненты пакетам, как это сделано с компиляторами. Хинты нужно также хранить в отдельной таблице, для каждого языка - свои.

И какие в этом плюсы?

я понял так: многоязычие, исключить дубли иконок для пакетов, тоже может касаться help-а

Я опять про локализацию. Чтобы сделать хинты зависимыми от выбранного языка, их лучше поместить в базу, соответственно точки и свойства компонентов тоже пойдут туда, т.к. хинты к ним привязаны, т.е. помещаем .ini файлы компонентов в базу. Список проектов - аналогично. Имена пунктов меню (хинты к командам) - тоже. Настройки компиляторов и привязка их к проектам. Иконки - чтобы не было милиона мелких файлов. И чтобы они не дублировались для пакетов, можно сделать один общий список компонент, и привязывать их к пакетам, как компиляторы. Можно даже автоматом, если присутствует файл hi<Имя компонента>.* в каталоге code.

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

Компонент идентифицируется по своему имени. Каким образом база данных поможет хранить разные его версии?

В отдельной таблице можно хранить разные версии программного кода компонента, идентифицируя его по коду версии или тройке (пакет,имя элемента,хэш):
CodeVersion (codevers_id,packet_id,elem_id, vers, date, hash, code_text)
При выборе пользователем соответствующей версии code_text записывается в файл. Изначально, эта таблица может быть пустой, но при установке новой версии, старую нужно будет тоже сохранить. А можно хранить код только в базе, а в файлы используемых компонентов записывать временно, до тех пор пока HiAsm не закроют.

Пожалуй идея размазать ini файл по некоторой структуре BD имеет больше плюсов, чем минусов. Действительно проблема локализации решается почти автоматом, кроме того появляется "бесплатная" возможность организовать наследование методов и св-тв(вечная проблема для Win элементов), ну и избавиться от дублирования всего, что только возможно.

Кстати, по поводу базы: идентификатор элемента лучше всё-таки сделать числовой, а не строкой, а эту имеющуюся на данный момент строку обозвать как prog_id.

А будет-ли общий список компонент с привязкой к пакетам?

Не вижу пока более менее логичного постраения структуры БД, при котором учитывается возможность попадания одного и того же компонента в разные пакеты с условием, что один из пакетов поддерживает только часть его св-тв/методов.

Дополнительные таблицы:

PropertyConPacket (prop_id, packet_id)
MethodConPacket (method_id, packet_id)

Получается примерно так:
------------------------------------------------------------------------------
Основная таблица конфигурации элемента(ElementConfig)
id  name  author  mail  version  class_id  info_id  sub

Таблица св-тв(Propertys)
id  name  info_id  type  value  list

Таблица методов(Methods)
id  name  info_id  type  data_type

Таблица описания св-тв элемента(ElementPropertys)
el_id  prop_id  default  tomethod  pos

Таблица описания методов элемента(ElementMethods)
el_id  mt_id  visible  pos

Таблица возможных классов элемента(ElementClasses)
id  name

Таблица групп св-тв элемента(PropGroups)
id  name

Таблица наборов св-тв, входящих в данную группу(ElementPropGroups)
gr_id  el_id  prop_id

------------------------------------------------------------------------------
Набор пакетов(Packs)

id  codename  name  info_id  units
Набор компиляторов пакета(pack_compilers)

pack_id  cmp_id  active
Набор проектов пакета(projects)

id  pack_id  entry  name_id  info_id  ext  make
Набор элементов пакета XXX(XXXPack)
(копия Elements.db с числовым полем id)

Запрет на показ методов элементов пакета(DisableMethods)
el_id  mt_id  pack_id

Запрет на показ св-тв элементов пакета(DisablePropertys)
el_id  prop_id  pack_id

------------------------------------------------------------------------------

Набор меню и панелей управления(menus) id  name  info_id

Команды среды(commands) id  name  info_id

Содержимое меню и панелей управления(menu_commands) menu_id  cmd_id  pos

------------------------------------------------------------------------------

Локализация(Localization) id  pref  info  active

Локализация названий языка XXX(info_id_XXX) (именно сюда ссылаются все поля info_id) id  info

------------------------------------------------------------------------------

Компиляторы(Compilers) id  name  cmd  path  ext

------------------------------------------------------------------------------

Привязка расширений к редакторам(ext_assign) ext_name  ext  info_id

------------------------------------------------------------------------------

- реализованы

А почему отдельная таблица для каждого пакета, почему бы просто не добавить pack_id в таблицу, то есть не копия Elements.db, а пара (pack_id, el_id), аналогично PackCompilers? А для локализации можно тоже сделать одну таблицу LocName (например с общеупотребимым английским названием), но добавить таблицу с переводом для каждого языка LocText (lc_id, info_id, lc_text) и если нет перевода для выбранного языка - использовать английский эквивалент (запрос будет с left outer join).

если нет перевода с какого языка

... с английского

При такой структуре удобнее хранить все в одной базе.

Перевод впринципе можно и в одной таблице хранить.