Nie mam czego Ci wybaczać, temat jest dla Ciebie świeży, więc normalne, że możesz czuć się zagubiony.
Nie wiem na ile w ogóle masz pojęcie, czym jest SQL - dlatego kilka słów wprowadzenia ;) Dane można przechowywać na wiele sposobów. Można w plikach tekstowych, można także w plikach, w których zamiast tekstu zapisuje się struktury danych (file of record-type
). Stworzono różne systemy działania z bazami danych - chociażby słynne i dawniej bardzo popularne pliki DBF. Ale to było za mało, bo one raczej skupiały się na pojedynczych rekordach, a nie na całości posiadanych danych. Dlatego kolejnym krokiem jest SQL (od razu uprzedzając osoby chcące mnie prostować - wiem, czym jest SQL, a czym sama baza/silnik, ale tutaj piszę w sposób uproszczony, żeby oddać ideę). W przypadku SQL działasz na większych partiach danych. Przykładowo - w "tradycyjnym" modelu, żeby znaleźć jakąś informację, nieraz musisz przeszukać cały plik, odczytać wszystkie rekordy. W wypadku SQL zadajesz pytanie, a resztę wykonuje za Ciebie silnik/baza.
I teraz dochodzimy do tego, dlaczego SQLite jest fajne. Taki tradycyjny silnik (chociażby MySQL, Postgres, MsSQL czy Oracle) musi być zanistalowany, skonfigurowany, musi cały czas działać. Jest to normalne w sytuacji, w której usługa ma być dostępna cały czas. Ale często SQL jest potrzebny tylko czasami i na chwilę, więc nie ma sensu odpalać wielkiego kombajnu, żeby przechować parę rzeczy. Istotna jest także kwestia przenośności - jeśli aplikacja odwołuje się do serwera SQL, to żeby można było mieć dostęp do danych z innych komputerów, musi on być dostępny publicznie.
Żeby zrobić z tym porządek ktoś kiedyś wymyślił SQLite. Z punktu widzenia użytkownika, działa to jak "prawdziwy" SQL, czyli wysyła się zapytania, które nakazują SQL wykonanie pewnych czynności. Ale różnica jest taka, że nie trzeba niczego instalować, nie ma żadnych wielkich systemów, które muszą chodzić w tle. W przypadku Windowsów całość ogranicza się do 1 albo 2 plików DLL, które trzeba umieścić w katalogu aplikacji. A rolę bazy odgrywa jakiś zwykły plik, w którym są zapisane potrzebne dane. Owszem, takie rozwiązanie ma parę minusów, chociażby brak haseł, użytkowników, poziomów dostępu itp, ale coś za coś. Trzeba umieć wybrać narzędzie do potrzeb. W Twoim przypadku, do trzymania listy słów. SQLite jest wystarczający całkiem.
To o co chodzi z tymi managerami i/oraz komponentami?
Zasadniczo różnego rodzaju managery to takie graficzne nakładki. Wszystko można zrobić w SQL ręcznie w konsoli. Chociażby tworzenie tabeli - można w jakimś graficznym kreatorze kliknąć coś w stylu "nowa tabela", potem pojawi się pewnie jakieś okienko, w którym się określi parametry tej tabeli. Ale równie dobrze można sobie ręcznie wywołać polecenie CREATE TABLE xxxxxxx
i tam określić, co to ma być za tabela. Tak naprawdę, to manager wykona dokładnie to samo, tylko w sposób niejawny. W każdym razie - tego typu aplikacje są przydatne, bo można w łatwy i graficzny sposób mieć dostęp do danych zawartych w bazie, można także zmieniać ustawienia bazy, tworzyć i kasować tabele, dodawać kolumny itp. ALE żeby była jasność - sama baza/silnik bazy nie ma żadnego związku z managerem. Możesz mieć bazę i nie korzystać z managera. Manager to jedynie takie udogodnienie, edytor danych trzymanych w bazie.
Co do kontrolek/komponentów - tutaj można działać na dwa sposoby. W Lazarusie masz cały zestaw komponentów do pracy z bazami danych. Można z nich korzystać, ale w naszym przypadku nie ma takiej potrzeby, a wręcz przeciwnie, mam wrażenie, że byłoby z tym więcej zamieszania. Dlatego Ty powinieneś postępować zgodnie z tym, co masz napisane w tutorialu na 4P, do którego link wkleiłeś kilka postów wyżej. Po prostu - dodajesz do uses odpowiednie pliki, dorzucasz DLL, a następnie wydajesz stosowne zapytania. Zakładając, że rozumiesz co jest w tutorialu, powinieneś dać sobie radę. Ewentualnie pytaj dalej, w miarę możliwości postaram się coś wyjaśnić.