Начал писать одну программу, продумываю концепцию, но мне непонятна пара моментов...
1.Смысл программы - имеется список имен, при клике по имени - на label кладется картинка соответствующая этому имени, в текстовое окно кладется описание, соответствующее имени и т.д.

2. Непонятно -

а)Как хранить этот список - просто текстовый файл или xml ?

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

Вот теперь основной вопрос к профессионалам - концепция верна, или сделано через одно место?

Бд-бд...
То есть стационарная ODBC?

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




А я так и хотел сделать...

А обновление я собирался написать так - все новинки публикуются у нас на сайте, и к MySQL хостинга есть доступ извне, вот я и хотел написать модуль коннекта к ней, для проверки обновлений.

Ну-с, будут еще версии?

Наверное, "стационарная ODBC"=стационарная СУБД???

Можно и через нее (СУБД)... вопрос - кому и как это приложение будет распространяться... будет ли у пользователя желание поднимать эту базу?

Вопрос другой - а не проще ли юзеру с сайта всё посмотреть? Или целесообразность разработки такой вытекает скорей из желания поиметь новые скиллы программинга, нежели создать меганужное ПО???

"и к MySQL хостинга есть доступ извне, вот я и хотел написать модуль коннекта к ней, для проверки обновлений. " = грузиться всё будет с сайта и смотреться потом на стационарном компе? такая задача?  Когда определимся с этим - дальше - больше.

P.S. Пардон за сленг и  словоохотливость - день такой выдалася

Структуру SQL можно повторить и в локальном приложении.
Хранение в файлах:
Элементы (elem.dat):
pk, name_len, name
...
Описание (desc.dat):
pk, fk_elem, desc_len, desc
...
Картинки (pict.dat)
pk, fk_elem, path_len, path
...


path - путь на внешнюю картинку. Текст занимает немного места, его можно за один проход полностью подгрузить в программу, а вот картинки лучше хранить отдельно...
Можно и в одном файле с разделителями. Скажем, pk может принимать значение от 0x0000 до 0xFFFE а разделитель 0xFFFF.
Я так делал для тестирующей программы, которую в своё время писал.

Можно, конечно, хранить и в xml, но так все данные хранятся в бинарном виде...

to Namelles One:
Если тебе так уж очень хочется, то можешь написать свой движок, для работы с данными, хранимыми в файле, только  все равно любую СУБД по оперативности и эффективности доступа ты не переплюнешь.  P.S. Ты сам-то сколько думал над своей задачей???

Возможно, я повторю отчасти Вудруф, но все же.

Мои предложения по планируемой разработке...

Храним в файле построчно (имя его, например, conf/main.dat):
<id элемента1>, <имя_картинки1>, <ее описание1>,<имя файла с картинкой1>
<id элемента2>, <имя_картинки2>, <ее описание2>,<имя файла с картинкой2>
.....

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

В отдельном файле (например, ini/update.inf) желательно хранить дату(отсчитываемую во временнОм пространстве сервера) последней загрузки. Каждый раз ее апрейдтить после загрузки.

Картинки хранить в папке img. Имена файлов картинок дополняются "img" слева.

Имена оставляем теми же, что они были на удаленном серваке (на всякий случай, потом мож пригодится).

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

То, как это всё фентезийное хозяйство отображать - на свой вкус. Можно древовидно, можно просто комбо, можно таблицу... смотря сколько их... дело чувства юзабилити.

Апдейт - это коннект к удаленной майскуюль базе с запросом типа:
select id, label, desc, fpath where dateIns>[время последнего апдейта из файла ini/update.inf].
Так мы получим список новых картинок с их описаниями и прочим.
И качаем далее из папки удаленного сервака файлы имена которых мы только что выбрали. Только после того, как мы все закачали - апдейтить реальные файлы данных (список инфы, дату). И теперь апдейтим онлайн данные для отображения.... Можно, конечно, еще подумать насчет дозакачки как файлов, так и их частей, но это уже предлагаю потом. Пока и этого хватит. Какими средствами расти дальнейшему функционалу уже заложено (АйДи картинки).

ИМХО

А ещё можнo глянуть в сторону sqlite. Вроде как база
(+) работа через SQL
(+) существует везде (Win,Lin)
(+) ничего не надо мудрить с ODBC
(+) картинки можно хранить прям в ней...

Нет, Qt устоена так, что ты запуская прогу пишешь в запросе, после коннекта структуру базы через SQL. Далее работаешь, пишешь в неё данные.... Закрываешь прогу. Запускаешь прогу снова .... оп вуаля...
драйвер устроен так, что если файл уже существует она его не перетирает, а просто коннектиться и всё...
Да, ещё момент, если ты поменяешь структуру базы, тебе надо будет, чтоб она поменялась прибить старый файл...
 
Сам был приятно удивлён... Тож парился чегож сделать чтоб файл остался, но как оказалось Тролли подумали за нас...