Ich bin noch am konzipieren und es betrifft auch nur ein Hobby-Projekt mit niedriger Prioriät, aber Einsichten sind dennoch sehr willkommen

Ich habe überlegt, dass ich viele Datensätze habe, die eigentlich sehr schön in unabhängige Tabellen passen würden. Etwas konkreter heisst das, ich
habe etwa eine Tabelle mit Feldern "Wert", "Name", "Kommentar", und davon viele Einträge.
Eigentlich könnte ich die alle in einer Map speichern (NSDictionary für Cocoa?). Das man das jetzt von/nach sqlite serilialisieren kann sei erstmal egal.
Ich habe jetzt überlegt, ob ich nicht einfach nur auf einer sqlite-Datenbank arbeite, also direkt mit INSERT und SELECT mit den Daten arbeite.
Dafür spricht jetzt, wie ich finde:
- Ich spare mir noch eine "Abstraktion" im Speicher
- sqlite übernimmt hoffentlich(?) Caching und laden in den Speicher etc. von sich aus
- Serialisierung kommt quasi "gratis"
- sqlite erlaubt doch mehrere Indizes? Also ich kann dann schnell nach "Name" suchen, auch wenn "Wert" mein PK wäre?
- Meine Datenhaltung ist komplett unabhängig: Unabhängig von Sprache, Plattform, Code. Ich kann einfach fix mit python drauf zugreifen, wenn
ich das will.
- Eventuell wird durch JOIN das ein oder andere einfacher, etwa wenn ich in einer anderen Tabelle fix den Namen zu einem gegeben Wert darstellen will etc.

Was mir nicht klar ist:
- Ich bin SQL Erfahren. Aber werde ich vielleicht doch blöd dabei, alles in rohem SQL zu machen? Soviel wirds ja sicher nicht werden, ein paar
prepared statements zum einfügen, rausholen, suchen.
- Ist sqlite schnell genug? In dem einen Szenario kann ich mir vorstellen, vielleicht 10^4 oder mehr Einträge zu haben, die ich dann jeweils 20 Stück (bzw. Fenstergrösse..)
in einem NSTableView darstellen will. Dann mit Scrollen jeweils das ganze aktualisieren. Sollte klappen, oder?
- Spricht irgendetwas anderes noch dagegen?

Vielen Dank! Das klingt ja alles recht naheliegend, und wenn wohl wirklich nichts dagegen spricht, werde ich das wohl so mal in Angriff nehmen