Re: [sqlite] Most wanted features of SQLite ?
You mean like http://www.sqlite.org/contrib ? I agree though there's much to improve in that area... Itamar. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Grzegorz Wierzchowski Sent: Monday, September 21, 2009 1:34 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Most wanted features of SQLite ? BTW while we are at subject of SQLite extensions. I'm very new on this e-mail list but already saw here and there in mails several links to places around the web with some extensions. What would you say guys for creating some centalized list of (known/recommended ...) extensions somewhere on official Sqlite wiki. I found: http://www.sqlite.org/cvstrac/wiki?p=ManagementTools , but this seems to be mainly about external programs like GUI or Management tools. I mean similar list but with links to general purposes code (open source licensed) for things like: - virtual tables modules - some usefull expression functions not implemented in mainline - special collating functions usable for wider audience, etc. I think it could be quite helpfull "first check place" if anybody is looking for something like virtual table which stores data in csv files, or so, or opposite - have wrote something general, and want to share. Best Regards, Grzegorz W. Monday 21 of September 2009 09:36:15 Roger Binns napisał(a): > Alexey Pechnikov wrote: > > SQLite does have the best extensibility of known to me DBMS. > > Also not mentioned is that it is available under a public domain > license and hence anyone has the right to use it in any way they deem > fit, make changes, distribute changes, charge anything they want, keep > everything public, private or anything else. Some of the alternatives > are open source but more restrictive (GPL). I've never read the > Oracle license agreement but there are many claims on the Internet > that its license agreement forbids publishing of benchmarks! > > Many of the feature requests are ultimately asking (or hoping :-) that > someone else will do the work. If something is that important then it > isn't unreasonable to pay DRH and team to do it. They also provide > support: > > http://www.sqlite.org/support.html > > Note "modest fee"! The extensions are also very cheap and liberally > licensed. No matter how you look at it, SQLite is a bargain. > > Roger > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Most wanted features of SQLite ?
Having to support a dedicated language for stored-preocedures sounds to me like an overkill, PL/SQL or not. IMHO having the ability to store complex queries in the standard TSQL syntax already supported today for queries, plus basic extra stuff only like loops, and have their compiled version executed, would be just enough (since as someone else has mentioned before most reasons to use SPs are irrelevant with most SQLite uses). If that's already an existing feature (afaik it isn't), then I have nothing else to ask for in this subject. Itamar. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Alexey Pechnikov Sent: Sunday, September 20, 2009 7:34 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Most wanted features of SQLite ? Hello! On Sunday 20 September 2009 18:16:19 sub sk79 wrote: > PL/SQL has a very wide user-base and a huge repository of existing > code-base in the world. Using StepSqlite PL/SQL compiler this huge > base can use SQLite by reusing their code as well as reusing their > skills - no learning curve for this set of users. But I write stored procedures and triggers for PostgreSQL on Tcl. You can write it on perl, java, etc. PL/pgSQL or PL/SQL is not the best solution to all. IMHO is more interesting any open source lang than proprietary PL/SQL. Oracle has a lot of a non-standart extensions which are not exists in SQLite. And Oracle ideology is very different. You may not replace Oracle to SQLite with the same application architecture. Best regards, Alexey Pechnikov. http://pechnikov.tel/ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Most wanted features of SQLite ?
As Igor mentioned in a previous post, Hebrew has no capital and lower case versions of a letter. It has only what's called Mantzpach, which are 5 letters which look different if in the end of a word; IIRC this is never an issue since they are ordered right after the original letter, and have their own character value (unlike capital/lower letters in English). Niqqud (the diacritical signs) are considered characters on their own, so you should either strip them (a common solution), or take that into account; here I'm not sure what is the default behavior. Also, since Hebrew letters are only used in Hebrew texts (unlike latin characters), sorting is hardly an issue if you have a Unicode representation of the character (usually a two byte one). The issues ICU is more likely to help you with are logical to visual conversion and the other way around and BiDi stuff. That's my own grasp of things, never had to use ICU myself. Itamar. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin Sent: Saturday, September 19, 2009 6:44 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Most wanted features of SQLite ? On 19 Sep 2009, at 3:07am, Igor Tandetnik wrote: > Simon Slavin wrote: >> Thanks to you and Jay for explanations. I hadn't encountered ICU at >> all before. Your descriptions make perfect sense and are very >> interesting since ICU is a good attempt to get around one of the >> fundamental problems of Unicode. > > Out of curiosity - what do you consider a fundamental problem of > Unicode? The fact that different people may prefer their strings > sorted differently? Only in that it's a fundamental problem with the way Unicode was defined. I completely recognise that the question of sorting cannot be answered at the level of characters for the reasons we discussed: different alphabets have different meanings for the same characters, and Unicode has just one entry for the character. It might have made more sense to define two levels of character definitions: one which says what 'c with a hat on' looks like, and another that defines alphabets, character alternatives, and where 'c with a hat on' comes in various alphabets. The problem I was referring to is that there's no consistent way of picking up which characters are variants of other characters. In the Roman alphabet, it would be very useful to be able to look at the codes for 'l' and capital 'L' and realise that they're somehow the same. In Hebrew it would be useful to be able match not only capital and lower-case characters, but also the variants used when a character occurs at the end of a word. ICU is a great way to approach these problems and similar ones. I have no problem with it. On 19 Sep 2009, at 3:17am, Roger Binns wrote: > Errr, this is not the fault of Unicode. Your reaction to my post is amusingly similar to my reaction when people assume that database synchronisation is simple. Sorry to have irritated you. I understand Unicode in more detail than we've discussed here. I do not consider these things to be 'the fault of Unicode' rather, in the words I used, 'problems with Unicode'. And I do consider Unicode to be far superior to the mess of code pages we used to have to implement before it became popular. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Two feature requests
Tim, In this context, you might find clucene useful. It's an IR lib written completely in cross-platform C++. It could be used just for what you're after using Queries and Filters. The git master HEAD is stable but still work in progress, or you could download the latest official release (quite outdated tho). http://sourceforge.net/projects/clucene http://clucene.git.sourceforge.net/git/gitweb.cgi?p=clucene/clucene;a=summar y Itamar. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Roger Binns Sent: Thursday, September 17, 2009 12:16 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Two feature requests -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Romano wrote: > Requesting these here, since I'm not quite sure how to go about it via > the WIKI (do you simply edit the request list there and prepend|append > your request to the list?) Generally you should enter them as tickets setting the type as enhancement request. You can see the open feature requests using the new Fossil source control system at: http://www.sqlite.org/src/info/084941461f The old cvstrac system has its requests at: http://www.sqlite.org/cvstrac/rptview?rn=8 (Yes it would be nice if they were merged :) > 1. An IFEMPTY(a,b) operator would be a convenience, analogous to [...] > 2. I would like to have a function that does a standard LIKE > comparison against a list of values: First remember the 'Lite' part of SQLite. Nothing is going to be added to the core unless it is substantially useful and would be used by the vast majority of users. So far SQLite users have survived just fine without these items :-) There are separate contributed extensions where your requests are generally more appropriate. See the contrib page at http://www.sqlite.org/contrib and in particular the last item - you'd find that author more receptive to your requests. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqxVW4ACgkQmOOfHg372QSEFwCeLbJ9de0gOszqUgivMgWWdBRY g04An2mY7/YDMjVa9KKbnh7uvFx4NYQo =Ecf8 -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Best approach for storing not-so-small BLOBs per record
Hi all, I'm in the design phase of an application with SQLite backend. The SQLite file will hold a table of about 20K records initially, and a few several other small tables. About 75% of the records in the large table will have binary data associated with it. My main question is which one of the following options I'm better off with to store those BLOBs, in terms of DB efficiency, memory usage, media seeks (since this will most likely to reside on a CD) and file size. The storage options I see relevant are: 1. BLOBs in the original table in a per-record basis (records with no BLOBs NULLified). If separating the BLOBs from this table will help performance in any way, I see two further options: 2. BLOBs in a separate table, and having the unique ID of the record in the large table point at this. No indices necessary, and will never use JOINs in queries since that table will be accessed explicitly on-demand only. 3. Same as #2 above, except in a separated, joint SQLite file (to aid file seeks). As mentioned, the binaries I'll be storing will only be pulled on demand (most queries to the large table will return the accompanying meta-data WITHOUT the binary data); no JOINs or foreign indices necessary. The average BLOB size is a few 10s of KBs; anyway I do not expect to have a BLOB over 1-2MBs. In the shelf version writes to the DB (particularly the large table) will very rarely occur; mostly only read operations, so I'm willing to take any cost to write operations. Also, looking up on compression support with SQLite I found 2 solutions - CEROD [1] and per-field compression using zlib and extension functions to compress / decompress. Are there more options I might have missed? Thanks in advance for any advice on this. Itamar. [1] http://www.hwaci.com/sw/sqlite/cerod.html ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
