Как записать простой [закрытый] механизм базы данных
Конфигурации логгера - пустая трата времени. Зачем их, если это означает изучение нового синтаксиса, особенно тот, который молча терпит неудачу? Не поймите меня неправильно, я люблю хорошие лесозаготовки. Я люблю наследование логгеров и добавление форматеров в обработчики в логгеры. Но зачем делать это в конфигурационном файле?
Вы хотите внести изменения в код регистрации без перекомпиляции? Зачем? Если вы поместите свой код регистрации в отдельный класс, файл, что бы это ни значило?
Хотите ли вы распространять настраиваемый журнал с вашим продуктом среди клиентов? Разве это не дает слишком много информации в любом случае?
Самое разочаровывающее в этом то, что популярные утилиты, написанные на популярном языке, как правило, пишут хорошие API в формате, который определяет язык. Напишите утилиту ведения журнала Java, и я знаю, что вы сгенерировали javadocs, по которым я знаю, как ориентироваться. Напишите специфичный для домена язык для вашей конфигурации логгера и что у нас есть? Может быть, есть документация, но где, черт возьми, это? Вы сами решаете, как это организовать, и я просто не заинтересован в том, чтобы следовать вашей точке зрения.
9 ответов
Если вы хорошо умеете читать код, изучение SQLite научит вас целому ряду вопросов о проектировании баз данных. Он маленький, так что голову легче обернуть. Но это также профессионально написано.
SQLite упоминался ранее, но Я хочу кое-что добавить.
Я лично многому научился, изучая SQlite. Интересно то, что я не перешел к исходному коду (хотя я просто бегло просмотрел). Я многому научился, прочитав технический материал и особенно изучив внутренние команды, которые он генерирует. У него есть собственный интерпретатор на основе стека внутри, и вы можете прочитать P-код, который он генерирует внутри, просто используя объяснение. Таким образом, вы можете видеть, как различные конструкции транслируются в низкоуровневый движок (что на удивление просто - но в этом также секрет его стабильности и эффективности).
Хорошо, я нашел сайт, на котором есть некоторая информация о SQL и его реализации - довольно сложно ссылаться на страницу, на которой перечислены все руководства, поэтому я буду связывать их по одному:
Ответ на этот вопрос огромен. ожидайте, что на докторскую диссертацию будет дан 100% ответов;) но мы можем думать о проблемах одну за другой:
Как хранить данные внутри: у вас должен быть файл данных, содержащий объекты вашей базы данных и механизм кэширования для загрузки данных в фокусе и некоторых данных вокруг них в ОЗУ предположим, что у вас есть таблица с некоторыми данными, мы бы создали формат данных для преобразования этой таблицы в двоичный файл, согласовав определение разделителя столбцов и разделителей строк и убедившись, что такой шаблон разделителя никогда не используется в вашем сами данные. т.е. если вы выбрали <*>, например, для разделения столбцов, вы должны проверить данные, которые вы помещаете в эту таблицу, чтобы они не содержали этот шаблон. вы также можете использовать заголовок строки и заголовок столбца, указав размер строки и некоторый внутренний индексный номер, чтобы ускорить поиск, и в начале каждого столбца, чтобы иметь длину этого столбца например "Адам", 1, 11.1, "123 ABC Street POBox 456" ты можешь иметь это как <& RowHeader, 1> <& Col1, CHR, 4> Адам <& Col2, num, 1,0> 1 <& Col3, Num, 2,1> 111 <& Col4, CHR, 24> 123 ABC Street POBox 456 <& RowTrailer>
Как быстро найти предметы попробуйте использовать хеширование и индексирование, чтобы указать на данные, которые хранятся и кэшируются на основе разных критериев взяв тот же пример, приведенный выше, вы можете отсортировать значение первого столбца и сохранить его в отдельном объекте, указав идентификатор строки элементов, отсортированных по алфавиту, и т. д.
Как ускорить вставку данных Я знаю от Oracle, что они вставляют данные во временное место как в ОЗУ, так и на диск и периодически выполняют уборку, ядро базы данных постоянно занято, оптимизируя свою структуру, но в то же время мы не хотим терять данные в случай отключения электроэнергии что-то подобное. поэтому постарайтесь сохранить данные в этом временном месте без сортировки, добавьте исходное хранилище, а позже, когда система освободится, используйте свои индексы и очистите временную область, когда закончите
удачи, отличный проект.
Есть книги по этой теме, хорошее место для начала - База данных Системы: Полная книга Гарсиа-Молина, Ульман и Видом
может быть вы можете узнать из HSQLDB . Я думаю, они предлагают небольшую и простую базу данных для обучения. вы можете посмотреть коды, так как это открытый исходный код.
Я бы посоветовал сосредоточиться на www.sqlite.org
Он недавний, небольшой (исходный код 1 МБ), с открытым исходным кодом (так что вы можете понять это сами) ...
О том, как это реализовано, написаны книги:
http://www.sqlite.org/books.html
Он работает на различных операционных системах как для настольных компьютеров, так и для мобильных телефонов, поэтому экспериментировать легко и изучение этого будет полезно прямо сейчас и в будущем.
Здесь даже есть достойное сообщество: https://stackoverflow.com/questions/tagged/sqlite
I am not sure whether it would fit to your requirements but I had implemented a simple file oriented database with support for simple (SELECT, INSERT , UPDATE ) using perl.
What I did was I stored each table as a file on disk and entries with a well defined pattern and manipulated the data using in built linux tools like awk and sed. for improving efficiency, frequently accessed data were cached.
If MySQL interests you, I would also suggest this wiki page, which has got some information about how MySQL works. Also, you might want to take a look at Understanding MySQL Internals.
You might also consider looking at a non-SQL interface for your Database engine. Please take a look at Apache CouchDB. Its what you would call, a document oriented database system.
Good Luck!