Berkeley DB 4.5 available
Oracle Berkeley DB Release 4.5 now supports multi-version concurrency control, non-stop upgrades for replicated environments and a pre-built replication framework to simplify development of highly available applications."
Posted Sep 27, 2006 18:17 UTC (Wed)
by jd (guest, #26381)
[Link]
Posted Sep 27, 2006 19:07 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (8 responses)
Posted Sep 27, 2006 19:38 UTC (Wed)
by mikov (guest, #33179)
[Link] (6 responses)
Its only limitation is the exclusive database-wide lock for all write operations, but for low-concurrency usage Sqlite is the best IMHO.
Posted Sep 27, 2006 20:09 UTC (Wed)
by yodermk (subscriber, #3803)
[Link] (5 responses)
I'm starting a project using HSQL as its embedded DB. Seems like a good choice so far.
Posted Sep 27, 2006 20:12 UTC (Wed)
by trutkin (guest, #3919)
[Link]
Posted Sep 27, 2006 20:26 UTC (Wed)
by dark (guest, #8483)
[Link] (1 responses)
I'll start caring about it after I start caring whether my numbers are "int" or "smallint" in mysql :)
Posted Sep 28, 2006 9:26 UTC (Thu)
by hawk (subscriber, #3195)
[Link]
For instance, which is better use of 4 bytes, to be able to store numbers 0-9999 or 0-4294967295 (if we take unsigned integers as our example)?
(Or if you want really small numbers as your example, with one byte you get 0-9 vs 0-255.)
You do however have a point, but what I'd say is not that it's efficient, but rather that for many uses it may not matter that much that it's awfully inefficient.
Posted Sep 27, 2006 20:36 UTC (Wed)
by bronson (subscriber, #4806)
[Link]
Even after watching the video I don't understand why he wanted this loosey-goosey datatype "feature". Something about speeding up development like dynamic typing? Anyhow, it hasn't gotten in my way.
Posted Sep 27, 2006 20:36 UTC (Wed)
by mikov (guest, #33179)
[Link]
In any case, unless you are manipulating large chunks of data, the overhead of conversion to and from ASCII is often quite negligible compared to everything elese that has to happen.
You also fail to consider the fact that reading a binary integer from disk in Java (HSQL is written in pure Java) requires reading the bytes separately and combining them - that is not that different from converting ASCII to string - both operations have negligible overhead. PostgreSQL's JDBC driver also transmits almost all values as text 9even though the wire protocol allows binary) and so far this isn't seen as a serious limitation.
At one time in the past I looked at HSQL and from their website and documentation I couldn't get a good idea of the internal design. That discouraged me from looking further. By comparison SQLite has several in depth document explaining all aspects of the architecture in complete detail.
Of course, if you language is Java, SQLite is not a serious option - there is a JDBC driver for SQLite, but AFAIK it is not very complete.
Posted Sep 27, 2006 23:27 UTC (Wed)
by mato (guest, #964)
[Link]
They forgot to add that it is also fully buzzword 9000 compliant.
Berkeley DB 4.5 available
I used to use BDB because it was light and tight. Did exactly what I want. Over the past few years, however, it has become and overweight disaster and, from this press release, it appears that it's just getting worse. I've moved to sqlite now and I'm loving it. Berkeley DB 4.5 available
I agree. Sqlite is absolutely amazing - simple, reliable, efficient, well documented, supports a large SQL subset, and and as far as I can tell is beautifully designed. Berkeley DB 4.5 available
I got turned off to SQLite when I heard that it stored *all* data types, including numbers, as strings. You call *that* efficient? Or did they fix that? Berkeley DB 4.5 available
That doesn't make sense as the sqllite generated files are binaries. Berkeley DB 4.5 available
I don't see why it would be inefficient. Most numbers in databases are pretty small, so they don't take much space even compared to a binary representation, and I bet there are wins from treating all data types uniformly. Berkeley DB 4.5 available
It's obvious that if it does indeed store numbers as their string representation, that certainly is a big waste of space. Berkeley DB 4.5 available
That was true in v2, not in v3. See http://www.sqlite.org/version3.html in the "Manifest Typing and Blob Support" section. Or see http://video.google.com/videoplay?docid=-5160435487953918... where the author somewhat explains why he made this design decision. Berkeley DB 4.5 available
SQLite version 3 stores integers, floats and BLOBs as binary. Version 2 used to store everything as ASCII; while that incurred (usually small) overhead, it was a very simple and ellegant design. Berkeley DB 4.5 available
Hey, if they've actually implemented MVCC properly (which is something I'd expect from Oracle, since their server products have done this for years) then this is a Good Thing. We were looking at using BDB in one of our products a couple of years back but ran into major problems with locking. Having MVCC just makes all that pain go away. Berkeley DB 4.5 available