Results 1 to 7 of 7

Thread: A less "texty" alternative to sqlite?

  1. #1
    Join Date
    Nov 2008
    Beans
    230

    A less "texty" alternative to sqlite?

    I've been reading sqlite documentation and examples and two things caught my attention.

    1-It seems that sqlite gives any entry in the database to you as a string, even if its a number. I say this because the callback function receives an array of strings. This looks a little bit inconvenient.

    2-I would like it more if I had specific database functions at hand instead of having to express everything in a text based format (i.e. the SQL language). This for example makes debugging the program easier; if your SQL is wrong, you'd see that only at run time and not at compile time.

    So, first, am I misunderstanding Sqlite? and if not, is there any alternative database library that may suite my taste better?

  2. #2
    Join Date
    May 2007
    Location
    Leeds, UK
    Beans
    1,664
    Distro
    Ubuntu 13.10 Saucy Salamander

    Re: A less "texty" alternative to sqlite?

    You didn't mention a programming language but all the bindings for SQLite are similar. These are the functions from the C library for retrieving the value of a column after issuing a query. As you can see, many of them return values other than strings:

    Code:
    const void *sqlite3_column_blob(sqlite3_stmt*, int iCol);
    int sqlite3_column_bytes(sqlite3_stmt*, int iCol);
    int sqlite3_column_bytes16(sqlite3_stmt*, int iCol);
    double sqlite3_column_double(sqlite3_stmt*, int iCol);
    int sqlite3_column_int(sqlite3_stmt*, int iCol);
    sqlite3_int64 sqlite3_column_int64(sqlite3_stmt*, int iCol);
    const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);
    const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);
    int sqlite3_column_type(sqlite3_stmt*, int iCol);
    sqlite3_value *sqlite3_column_value(sqlite3_stmt*, int iCol);
    Why did you think the SQLite libraries could only return strings? Are you looking at a different API?

    You are quite correct that when issuing SQL to a database via a library, you won't find out if your SQL is wrong until you run the code. That's true of most relational database access libraries in my experience. SQL is still the standard way of accessing relational databases. There are frameworks that allow you to work with objects rather than databases but the choice of those would depend on the programming language and target systems. Even then, although the SQL is generated, you don't always get complete validation against the database at compile time.

    It would probably help to provide an idea of the amount and complexity of data you are thinking of, and also your programming language and expected target systems.
    Please create new threads for new questions.
    Please wrap code in code tags using the '#' button or enter it in your post like this: [code]...[/code].

  3. #3
    prodigy_ is offline May the Ubuntu Be With You!
    Join Date
    Mar 2008
    Beans
    1,219

    Re: A less "texty" alternative to sqlite?

    1. SQLite has several datatypes and you can perform numeric comparisons for integer/real types: http://www.sqlite.org/datatype3.html

    2. What's the point of working with a DB if you don't want to use SQL at all? Nobody forces you to use it for data processing though.

  4. #4
    Join Date
    Aug 2011
    Location
    47°9′S 126°43W
    Beans
    2,165
    Distro
    Kubuntu 14.04 Trusty Tahr

    Re: A less "texty" alternative to sqlite?

    Quote Originally Posted by TheHimself View Post
    if your SQL is wrong, you'd see that only at run time and not at compile time.
    When you do DB development, you test your SQL queries (for correct results, but also for performance) against a DB outside of any code, so when they are added to the rest of the code (as hard-coded string constants or as some text file) they can be assumed to be correct. What you debug is how your code fills the parameters to these queries and what it does with the results.

    And when you go beyond the basic SELECT or UPDATE, you find that API calls just wouldn't cut it... SQL has about the same status in application code as the notation for regular expressions...

  5. #5
    Join Date
    Nov 2008
    Beans
    230

    Re: A less "texty" alternative to sqlite?

    Thank you guys and specially r-senior. I didn't know about those functions. The sqlite documentation on its website is pretty terse.
    I'm using C and want database support for storing and retrieving file data and metadata. So the columns would be file name and path, modification date, tags, rating, etc.
    Actually what I want to do is to write an open source alternative for Mendeley desktop (for organizing scientific papers). I have some experience with C and GTK but have not used databases before.

  6. #6
    Join Date
    May 2007
    Location
    Leeds, UK
    Beans
    1,664
    Distro
    Ubuntu 13.10 Saucy Salamander

    Re: A less "texty" alternative to sqlite?

    As this is a Gnome/GTK application, you should make yourself aware of GDA: https://developer.gnome.org/libgda/stable/index.html.

    I've never tried it, but the main benefits I'm aware of are increased portability and some widgets for use with GTK:

    https://developer.gnome.org/libgda/stable/ch22.html

    It could be that the grid control in itself is worth the pain of learning GDA -- but if you thought the SQLite documentation was terse ...
    Please create new threads for new questions.
    Please wrap code in code tags using the '#' button or enter it in your post like this: [code]...[/code].

  7. #7
    Join Date
    Nov 2008
    Beans
    230

    Re: A less "texty" alternative to sqlite?

    Thanks a lot. It has some useful features.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •