Dodam, że SQLite jest bardzo prostym RDBMSem. Chyba jednym z najprostszych.
Nie widziałem jego kodu, więc nie wiem, czy jest trudny do zrozumienia czy nie. Próbowałem kiedyś dłubać cos w PostgreSQL i MySQL, i po paru dniach stwierdziłem, że łatwiej jest napisać kompilator/optymalizator zapytań samemu od zera.
Krótko, co musi być (w każdym, nawet najprostszym RDBMSie):
- Lexer + parser SQL - da się wygenerować odp. narzędziem z gramatyki. Podstawowa gramatyka zmieści się w ok. 100 liniach. Gramatyki do SQLa walają się gdzieś po sieci, ale często są zbyt rozbudowane. W 3 dni da obskoczyć, jeśli znasz dobrze narzędzia i SQLa.
2a. Reprezentacja operatorów algebry relacyjnej i drzew. Do tego aż prosi się wziąć język obiektowy. W samym C nie ma najmniejszego sensu się męczyć, choć się da. Będziesz miał z tego kilka klas po kilkadziesiat / kilkaset linii.
2b. Reprezentacja metadanych - tzn. system musi wiedzieć, jakie są tabele, jakie mają kolumny, jakich typów itd. Metadane muszą być zapisywalne w pliku bazy. To jest proste, ale żmudne. Znowu C bym odradzał, bo tu się bardzo przydają wszelkiego rodzaju kontenery (wektory, tablice asocjacyjne itp.).
- Kompilator zamieniający drzewa składni w drzewa algebry relacyjnej. Na tym etapie dokonuje się też analizy semantycznej - tzn. wiąże się identyfikatory w zapytaniu z konkretnymi tabelami / kolumnami. Jeśl nie da się powiazać, zgłasza się błędy. U mnie ten fragment (Java) ma ok. 850 linii z komentarzami.
3a. Optymalizator zapytan. Od biedy można walnąć w 3 dni coś super naiwnego co zastosuje jakieś heurystyczne reguły (podejście MySQLa, SQLite) - np. użycie pierwszego lepszego dostępnego indeksu, gdzie można. Na kosztowy optymalizator w Twoim przypadku bym się nie porywał, choć to jest de facto w tej chwili standard w dobrych RDBMSach.
- Implementacja fizyczna operatorów relacyjnych. W końcu coś musi odczytać dane z dysku i je przetworzyć zgodnie z planem zapytania. Minimalny zestaw:
- projekcja (tzn. wyciągnięcie odp. kolumn oraz ewentualnie policzenie jakiegoś wyrażenia)
- filtrowanie rekordów na postawie zadanego warunku
- złączenie tabel (najłatwiejsze naiwne przez zagnieżdżone pętle)
- sortowanie (external sort)
- sekwencyjny odczyt tabeli
- sekwencyjny odczyt indeksu powiązany z równoczesnym odczytem przypadkowym tabeli
-
Zarządca buforów. Trzyma najczęściej używane dane w pamięci i stara się je "mądrze" zapisywać na dysk. Bez tego w sumie można się obyć i zwalić to na system op (jak w PostgreSQL). Niemniej nadal potrzebujesz coś co czyta dane z dysku całymi blokami i wyższej warstwie udostępnia interfejs w postaci osobnych rekordów.
-
Zarządca blokad. Dwuetapowe blokowanie wydaje się dosyć proste do zaimplementowania - najprościej blokować całe tabele, ale jest to oczywiście strasznie lamiaste...
-
Implementacja indeksów - jeden typ musisz mieć. B-drzewo wydaje się absolutnym minimum. Implementacja B-drzewa jest u nas na wydziale chyba na jakimś przedmiocie jednym z projektów (trwa 1 semestr). Na sieci jak dobrze pogrzebać jakieś kody źródłowe mozna znaleźć. No, można też zerżnąć kawałki kodu z MyISAM.
-
Dodatki takie jak interfejs użytkownika, zarządzanie kontami, bezpieczeństwo. Tak naprawdę w porównaniu z całą resztą to to już są kosmetyczne pierdułki.
Jeśli serio macie coś takiego zrobić na projekt, to tego gościa pogięło. Dla mnie to jest za dużo nawet na magisterkę. Poza tym, powiedział, po co to ma być? To jest jakiś przedmiot z baz danych czy co? A może Wy to macie zrobić zespołowo w 10 osób? (też miałbym wątpliwości - 10 osobowy zespół na uczelni działa wolniej niż zespół jednoos.)