I am currently toying with a little pet project on my spare time, and has come upon a pretty big obstacle. I need a database solution that can be compiled into a Cocoa app and store Unicode strings in it. So far I've tried the usual NSArray/NSDictionary approach, but it becomes very slow and unusable with a large number of entries in a database (my database contains 115,316 entries in it, and searching through it is not easy). Moreover, it saves and loads very slow (about 10-12 seconds on an application launch).
So what other options do I have?
- Valentina SDK - a very fast and robust engine, which could be ideal for my needs (especially since we have a license since the Unsanity Echo days) - but it cannot handle Unicode, only ASCII, which is not good for my purposes;
- SQLite - another nice engine, but from what I've read on its site, it cannot handle strings that contain \00 - which makes it impossible to store unicode text in it directly. I think NetNewsWire uses SQLite, any tips/ideas, Brent?
- What other options are there?
Your ideas and suggestions would be greatly appreciated. To reiterate, I need to store lots of unicode strings, and search through them, and it gotta be faster than NSDictionary.
Posted by slava at 05:10 AM
| Comments (11)
| TrackBack (0)
Related:
- Betas, Twitter and WTF - Feb 16, 2010
- Quick Status Update - Feb 12, 2010
- It's Winter, Right? - Jan 26, 2010
- Hiya Kids, it's Theming Time! - Oct 06, 2009
- Mighty Mouse with Some Theme Sauce - Jun 02, 2009
I'm using SQLite in SpamSieve. You can compile it with UTF8 support. It doesn't handle embedded nulls, so if you have binary data you would need to encode it first. But for Unicode text it should work fine.
One thing you should be aware of is that it doesn't maintain its cache between calls to the library. So if you're mostly doing a lot of searching, the performance might not be as good as with another engine. I think you'll like it much better than property lists, though.
Posted by: Michael Tsai on March 18, 2003 11:13 AMAnything wrong with using MySQL? There's a Cocoa wrapper, . It supports storing binary data.
Posted by: Zig on March 18, 2003 5:28 PMWell, if you don't actually need to use Valentina to manipule the strings, then you could always store the strings as UTF-8 instead of UTF-16.
Posted by: Rincewind on March 18, 2003 5:37 PMSpent some time a couple of years ago embedding Valentina inside an application. I would recommend against using it. As time went by the developer shifted Valentina's focus. It went from being a nice lightweight C++ semi-object oriented database to being just another SQL-ish implementation. It became very difficult to do anything with Valentina without using embedded SQL statements.
Posted by: schwa on March 18, 2003 6:15 PMHow about libmysqld:
http://www.mysql.com/doc/en/Nutshell_Embedded_MySQL.html
It's pretty much designed for what you're describing, and in the development tree (4.1) Unicode-8 is supported.
Sleepycat Software make the Berkeley DB package. It's the standard for lightweight embeddable databases, and is very binary safe. Also has the advantage that your database files are portable between platforms.
If you're after something with more power, try FireBird. It's the open source version of Borland's InterBase. There's an OS X port, I believe, but beyond that I know nothing.
--Nat
Posted by: Nathan Torkington on March 19, 2003 8:00 PMHave you considered db.h? It's the Berkeley DB stuff, that eventually became Sleepycat Berkeley DB listed above, but it's a much earlier version. It'll probably do everything you want it to, and it has the advantage of not tainting your source like the Sleepycat version.
Posted by: Jan Kujawa on March 20, 2003 7:35 PMHi Slava,
I have good news for you. Next month we will make Unicode in Valentina.
Posted by: Ruslan on March 24, 2003 2:56 PMYes Guys,
if somebody not know. mySQL is NOT FREE.
In fact it is VERY VERY expensive as only as you want distribute application embedding mySQL
Hi schwa,
I very dissapointed to read your words, but I believe you are not right.
Valentina C++ SDK do NOT in any case force you to use SQL. you can use the same Object-Relational features which was 2 years ago.
Just look, SQL codebase take only 238KB in the kernel of size 1.07KB. So it is clear that the main power of Valentina still is NOT in SQL.
I want underline, Valentina will be developed in both directions better SQL support, and more and more Object features (inheritance, special relations, ...)
In Valentina 2.0 we even plan to make plugin system, and developers will be able even REMOVE SQL parser+engine from kernel. I hope this will make you happy :-)