Вопрос наверное слишком общий но всё же...

Пишу базу данных (никаких там МС Ацесс и пр. всё своё и простое)
и как я понял во многих базах данных размер ячейки заранее известен.

А что делать если размер записи заранее не известен (туда записывается например прилагаемые картинки , список родственников человека , ну что то чей размер и кол-во неизвестны и неограничены)

Везде я натыкался на систему типа : запись делается по длине максимально длинной и заполняется нулями в пустых местах , что облегчает поиск нужной записи , мы всегда знаем начало следующей записи (ну кратное длине записи)

Идея то такова может стоит отказатся от базы данных на одном файле и написать базу типа каждая запись - отдельный файл и искать по названию ?

вообще стоит работать в этом направлении ? или проблем будет больше чем решений ?

Заранее спасибо что не пинаете за глупость.

Dubinsky
Считаю не стоит изобретать велосипед, только если в учебных целях..
Если б все было так просто с базами, то б их штамповали тысячами. А так серьезных только 5-6...

Вообще-то 200% согласен с Coocky

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

vadims
а структурировал?
Добавлено @ 20:30
А какие алгоритмы сортировки ?Сам придумал, или со стандартных брал??

Подождите это конечно может велосипед или нет, но для темы то неважно.

вопрос влоб

Как реализовать то базу с неизвестной длиной записи ?

мною предложенный способ глуп или всё же ?

если бы кол-во записей было 10 -100 я бы даже не спрашивал , а так записей может быть и 10 и 10 000 пугает кол-во файлов просто ...

сама база слишком "гибкая" должна быть , вот что , всё, сдаёмся ?
либо по учебнику либо невозможно ?

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

он даже мне кажется самому не очень но выхода как то не вижу
Добавлено @ 20:42
уфф вы быстрее чем я ...

сейчас соберусь ...

Dubinsky
Динамические массивы и списки?

база легкая ей и сортировка не особо важна ...

важно что есть записи которые ссылаются на разные другие записи , несколько и неизвестно сколько раз (одному Богу известно , зависит только от прихоти пользователя ) , это ладно ещё , а вот что делать со скажем приложенными файлами (картинками , ворд файлами) , их надо как то связать с записью , а каждая связка это пучек данных , кол-во связок неизвестно .

я так понял значит размер то будет плавать , тем более что я хотел эти картинки и прочее включить в саму запись но это не так уж нужно.


Добавлено @ 21:05
Ну да динамические списки , а что это всё , да ? мне выйти в сад ?

Coocky
Я ж говорю -

Цитата(vadims @ 3.7.2005, 20:27)

если это конкретная задача с небольшим кол-вом записей (а не база вообще)

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

Dubinsky
Вот поэтому без конкретики примерно сколько полей в записи и какого типа эти поля, а так же без конкретного списка операций над записями подсказывать не берусь

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

Пока отвечал появился новый пост от автора - мое мнение - бросай эту затею, свихнешься, а четкой работы не получишь

Это сообщение отредактировал(а) vadims - 3.7.2005, 21:12

Dubinsky

Цитата

Ну да динамические списки , а что это всё , да ? мне выйти в сад ?

Я не понял твоего возмущения?
Что конкретно надо?

нет нет , возмущения нет .

я просто спросил может (да наверняка) кто то уже наступал на эти грабли , система в которой запись это отдельный файл , записей порядка 10 000 , размер записи в среднем около 4 кБ
(ну примерно) может ли работать по этому принципу ?

есть ли смысл так делать если используются динамические массивы , или есть другой способ записи ячеек?
ведь если размер записи известен то при перезаписи мы с начала записи и до конца перезаписиваем часть файла и никогда не залезем на следующую запись.А если при перезаписи длина стала больше ? залезем на следующую запись ? перезаписываем так сразу ВСЁ ?

вообще неужели нет других способов ?

не съест ли фрагментация винт ?



список всех записей хотел получить посредством FindFirst() FindNext() ...






Добавлено @ 21:30
а как по другому то ?сказать бросай это и я могу
Добавлено @ 21:36
тип полей в основном то String , их то можно по максимуму ограничить , а вот кол-во связей ?

забить типо максимум 10-100 связей и если нет связей меньше то заполняем нулями , а если больше то извини пользователь , больше не дано ...

здравствуй типизированный файл ...

Цитата

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

Ты не в жизни без них не обойдеся...Мало того, у тебя еще будут массивы в массивах. Вообщем сложная структура.Это насчет таблиц.
Что каксется полей, то можно сделать статические массивы, но с ограничением размера данных

Цитата

А если при перезаписи длина стала больше ?

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

не ну вообщем спасибо , хоть что то проясняется ...

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

вообще может какую информацию посоветуете то по этой тематике ?

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

Dubinsky
Делаешь один класс-это база данных. В нем методы для работы с таблицами и поля с именем таблиц(опять же массив, опять же динамический)...с указателями на таблицы
Далее еще один класс,вложеный, для таблиц, со своими методами и полями.
Тип такой, а вообще покумекать надо..

это вроде разбить базу совсем на ячееччечки махонькие

ну типо имя , фамилия , связка какая то , одного человека это отдельные записи? А соберём человека уже потом по кускам?

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 кБайтный индекс. Хочешь сделать ещё меньше? Пожалуйста, проискивай базу прежде чем добавить новую запись. Вдруг она уже имеется? тогда её не надо добавлять в файл - базу, а только её позицию в индекс.

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

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

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

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

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

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

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

Если запись длиннее, то оставляем дырку, а запись вешаем на конец.
Раз в месяц делаем Vacuum

А файловая система... как тебе сказать... Я бы такое у себя не ставил 100%!

Вот и я засомневался ...потому и спросил...

мда раз в месяц сдавливать её ... мда может и неплохо...
только если мы ищем запись то находим её индекс "n" пропускаем "н" байтов читаем , если что в конец её ...

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

Я бы делал так как предложил sergej.z,
едиственное что с файлами проще (а чем тупее тем надежнее) реализовать - все функции поиска по ключу(имени файла) берет на себя ОС

Что касается файловой системы - все будет нормально если файлы закрывать после добавления-редактирования не забудешь и питание раз в 10 минут лететь не будет - это же не мои фантазии - а из практики, у меня около 10 лет уж пашут без нареканий 2 такие штуки - одна под DOS, вторая по W98

Кстати решения КСС и Пейджлик по пейджинговым системам - на этом принципе - куча продаж была - собственно оттуда идею и взял в свое время

Сортированный индекс для того и делается, чтобы легче было искать
Если индекс не сортированный, то да, придётся пробегать по всёй базе.

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

PS:
Возми SQLite, раяо или поздно всё равно понадобятся все фичи

ОК допустим СКУЛит случаем копирайты не имеет сия фича , и проблем типа "Покупайте лицензию !"

Эта библиотека не только opensource, но и public domain. Означает - делайте с кодом что угодно, но не говорите потом, что это я так написал.

Написал её австралийский профессор, которому и так денег хватает. Она уже широко распространилась (например PHP5 имеет её уже встроенной)

Благая весть ! на сегодня и вообще спасибо !

Цитата(sergej @ 4.7.2005, 19:42)

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

Так работает СУБД Аксесс и это хорошо при малых обьемах базы... когда же файл базы достигает 40 мегобайт, то время сжатия увеличивается до 10 минут. ЗЫ хотя Аксесс и не предназначен для таких обьемов

Цитата(En_t_end @ 4.7.2005, 17:14)

Так работает СУБД Аксесс и это хорошо при малых обьемах базы... когда же файл базы достигает 40 мегобайт, то время сжатия увеличивается до 10 минут. ЗЫ хотя Аксесс и не предназначен для таких обьемов

так работает любая СУББД просто некоторые стараются разбиение на файлы ограничить время переписки. вообще DELETE - очень проблематичная функция.

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

так есть ли смысл одним файлом то писать ?
единственный минус это быстродействие поиска файла (findfirst , findnext),но ведь это нужно сделать только один раз ,загружая список всех записей , да и файл можно заранее сделать с названиями , так то вообще быстро будет ?

Почему мне всё время кажется что я что то не учитываю ...

а насчёт переписи файла ... как то мне это кажется ещё более глупым нежели моё предложение .
средний размер базы будет 100-200 МБайт
каждый раз перезаписывать ? долговато будет... или раз в час ?

Цитата(Dubinsky @ 5.7.2005, 11:51)

а насчёт переписи файла ... как то мне это кажется ещё более глупым нежели моё предложение . средний размер базы будет 100-200 МБайт каждый раз перезаписывать ? долговато будет... или раз в час ?

Это зависит от того, как часто будут удалятся записи. Создай систему, которая считает "пустое место" в файле. Запускай функцию, когдо его будет слишком много.

А что, у тебя проблемы с SQLite? Дай пример своего кода, я помогу тебе её туда вставить.

зато насчёт вылетания питания , тут так однозначно много файлов рулят ...

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

если на каком то этапе рубанёт ли[censored 9]ричество то:
1 не допишется бэкап
2 запишется бэкап но не запишется файл
3 не сотрётся бэкап

в любом случае информация целая только либо на бэкапе либо в самом файле, остаётся смотреть файл цел или нет и грузить соответствующий.
Добавлено @ 12:59
да пока проблем нет я не смотрел СКУлит ...

мне стало интересно почему так никто не делает ?

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

Цитата(Dubinsky @ 5.7.2005, 11:58)

мне стало интересно почему так никто не делает ?

Дык делают так почти в любой СУББД.

ПС:
Ещё тебе придётся реализовывать Begin work и Commit.

ладно а что мне надо от СКУлита ?? сорс ? или что они там предлагают ?

На чём пишем? Сорс у неё на Си. Если пишем на Си/Си++ то сорс - самое то. Иначе можно просто взять ДЛЛь
Добавлено @ 14:08
Кстати, скажу сразу, vacuum придётся и на SQLite делать время от времени. Во всяком случае так было 3 года назад. Может что и изменилось в этом направлении..
Добавлено @ 14:12
Как я и предполагал, они ввели уже autovacuum

Здесь можно просмотреть всю историю развития SQLite как на ладони
http://www.sqlite.org/changes.html

Можно себе вообразить, что ожидает разработчика такой базы с нуля

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

пишу на Бульдере 6 ... значит сорс ...
Добавлено @ 15:01
мдааа скачал , идиот , сижу и пялюсь как на чудо " а что дальше то ?"

Добавь *.c файлы в проект. Там не все нужны. тесты например не нужны. Все, где внутри есть функция main можно не добавлять. Даже нельзя добавлять, ведь у на своя main будет.

Потом создай тест файл, как я описал http://forum.vingrad.ru/index.php?act=ST&f...ndpost&p=131364

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

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

Fantasist
Согласен

Послушай народ, не пиши свою базу, времени убьешь, а толку нулл...

Если что более-менее серьезное требуется, то возьми хоть FireBird.
http://sourceforge.net/projects/firebird/

Есть варианты ClasicServer; SuperServer; Embedded. Разные операционки.

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

Месяцев за 2-3, если плотно посидишь, с IDE интерфейсом разберешься...

Fantasist Во-во, уже с выходных пытаемся человека убедить

ну чтож ошибка начинающего , может оно и так ...

за советы спасибо , особенно сергею ...

а насчёт базы , я упрямый , посмотрим ещё , если получится , зацените может потом ...

если почувствую что не попрёт самому , полезу на СКУЛит , так и так придётся разбиратся

всё , удачи , всем спасибо.

Модератор: перенесено из C++:Общие вопросы.

Цитата(vadims @ 6.7.2005, 09:57)

Fantasist Во-во, уже с выходных пытаемся человека убедить

Так я вижу. Уже всем скопом убеждаем, но видимо, не убедили. Ничего, такие вещи с опытом быстро приходят.

Та ладно вам, ну хочет чел написать свою БД -- пусть пишет
Я думаю тут что-то с сегментацией надо, наподобие: разбиваем все на блоки 4 кб и тасуем записи между ними. Таким образом получиться даже некая ФС.

Не думаю, что настоящие БД используют сегментацию. В БД важна быстрая выборка и быстрое сравнение двух записей. Таким образом придётся фрагменты сравнивать...
А место как раз не важно. Так что пихают на конец и всё. Максимум что делают - разбиение на файлы - таблицы. Критичное здесь толко удаление записи. При разбиении на файлы по, скажем, 10 МБ vacuum делать намного легче.

PS:
Я на вашем месте прекратил бы оффтоп и поучение человека. Дайте ему конкретные факты, чтобы можно было сравнить и понять, почему собственная разработка безперспективна.

А если чек хочет попрактиковаться в программинге, то БД - это довольно интересное и поучительное занятие.
Потом сравнит с готовым продуктом (SQLite кстати 5 лет всем земным шаром разрабатывается ) и возможно примет участие в его разработке.

Создание своей базы - классная идея! Т.е. если мое приложение хранит не миллионы записей и не использует множество таблиц - то здорово бы иметь не слишком сложную библиотечку, которая интерпретирует SQL-запрос и эмулирует Recordset, храня данные в файле(ах) и не требуя драйверов (BDE, ODBC, OLEDB).

По конкретному вопросу, Dubinsky - скорее всего, лучше использовать какую-то стандартную базу данных

Dubinsky, "А что делать если размер записи заранее не известен (туда записывается например прилагаемые картинки , список родственников человека , ну что то чей размер и кол-во неизвестны и неограничены)"
- картинки можно хранить в BLOB'полях базы, имеющих неограниченную длину (но по содержимому BLOB'а нельзя искать); или можно хранить в файлах, а имена файлов писать в базу
- список родственников человека - такое обычно выносят в отдельную таблицу, например:
таблица_сотрудников: id_сотрудника, имя_сотрудника, должность_сотрдника;
таблица_родственников: id_родственника, id_сотрудника, имя_родственника.
Делая запрос "SELECT имя_родственника FROM таблица_родственников WHERE id_сотрудника = ..."
получу список родственников сотрудника
Вообще в среднем приложении используются десятки таблиц, ничего страшного в этом нет; есть множество развитых средств проектирования структуры таблиц базы и их взаимосвязей - начиная, скажем, с ErWin, PowerDesigner

Dubinsky, "Везде я натыкался на систему типа : запись делается по длине максимально длинной и заполняется нулями в пустых местах"
- есть тип varchar, в отличие от char, не забивает строку нулями до максимального размера, а помнит фактическую длину строки; в базе MSSQL максимальная длина для varchar - в районе 8000 байт; правда физически в базе нули могут храниться - я слышал, что MSSQL2000 не хранит нули, только если varchar/image(BLOB)-колонки - последние в описании таблицы; по varchar доступен поиск, в отличие от BLOB
- вообще ограничение размера полей нужно, чтобы делать оптимизацию размера и скорости поиска по базе (и находить баланс между этмии характеристиками)
- каталог с файлами - это вообще говоря тоже база данных, не очень быстрая при большом количестве файлов в одном каталоге (промышленные базы данных быстрее - в таблицах у меня бывали миллионы записей, а вот в каталоге с файлами - я бы не делал больше 1-10 тысяч файлов максимум)

Цитата(_vlad @ 7.7.2005, 20:45)

Т.е. если мое приложение хранит не миллионы записей и не использует множество таблиц - то здорово бы иметь не слишком сложную библиотечку, которая интерпретирует SQL-запрос и эмулирует Recordset, храня данные в файле(ах) и не требуя драйверов (BDE, ODBC, OLEDB).

SQLite идеально отвечает всем требованиям. Весит 200 кБ и испытана годами и миллионами юзеров.

_vlad, рады видеть вас на Винграде. Регистрируйтесь и вам откроются новые возможности у нас на форуме

Вот как раз около 10 000 файлов и будет ...