Found a thread in the sqlite forums. It sounds like they are bundling a modified version of sqlite, which has sqlite's native buffer/page layer replaced with BDB.
Di Mär 30 2010 12:37:23 EDT von IGnatius T Foobar @ Uncensored
Would I do it with Berkeley DB today? Probably not. Today we have things like SQLite available that would have given us a schema layer *and* embeddability.
It's not worth switching over at this point because we already did all of the heavy lifting, but if we were starting the project today, things would definitely be different.
which performs "realy well" *couch* as you can see if you ran firefox for a while and its db backend fills up.
maybe jetsql would have been the next best alternative ;-P
Di Mär 30 2010 11:38:34 EDT von IGnatius T Foobar @ UncensoredYou know, like all of that HP-RISC assembler that you tend to find in stored procs. (?)
well, rather pl/sql not being as pl/sql if you're on oracle or sy aeh mssql or postgres and by no chance if you're on mysql
which performs "realy well" *couch* as you can see if you ran firefox
for a while and its db backend fills up.
Specious. Nobody knows where Firefox is leaking its memory, least of all the firefox developers ;)
Interesting. I guess once that version finds its way out to the world's operating system repositories, we will have the option of using it ... maybe even spending the next couple of years gradually migrating everything out to SQL instead of forcing the issue all at once.
and some more RDBMS advice from the trenches: just drop all your
foreign key constraints already. if your app is small, you don't need
HA! That's funny. I hate fk constraints almost as much as I hate stored procedures, but try explaining to a territorial dba (read: all of them) that their fancy dancy constraints are fucking everything up.
Oh yes, the big bad evil DBA, who wants to "make you use nonportable
stuff." (Huh? WTF?)
I ask (although lately it's been turning into 'tell' and 'yell') my dba to create table X. I have him do it so he can add all the silly index names I could care less about and data segments and what not.
And what do I find?
I find foreign key constraints from my table against a new table that he made. He took my data out of my dev table and decided those were all the values that could be in my 'type' field so he made another table just so he could add forign key constraints against it.
Not my idea, I didn't ask him to, and it certainly didn't have prod or preprord ready data in it.
non portable isn't the only problem with some DBAs.
explanation is that they are generating 10's of billions of records a
month here and a relational database big enough to handle it would be
See? It's not even that it's too smart or slow, it's just plain expensive.
Is his name Mel?
Do you mean mel as in melissa or mel as in mellon? But either way, no.
Specious. Nobody knows where Firefox is leaking its memory, least of
all the firefox developers ;)
That's really sad, isn't it. Here they are trying to save the world from microsoft and either they can't or they don't bother to fix the memory leaks. Andit's gotten to the point where everybody knows it and does nothing.
HA! That's funny. I hate fk constraints almost as much as I hate
stored procedures, but try explaining to a territorial dba (read: all
of them) that their fancy dancy constraints are fucking everything up.
The funny thing is, we don't use them at $workplace, as far as I can tell, we never have. This probably goes back to the dawn of time when HJM wrote all the code and did the DBA stuff himself. So it's become standard practice here, and now the DBAs are defending it because it's become defacto standard, and they don't want any inconsistency, or extra work, or to change the status quo, and they probably realize the advantages by now.
One of the reasons why I *like* our DBAs. (Well... sometimes ;) And it goes to show: if you don't like what your DBAs are doing, the solution is simple: be the Creator.
Mar 31 2010 10:46am from Peter Pulse @uncnsrd
I see it from a different point of view.. if I am going to pay a
kazillion dollars for a database and people to run it, it damn well
better have referential integrity. That is one of the MAJOR selling
points of these systems isn't it???
Ok, well yes and no. It's a major selling point of RDBMS in general I agree with that. I don't agree that it's a major selling point of Oracle in specific, because it's become a very commoditized feature let's face it. Most of the major open source RDBMSs implement it... the value proposition of Oracle is further up the pyramid, with things like partitioning, and RAC, and replication, and all those fancypants SQL extensions, like analytical queries (some of which are standard ANSI SQL now, btw.)
In any case, foreign keys sometimes just don't work, because they can impose unpredictible lock orderings on your queries. Every time you issue DML on a constrained table, Oracle (and probably every other RDBMS suffers the same problem) spawns a child cursor/query against the parent/child tables to check indexes and enforce constraints. That child query creates the lock-order problem and as near as I've ever been able to tell, the ordering is simply undefined and can't be relied on.
So most likely FK constraints will work just fine for you for months or years, but eventually as your load creeps up and your schema becomes more complex and you have more and more disparate queries hitting it, you will start running into ORA-00060 (deadlock.) And most likely the problem is universal across RDBMS.
When this does happen, you can spend a lot of time scratching your head, analyzing Oracle dumps, and trying to fix your queries to consistify the locking order. But you will likely fail - so you either have to code around the ORA-00060 with retries, or just drop your constraints. Best not to go down the analysis route - it's so unlikely to work - just retry queries or drop constraints.
This is one reason you should never write code that DEPENDS on the presence on FK constraints in some what, particularly code that relies on CASCADE DELETE. Code must continue to function properly if the constraints have to be dropped, some day.
some what = some way
Speaking of our genius DBA, I was somewhat surprised that sybase didn't have cascade delete, and because of some reason I forget I wanted to delete stuff in the cascade delete order, but the foreign key constraints the DBAs put on my tables didn't allow for that.
So my sprightly (spritely?) dba told me he'd write a trigger to implement cascade delete
Scratching my head I wondered how this was going to work without removing the fk constraints. After much banging his head, he let it drop, as in gave up, and I still have to delete my stuff backwards.
Shouldn't be that hard. But it is, it always is.
I recently reached a milestone in my life. Since I was about 23 or so I've never run less than 2 machines, one for my use and one fo the websites I run and mail and whatever else. Well finally I consolidated, and I have everything on one big ass machine.
There are many downsides, but this is the way it's going to be for a while, and I think my most pressing problem is that I have no online machine to back this machine up to.
I used to rsync back and forth between the two. Now there's nowhere to rsync to.
This machine has raid0 via linux so it's not completely at risk, but I'd still like somewhere else to go.
so I was thinking the memorystick angle. I see you can buy a 64gig stick on ebay for about $20-$30. Is this reasonable or is this crap from china that will write once read never?
Or does anybody have a better idea? I've got about 36gig to back up at the moment.
Sad my whole online life fits in 36gig.
That trigger might actually work on Oracle because of the deferred constraints feature.
I bought a 1TB external disc for backup, but Steve Ballmer probably made me do that.
Check it out if you use Windows and haven't seen it.