Posted 06 May 2010 - 04:41 PM
I would do a function similar to the one you already have.
db_entry_get_pos_ext(table id, "column1=variable1,column2=variable2,column3=v
ariable3", 0, list, ",");
Table id would be file name.
Instead of list it would be a table.
It would first load the structure of the file. Then search for the columns where the requirements matched.
Then it would load the entire row where it found a match into the new table.
*Notes and possible problems. Part of the reason file based db's work this way is because they have some sort of indexed system so they can do quick searches for records with out having to go through them one by one.
Secondly > < (greater then, less then) are supported by the queries. So i could say where Column1 > 100 and column1 < 200
Thinking about it now, that would be a lot of work on top of what you already have. Not to mention i don't know your current file structure but it seems like a encrypted ini file or some sort of bin file. So indexing it, figureing out how to do that on top of having some sort of greater then less then would probably not be practical for you to add.
As far as some sort of indexing strategy i suppose having something like this might work.
Column index section - list of all columns pointing to a seconded section that has sorted column data
Sorted column data index - Sorted list of data that is easy to search through and contains the pos of the record.
At the front of the file you might have a list of the columns with a index (pos) of each of the secondary column data indexs.
These secondary index records would be the the data with the first 5 characters of a string or all of the real numbers sorted From Low to high. Then it would also contain the pos of the real row of data.
So you could search for column2 (a real, say 100) even if the data contained 1000's of other rows. It would search the beginning of the file find that column2 index is stored at file pos x, then looking at the secondary index it would find the starting data is 1, it could skip 100 records and maybe some are missing so it finds record data 105 then searches backwards till it finds 100 then grabs the record pos and returns that entire column of data from the real table.
Like i said it would be more complex. Real data would be stored as a file byte position at the start of the file as well. For where the real table data started.
Here is a example of what im talking about to try to clearify it.
Column Name sorted alphabeticly , File posistion of column index , Type
Column1 , byte 10 , real
Column2 , byte 20 , string
Column3 , byte 30 , string
Column1 index data (sorted), row posistion
5 , 1
Column2 index data (sorted), row posistion
a , 3
Column3 index data (sorted), row posistion
bike , 2
Then the real data would be following
Pos, Column1 , column2, column3
1 , 5 , b, zebra
2 , 20, d, bike
3 , 10, a, jump
4 , 25, c, plant
5 , 30, f, van
6 , 15, e, quick
7 , 35, g, carrot
So if i wanted column1 data 30 it would know it was on row 5 and could return column1 column2 and column3 only into a new table.
pos 5 , 30, f, van
Having ranges is important to minimize how many times you would call from a table.
Also maybe a search string like column3 contains "a" which would return 1 4 5 and 7
advanced contains would be like contains "ump" which would contain 3
These are just my thoughts on the matter as i do not know exactly how they are done in the professional world.