Whether or not the the secondary columns are needed is a function of one
of the primary columns. That function involves values from another
table, though, so the general case would require a join. That other
table is small, however, so I generally cache it outside the database.
Some pseudocode for my expected use would be something like:
prepare("SELECT primary_columns FROM big_table WHERE some_criterion")
while(step()) {
if( F(primary_column_values) ) {
Fetch secondary values
}
do something with primary and maybe secondary values;
}
Where F would be implemented outside the database.
Thanks,
Jeff
Richard Klein wrote:
>> I'm pretty new to databases, and I have a schema design question. I
>> don't know enough about the guts of how sqlite works to know how to make
>> some tradeoffs. I have a large (potentially millions of entries) table
>> and it has 4 columns which are needed for every entry, and 4 more that
>> are needed for about 10% of the entries. I'm trying to decide whether I
>> want one table with 8 columns with a bunch of NULLs or two tables with
>> no NULLs that will require a join to get all of the 8 column values. I
>> assume this is a space/performance tradeoff, since I would think
>> searching one table would be a lot faster than doing a join, but I'm not
>> sure what the impact would be in terms of disk/memory/performance of all
>> those NULLs.
>> Does anybody have any suggestions?
>> Thanks,
>> Jeff
>>
>
> Can you give us a little more information? Specifically, is there any
> way to tell, by looking at the 4 primary columns, that you are dealing
> with one of the 10% entries that requires looking at the 4 secondary
> columns?
>
> - RichardKlein
>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
