Вопрос может показаться несколько странным, но... есть что хранить: строчки (байт по 65), строковой параметр (байт так 15) и дату (но можно может быть и обойтись).
Раньше была база Access, подрубленая через ODBC. Для обращения из Делфи юзал TConnections, TQuery и всякие датасурсы. Скорость явно не устраивала (может быть я не умею работать с БД), т.к. выборки и выгребания данных занимали около секунды на 50 (да, всего 50) Мб базе. То ли опыта работы с БД мало, то ли компоненты медленные, то ли ОДБЦ. Я вот думаю, может быть быстрее было бы вручную обрабатывать файл сообственного формата? У меня есть ещё как вариант раскидать всё в текстовики, в имени которых будет содержаться параметр и работать как с набором строк. Время критично, а всякие ODBC, BDE не переношу =(

Подскажите плз способ хранения данных... В проектировании БД ошибки исключены, т.к. просто нечего проектировать. Одна табличка и два-три поля.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

AlexZ пишет:
У меня есть ещё как вариант раскидать всё в текстовики, в имени которых будет содержаться параметр и работать как с набором строк.
...таким образом указывая имя файла уже получаем доступ к нужному контенту, который остается отсортировать по строкам. Этот параметр - имя юзверя. Таким образом не надо выбирать из общей таблицы (если бы было в одном файле) ещё и по имени юзверя, а это значит что мы экономим время.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

Получается самый выгодный вариант - это хранение на каждого юзверя по БД с одним единственным полем? Тогда может быть нет смысла подключать 25 БД, а скидывать инфу в текстовики? Так бы и сделал (Вася.txt, Маша.txt ... против Всеюзвери.DB), но:
1) Нужно определять когда последний раз активничал юзверь, для этого придется подгрузить файл в память и достать последнюю строку с записью о том, что делал Вася. Загрузка всего файла в память себя не оправдывает по времени. Как вариант: считать последние 100 байт и вытащить строку (т.к. последняя строка 100% окажется последней в файле и чтобы на неё попасть считаем с запасом).
Другой вариант решения: Хранить записи в файлах типа Вася_01.01.07.txt. Всё классно, файлы будет маленькие (но много), но:
2) Чтобы найти последние махинации Васи, надо перелистать файлы в директории Васи начиная с текущего дня до минус бесконечности(до количества файлов), пока не найдется нужный файл. Снова время.
Пока догадался только до того, чтобы хранить дату последнего похождения Васи в LastItem.txt и тогда я точно буду знать в каком журнале истории искать последнее действие Васи, либо каждое действие Васи считать как последнее и перезаписывать LastItem.txt каждый раз...

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

Почему нормальную СУБД заюзать не хочешь? Visual FoxPro, например?

| Сообщение посчитали полезным:

AlexZ
Попробуй FireBird его можно как многопользовательску и как Embedded, работать можно с FIBplus,IBX все можно почитать на ibase.ru. Я думал остановиться на DBISAM, но эта СУБД - это рай !

-----
My love is very cool girl.

| Сообщение посчитали полезным:

AlexZ
По суди сам! Табличка одна и полей не много, создашь нужные индексы по тем полям по которым будешь искать значения, ну и индексы на уникальность, если надо и все будет очень хорошо. При само-пале, тебе:
1) открыть файл
2) Влоб,полным перебором, весь файл надо перебирать при поиске чего либо

-----
My love is very cool girl.

| Сообщение посчитали полезным:

Немного поправил третий постенг... думаю...

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

YDS, фокспро не знаю, тем более что управлять БД - это побочная функция моей проги, основные реализованы, а здесь запнулся =(

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

theCollision пишет:
1) открыть файл
2) Влоб,полным перебором, весь файл надо перебирать при поиске чего либо
Я так и делаю... наверное это не оптимально.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

theCollision пишет:
2) Влоб,полным перебором, весь файл надо перебирать при поиске чего либо

Ну лучше сортировать по имени и искать методом деления списка пополам - в разы быстрее будет.

| Сообщение посчитали полезным:

AlexZ
Я не совсем понимаю твою задачу и предметную область. Опиши четко, что тебе надо хранить и какие действия с этой информацией делать(выборка,модификация, удаление) и характеристика действия(удалять каждые 10 сек. старые записи или др.). Вобщем опиши все что тебе нада!

-----
My love is very cool girl.

| Сообщение посчитали полезным:

AlexZ, если у тебя несколько тысяч записей и надо сделать что-то типа

select * from connections where user="Bob" and startTime>ABC and startTime<XYZ

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

Я пользуюсь sqlite - там есть SQL syntax, и индексы и операция типа описаной выше происходит очень очень быстро (индексы будут в памяти, и алгоритмически это намного оптимальне линейного поиска. Ну а с диска тоже считывется только то, что надо). Ну и весь движок мелкий и линкуется к проге.

| Сообщение посчитали полезным:

> Ну лучше сортировать по имени и искать методом деления списка пополам - в разы быстрее будет.

Полностью согласен, разве что не в разы (имхо) а на порядок-два.

Не так уж сложно сделать свои индексы, даже многокомпонентные (а тут вроде задача простая). Однака на перспективу использовать движок sql или курсорную типа btrieve конечна лучше.

-----
The one derivative you manage is the one I abhore (c) Slipknot

| Сообщение посчитали полезным:

AlexZ
Без индексов никуда. Только если сам реализуешь более менее приемлимые. На хрена ODBC? Юзай сразу ADO + MS Access, либо какую-нить embedded субд (FB / SQLite). Скорость по сравнению с вариантом BDE / ODBC намного выше, да и масштабирование проще.

| Сообщение посчитали полезным:

Перечитал еще раз, на свежую утреннюю голову! И понял, нефиг тебе изобретать велосипед!
Бери FireBird на пориод отладки делаешь его SQL - сервером, как оттестируешь, заменяешь на Embedded версию! Для удобства проектирования базы используй www.sqlly.com/index.ru.html. Работать можно, как я уже говорил, IBX или FIBplus, которых в нэте на ура найти!

Еще раз: Зачем изобретать грабли,если они уже есть?

-----
My love is very cool girl.

| Сообщение посчитали полезным:

theCollision пишет:
Еще раз: Зачем изобретать грабли,если они уже есть?
'Универсальные грабли' редко оптимальны для частной задачи. Может быть выгоднее использовать простой собственный движок (особенно, для записей фиксированного размера) с индексами на B+Tree. Если нет времени на свое - взять что-либо типа Berkeley DB.
SQL для задач с простыми фиксированными запросами - абсурд.

| Сообщение посчитали полезным:

theCollision пишет:
Перечитал еще раз, на свежую утреннюю голову! И понял, нефиг тебе изобретать велосипед!
Бери FireBird на пориод отладки делаешь его SQL - сервером, как оттестируешь, заменяешь на Embedded версию! Для удобства проектирования базы используй www.sqlly.com/index.ru.html. Работать можно, как я уже говорил, IBX или FIBplus, которых в нэте на ура найти!

Еще раз: Зачем изобретать грабли,если они уже есть?
Совет дельный - для одной таблички получишь всю мощь клиент-серверной технологии + к своей программе файл базы минимум на 400 кБ (если постараешся и повыкидываешь ненужные системные таблички) + 2 мега fbembed.dll . Если всё-таки БД, то лучший вариант VolgaDB (volgadb.ru, там есть исходники Prof версии - бесплатно) - exe-ник увеличится примерно на 400 кБ, формат базы очень оптимизирован и компактен Acces, DBASE, Paradox и пр. отдыхают (+ есть возможность шифрования), все операции в thred-ах - скорость поразительная, быстрее не найдешь, самое главное не надо ничего лишнего - весь движок будет в твоём EXE-ике.

| Сообщение посчитали полезным:

gazlan
И пока он будет его писать, убьет уйму времени на отладку! На фига? Для частной задачи FireBird наилучшее решение, т.к. часто обновляется и поддерживается, есть саппорт если что-то не так, всегда помогут!

Почему то буржуи во многом впереди нас, а причина в том что они делают узкий круг задач. У них ООП подход, компонентное мышление, типа Вася делает ЦПУ, Толя делаер ОЗУ, А я буду материнки. У нас же разработчик стремистя сделать все сам и из-за того что раскидывает либо делает через ж... либо тратит много бабла.

Если автор темы пойдет по пути изобретения самопала это опять будет лишняя трата времени! Если уж так захотелось, то думаю лучше будет применить xml-формат, и в дельфи XML-Binding будет делать за разработчика всю черную работу! Разработчику надо будет только разработать структуру 2) направить xml-файл на xml-binding 3) Применить готовый после биндинга компонент

-----
My love is very cool girl.

| Сообщение посчитали полезным:

theCollision пишет:
И пока он будет его писать, убьет уйму времени на отладку! На фига?
IMHO, потребность в собственной маленькой DB возникает очень часто. Для нескольких сотен записей можно еще обойтись коллекцией в памяти, но для нескольких миллионов нужно что-то другое. Сделав (и отладив) один раз инструмент 'по руке', потом можно использовать его во многих проектах. Собственно, само обилие предлагаемых движков доказывает, что устраивающего всех решения так и нет.

| Сообщение посчитали полезным:

AlexZ
Могу посоветовать юзать SQLite. В частности для Delphi есть очень удобный компонент - DISQLite3.

DISQLite3 is a self-contained, embeddable, zero-configuration SQL database engine for Borland Delphi:

- Compiles into exe, requires no DLLs.
- Implements most of SQL 92.
- Small, about 200 KB code size only.
- Compact, single file database format.
- Excellent performance &ndash faster than other database solutions.
- Up to 2 TB database size.
- Unlimited table, record, field counts.
- ACID transactions: Atomic, Consistent, Isolated, and Durable.

Для описанных тобой задач подходит как нельзя лучше. Скорость работы нареканий не вызывает, юзаю постоянно и никаких проблем. Не надо никаких ODBC, BDE и т.п. DISQLite3 - локальная БД. Все данные хранятся в одном файле.

| Сообщение посчитали полезным:

theCollision пишет:
Разработчику надо будет только разработать структуру 2) направить xml-файл на xml-binding 3) Применить готовый после биндинга компонент Избавьте )
intro пишет:
В частности для Delphi есть очень удобный компонент - DISQLite3.
Почти 300 баксов =(
Прога будет коммерческой, на работе пишу.
theCollision пишет:
Почему то буржуи во многом впереди нас, а причина в том что они делают узкий круг задач. У них ООП подход, компонентное мышление, типа Вася делает ЦПУ, Толя делаер ОЗУ, А я буду материнки. У нас же разработчик стремистя сделать все сам и из-за того что раскидывает либо делает через ж... либо тратит много бабла.
Соглашусь. Ну уж как есть. Хотя грустно такое читать, потому что ООП подход будет означать что учишься ты например на "разработчика delphi классов для работы с базами фокспро" (ну допустим) или что ещё хуже, это может сойти на "разработчик классов для занесения записей в БД"... и всё, одним и тем же занимаешься: шаг вправо-влево сбивает в пропасть, где ты ничего не можешь сделать. Вот с такой же жо я столкнулся при работе с компонентом, и это как раз пример мышления "спецов" узкого профиля (с части "ADO и файлы формата MS Access"):
www.codenet.ru/progr/delphi/ado/

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

Я думаю что мне надо просто побольше почитать о приемах работы с TTable ADOtable и проч.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

AlexZ
А mysql не подойдёт тогда? Она вроде бесплатна.

| Сообщение посчитали полезным:

Чем больше компонент написано, тем сложнее в них разобраться... Сейчас у меня табличка:
TMyRec = record
UsrName:string[16];
UsrAction:string[64];
end;
Тупо сам изготавливаю движок БД с необходимыми мне функциями. Добавил 1000000 (мульён) записей за 10 секунд при 100% загрузке 1.6 ГГц и 1 Гб памяти, в результате чего файл вырос из нульвого размера до 75 Мегов.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

Скорее всего буду хранить данные в виде "Вася.db, Маша.db..." и ограничить на размер, т.е. при наступлении конца файла начинать запись в бошку. Поговорил с коллегами (один из них фокспрошник и делфиец), говорит что без разницы: поднимать ли БД сервак или делать всё ручками, только ручками будет быстрее (как в плане создания так и в плане работы) и понятнее, а с компонентами пока разберешься...

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

Заинтересовался нашим производителем
Зашел на hххp://www.volgadb.com/
Вы можете выбрать любой из вариантов:
бесплатный Lite вариант - работа только с TVolgaTable для Volga файлов.


Lite вариант VolgaDB Engine (Delphi, C++Builder) состоит из компонент TVolgaTable и TVolgaDatabase.
Основные возможности:
доступны все стандартные свойства, методы и события TDataSet, возможна работа с любыми визуальными DB-aware компонентами;
быстрый доступ к данным без BDE, компактный формат Volga-файлов, поддержка строк, числовых полей, дат, мемо-полей, картинок, и т.д.;
временные таблицы в памяти, которые потом можно сохранить на диск;

и т.д.
Под твою задачу - более чем достаточно. Зачем, действительно, изобретать велосипед?
Access - действительно тормозная хрень. FireBird (старый добрый Interbase) для такого дела возможно тяжеловат. Paradox, DB и иже с ним на такие размеры таблиц не расчитаны... Я бы попробовал эту волгу.

| Сообщение посчитали полезным:

AlCr0, а в коммерческих целях это можно использовать?

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

>> для такого дела возможно тяжеловат
Все зависит от кривизны рук разработчика при разработке БД!
Тормозная она была на 1.5.2, а сейчас уже 1.5.4 и 2.0.1 это очень хорошие СУБД у меня при одной тысяче записей за 0.48 сек. запрос на выборку выполняется и при этом я подсоединяюсь с удаленной машины.

Так что не надо херню говорить, эта СУБД самое то!

-----
My love is very cool girl.

| Сообщение посчитали полезным:

theCollision пишет:
Если уж так захотелось, то думаю лучше будет применить xml-формат

xml это гавно, в нем размер служебных данных может превышать полезные данные в десятки раз. я уже не говорю о быстродействии. ODBC уделает xml по производительности на пару порядков а то и больше, зависит от размера бд.

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

-----
have a nice day

| Сообщение посчитали полезным:

AlexZ пишет:
Подскажите плз способ хранения данных... В проектировании БД ошибки исключены, т.к. просто нечего проектировать. Одна табличка и два-три поля.
Возьми DBF и TDBF http://sourceforge.net/projects/tdbf для прямого доступа.

| Сообщение посчитали полезным: