Файлы, списки и прочее...

[Namelles One]

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

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

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

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

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

[Steven_Orko]

А поподробнее? что за программа?  Основная цель ее создания?

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

Вполне возможно, что нормальная, если данных мало.

Что такое "имя"? Название чего-то? Картинка - это фото того, что определено в названии??? Ну, а в текстовое окно кладется тогда более подробная информация? Если так, то хранить можешь, где угодно. Хоть в бинарном файле, хоть в БД. Только вот как картинку ты хранить в XML будешь??? Можно только путь к ней указать(ИМХО).

Судя по всему, твоя прога что-то наподобии справочника. Посмотри, как организованы подобные справочники. Если инфы много, и планируется ее добавление, редактирование, удаление, а твоей программой только просмотр, то (ИМХО) для хранения данных лучше использовать БД. Потом и расширить сможешь...

[Namelles One]

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

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

вот как картинку ты хранить в XML будешь??? Можно только путь к ней указать(ИМХО).

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

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

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

[Steven_Orko]

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

Интересно, что ты понимаешь под словосочетанием "стационарная ODBC"??? Это вообще как? :?:

[D_N_S]

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

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

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

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

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

[Namelles One]

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

Э ну да-да, конечно, совсем уже зарапортовался...
Вся эта энциклопедия и так уже доступна на сайте...
Но мало-ли вдруг, понадобиться описаниЕ, а доступа к инету нет, вот и пришло предложение написать оффлайн версию...

будет ли у пользователя желание поднимать эту базу?

Именно поэтому и не хотел бы связываться с этим...

грузиться всё будет с сайта и смотреться потом на стационарном компе?

Нет энциклопедия будет полностью локалная...
Через БД сайта будет сделан только модуль обновления...
Но это потом, пока надо оффлайн-часть написать...

[Вудруф]

Структуру 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, но так все данные хранятся в бинарном виде...

[Namelles One]

Хм...
То есть получается, что при открытии программы делается проход по файлам, и вся инфа грузится в оперативку по массивам, а потом уже юзается?

[Steven_Orko]

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

[Namelles One]

все равно любую СУБД по оперативности и эффективности доступа ты не переплюнешь.

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

P.S. Ты сам-то сколько думал над своей задачей???

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

[D_N_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].
Так мы получим список новых картинок с их описаниями и прочим.
И качаем далее из папки удаленного сервака файлы имена которых мы только что выбрали. Только после того, как мы все закачали - апдейтить реальные файлы данных (список инфы, дату). И теперь апдейтим онлайн данные для отображения.... Можно, конечно, еще подумать насчет дозакачки как файлов, так и их частей, но это уже предлагаю потом. Пока и этого хватит. Какими средствами расти дальнейшему функционалу уже заложено (АйДи картинки).

ИМХО

[Namelles One]

Хм...
ну что же, ИМХО, последний пост наиболее юзабельный...

D_N_S
Пасибо, помог мне мои мысли в порядок привести и дополнить их...

Если еще какие-либо вопросы возникуть - задам...
Всем спасибо...

[Sergey B.]

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

[Namelles One]

Sergey B.

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

[Sergey B.]

Sergey B.

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

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