Dubinsky
Нет, это разбить базу на таблицы, а таблицы на поля...
Кол-во таблиц-динамические данные, кол-во полей таблиц-опять же динамические..

Dubinsky
Я сейчас отключаюсь уже и чтобы чепухи не нагородить лучше советов давать не буду - поразмышляю завтра, опиши примерно как будет использоваться эта база, хочу понять насколько активно предполагается обращаться к ней на чтение и на редактирование - от нечастых транзакций тоже можно кое-что скроить
И еще, какой ОС и инструмент для разработки предполагаешь использовать

Может стоит посмотреть в сторону XML?

Мдя... каким это боком в С++ оказалось неизвестно( на самом деле ей бы в юмор)... ну я когда начал с базами работать, тоже очень испугался осваивать что-то новое . Поэтому тоже сел писать контролер "ФАЙЛОВОЙ БАЗЫ ДАННЫХ". Про её недостатки можно очень много прочитать в начале любого учебника по реляционному проектированию, наряду с похвалами великому Кодду.
Сразу скажу... как только я сел за проектирование системы контроля транзакций я сдулся, потому что её обычно делают сотни грамотных специалистов, а тут какой-то любитель совсем без образования сел и начал писать - ничего не вышло. Возникло много вопросов вот они(ЗЫ там меня уже давно обсмеяли ) http://forum.vingrad.ru/index.php?showtopic=53664

я запостил сюда эту тему потому что в форуме по БД разъясняют только Оракл , АДО , ДБ2 и т.п. А мне НЕОБХОДИМА самописная БД и других вариантов НЕ БУДЕТ там вроде как то неудобно было

теперь конкретнее :
Всё что нужно будет этой БеДе так всего лишь найти необходимую запись , считать и по необходимости заменить .

вопрос то был о плюсах и минусах такой системы :

что с фрагментацией будет (если НТФС или ФАТ32)?

если размер файла может только увеличиватся (оччень редко уменьшатся), частота изменения файла 5-10 раз в день . Обращатся к файлам будут на порядок чаще , однако в общем больше 50 файлов в день менятся не будет.

о работе с индексами : у каждой записи уникальный номер вот вам и название файла , и индексация по ним . Индекс менятся не будет присваивается один раз.

Остальное проще простого : просканировал директорию на наличие файлов, загрузил в список названия файлов , надо загрузить пжласта название есть...
добавилась запись - добавь в список название , в чем я ошибаюсь ?

повторяю пугает кол-во файлов ...

ОС - Вин 2000.ЭКС ПИ. язык Ц++ бульдер

Это сообщение отредактировал(а) Dubinsky - 4.7.2005, 14:57

Цитата(Zzz @ 3.7.2005, 23:37)

Может стоит посмотреть в сторону XML?

Dubinsky
прислушайся к совету
тем более в Ц++буилдере есть не плохой компонент TXMLDocument

Это сообщение отредактировал(а) chaos - 4.7.2005, 13:40

Вот за совет спасибо эт ближе к делу ,
только вот никогда не работал с ХМЛ с чего начать то ?

Цитата(Dubinsky @ 4.7.2005, 13:50)

Вот за совет спасибо эт ближе к делу , только вот никогда не работал с ХМЛ с чего начать то ?

ну для начала прочитай что такое XML(если хоть не много знаешь HTML может будет легче хотя нет там ни чеог уж ьакого сложного)
ну и потом разбирайся с TXMLDocument там в принципи точе все прозрачно

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

Один из первых постов был мой, где был поставлен вопрос - опиши конкретно задачу, может там набор операций и условия использования усечены так что можно и что-то сделать - наконец то ты это подтвердил

Объем транзакций небольшой и вполне можно сформировать базу по принципу запись == файл
Тк предусматриваются поля переменной длины а объем транзакций небольшой, я бы хранил эту запись как текст, те поле == текстовая строка(удобно для строк переменной длины), а уж каждое строка(поле) либо значение либо ссылка на другой файл(запись) либо пусто.

Повторюсь, что на таком подходе 8 лет работает БД во вполне коммерческой задаче (5000 записей) - ни одного сбоя и скорость обращения вполне приемлимая - это система голосового сервиса для пейджингового абонент, те абонент висит на линии когда происходят транзакции.

Ну а минусы уже говорил: копирование и архивация - свихнешься ждать, опять же обеспечение целостности по ссылкам

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

Напишешь без ошибок - ничего не загнеться


НИЧЕГО не ПОНЯЛ, а куда делся пост на который я отвечал - оставляю ответ, тк автор наверное поймет

Это сообщение отредактировал(а) vadims - 4.7.2005, 14:45

Дам тебе пару советов

Пиши в 2 файла

1 файл - индекс
2 файл - база

в индексах прописана позиция начала записи в файле-базе.

Когда приходит запись, она пишется в файл-базу на конец, а в индекс-файл в писывается позиция.
Таким образом у тебя в индексах константная длинна записи - число - позиция.
Какой длинны - решай сам. Чем длиннее, тем больше записей сможешь сохранить.

Вообще, всё вышеописанное делай только если хочешь немного попрогить. В нормальных случаях берёшь: SQLite - 200 кБ библиотечка цепляешь в свой проект и вот у тебя полноценная, провереная БД прямо в коде, которая имеет ряд качеств:

Самая быстрая на сег. день.
Маленькая, лёгкая
Поддерживает весь SQL
Удобный интерфейс
Может быть скомпована с прогой или в DLL'ky
Кучи тулзов для независимой работы с ней.
Всё лежит в одном файле
С этим Файлом можно работать на любой платтформе
С разработчиком можно поговорить непрямую

Вот ещё ссылка http://forum.vingrad.ru/index.php?act=ST&f...ndpost&p=131364

Что-то я не понимаю.. раз так все просто и вопрос не в пользовании FindFirstFile и FindNext, то зачем
1. Создавать эту тему в С++. Для этого есть отдельные разделы(я бы посоветовал "Базы Данных" и "Технологии" + "Литература", чтобы найти инфу по XML)
2. Как я понимаю вы делаете простой список... и требуется быстрый поиск ? Уникальные номера файлов будут даваться в порядке возрастания ? Тогда используйте char** для хранения имен и ещё отдельный char** для хранения информации о файле. Свяжите их индексами.
Если охота сделать красиво... то просто содайте класс на основе массива.

ЗЫ XML действительно подойдет.

Это сообщение отредактировал(а) En_t_end - 4.7.2005, 14:58

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

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

Программа-аналог имеет структуру базы предложенной Sergej.z , только я заметил что такая база в том случае сжимается процентов на 95 , забита ненужной инфой ...

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

Добавлено @ 15:16
мда может технологии было бы более нодходящим местом для этой темы ...

Цитата(Dubinsky @ 4.7.2005, 14:15)

Программа-аналог имеет структуру базы предложенной Sergej.z , только я заметил что такая база в том случае сжимается процентов на 95 , забита ненужной инфой ...

Ничего не понимаю Какая ненужная инфа?

первый файл содержит только числа - позиции записей во втором файле:

Как они просортированы - да как захочешь. не хочешь, не сотртируй вообще.
то есть для 10000 записей в первом файле будет стабильно 40000 байт (интегер имеет размер 4 байт) А во втором файле идут просто записи одна за другой.
И как ты предлагаешь ужать эту историю? Единственная добавка к записям - это 40 кБайтный индекс. Хочешь сделать ещё меньше? Пожалуйста, проискивай базу прежде чем добавить новую запись. Вдруг она уже имеется? тогда её не надо добавлять в файл - базу, а только её позицию в индекс.

Хочешь просортировать записи? Пожалуйста! Создай ещё один индекс-файл в котором числа из первого будут в отсортированном по записям порядке.

да там система то такая , только вот если посередине где то запись меняется в меньшую сторону или стирается то индекс то стёрся (изменился) , а сами данные (где они уже не нужны ) остались какими были ...

Вот и выходит что поначалу всё супер , а потом ...

более детально разложить прогу-аналог не могу ...

То есть проблема с удалением. Ну она всегда есть. Разбивай файл - базу на абстрактные сегменты. И освобождай весь сегмент.

Или, что проще, сделай функцию, которая бежит по индексу и переписыват файл - базу в другой файл, а старый стирает.