[Kstars-devel] branches/kstars/carbonix/kstars

[Alexey Khudyakov]

On Tue, Jun 15, 2010 at 1:54 AM, Victor Carbune
<victor.carbune at gmail.com> wrote:
>> I think it would be better to generate database during build phase and
>> install it as data file. The less we touching $HOME the better.
>
> Yes, the database should be shipped as a prebuild file (this was the
> idea, I think I made some confusion when I wrote).
> I'll move the KStarsDB class probably in the data/tools folder.
>
> There should be, however, a class which manages the interaction with
> the database. KStarsDB was my target for this (having the conversion
> methods as well). Or, would it be sufficient to let the developer do
> the queries manually using the normal Qt SQL Driver provided?
>
"When in doubt use brute force". Just use simplest method. When it fails you'll
have enough information to make right choice.
> Thanks! I will be working this week on a query dialog (using the
> KSObjectList class I wrote about on my blog) which will search through
> the database. Also, I'll populate the database with more objects,
> starting after another exam, on wednesday.
>
> I'm also thinking at the way the user will update the list of objects.
> A suitable method would be on downloading small chunks of data and
> insert them into the database after download, step by step? I find
> this as a flexible method, from all points of view - both developer,
> and the user.
>
> We'll just provide some standard ascii catalog file (similar to the
> ngcic.dat) the user downloads it similar as it does with the current
> extra catalogs and KStars updates in the backend the database with the
> newly downloaded information.
>
> Another method, which would operate the same as it is done with
> multiple catalogs, would mean multiple prebuild databases (but this
> wouldn't actually work efficient though, since the idea is to have a
> central database).
>
This bugs me too. SQL databases lack additivity one cannot just drop two
databases into one directory you have to merge them long and error prone.
Personally I don't like idea of database in users $HOME. Especially writeable
database. Ideally it should be possible to just drop files in the catalog and
everything works. This will play nicely with package manager too.

Perpormance could be an issue too. Does SQLite perform well with queries which
return hundreds/thousands of objects? Such queries may arise when drawing onject
on a map.

There is another aspect. SQL doesn't solve problems with star catalogs.  They
are just too large and I cannot see any real difference between stars and
deep-skyes. Stars have proper motion and that's all and doesn't have visible
size but every other aspect is the same: names, multiple designations, multiple
catalogs.

Maybe we should concenrate instead on method which _can_ work on star but test
it on deep-sky objects first. Although I don't know how should looks. Any other
opinions? All kinds of ideas are welcome