I'm working on a program that disassembles programs and analyses the results. I decided to use SQLite to store the data, but I'm having trouble deciding on how to organize the data.
The design I've thought of so far involves placing the code data (comment, line number, opcode, etc) in one table, and then placing data about the code like symbolic names for memory addresses in other separate tables. There could potentially be millions of lines of code, so I might need to handle millions of columns in the disassembly table.
The program using this database will be a simple text view (for now). It will fetch enough lines of code from the code table to fit the screen, and the program will look up data about the code from the other tables. Say that I have a memory address referenced at some point. My program will recognize that, and look it up in the symbol name table to see if we could find a human readable name for it. In the future, I might also add editing for individual lines, which could invalidate data stored about a line of code.
Does this seem somewhat sane? How else might I go about it? Assuming this rough idea makes sense, what things should I keep in mind for making it fast? Any suggestions or resources to look at for designing this database would be much obliged.
Best Answer
"Millions of columns"? Or millions of rows? For single user applications and just a few megabytes of data, sqlite can be perfectly sufficient, so it will really depend on how many lines of code/rows of data you'll be dealing with, and the complexity of the queries that you'll require. You may want to consider postgresql or mysql from the get go, to avoid getting bogged down or finding sqlite is too limited when you've invested a lot of code and time on it.