На чём пишем? Сорс у неё на Си. Если пишем на Си/Си++ то сорс - самое то. Иначе можно просто взять ДЛЛь
Добавлено @ 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, рады видеть вас на Винграде. Регистрируйтесь и вам откроются новые возможности у нас на форуме