Language:
switch to room list switch to menu My folders
Go to page: First ... 61 62 63 64 [65] 66 67 68 69 ... Last
[#] Tue Mar 30 2010 11:57:01 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Oh, right, I forgot about that.

Remember how long it took to stabilize Citadel on top of Berkeley DB? You can't say the API made development easier for us initially. SQL would have been easier (except for the fact that Citadel was a legacy system which would have had an impedance mismatch with SQL) although you might argue that putting Citadel on Oracle would have traded increased administration burden for initial ease of development.

There's always lots of interesting stuff going on in the low-end, embedded SQL microserver realm though.

Is SQL the right tool for every application? Obviously not, but for your typical interactive web app it's the appropriate swiss army knife.

[#] Tue Mar 30 2010 12:24:57 EDT from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think maybe I was trolling you just a little bit but you wouldn't have fallen for it if you hadn't gone into pompous mode just a little bit :) You forget who you are preaching to.. or at least me, you, Ford. We've been there, we know the tradeoffs. Where I am working now they use Oracle but only for the basic data, the bulk of the data is in flat files or a proprietary record manager they developed for their application. And I came in very skeptical of that. But the 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 ridiculously expensive.

[#] Tue Mar 30 2010 12:29:35 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


It's not a /mode/, it's a /lifestyle/.

[#] Tue Mar 30 2010 12:37:23 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Remember how long it took to stabilize Citadel on top of Berkeley DB?

You can't say the API made development easier for us initially. SQL

My primary goal was (and still is) to have a database back end that could be linked in as a library instead of requiring DBA-like activities everywhere the software is installed.

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.

I got into some superheated arguments with Mr.T about this. He wanted a totally decoupled store using an external RDBMS. He said it wasn't an issue.
I argued that requiring all of those extra steps for installation would limit the take-up of the platform. It's a decade or so later now and I still think we did the right thing.

[#] Tue Mar 30 2010 12:41:45 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ford. We've been there, we know the tradeoffs. Where I am working now


There are a lot of tradeoffs involved in dealing with wheel reinventers... I know you and I have both had to deal with their mess after they've flown the coop.

[#] Tue Mar 30 2010 12:44:15 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And yet, even they, typically use Sybase. And fancypants abstractions

like message queueing. There's a level below which busybusy people just

generally don't want to go, evenn the performance oriented busybusy
people.

We are talking about two different groups of people then. I mean I know a guy who writes financial software and they use mssql and they have this terribly tiered client server server system or something like tht.
But I also know a guy who's bonus is directly tied to how many transactions per second he can pump through.
no joke.

[#] Tue Mar 30 2010 12:51:00 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Is his name Mel?

[#] Tue Mar 30 2010 13:34:04 EDT from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

your data quality will suffer in some ways, but you won't notice too

often. the only practical problem is that your data architect will hate

you. solve this by not hiring a data architect in the first place ;)

<laughs> Perfect!

[#] Tue Mar 30 2010 14:13:18 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

http://www.oracle.com/us/corporate/press/063695

Oracle Announces Latest Release of Oracle(R) Berkeley DB

[#] Tue Mar 30 2010 14:35:07 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Am I reading that correctly? They're putting a SQL layer into Berkeley DB?

[#] Tue Mar 30 2010 14:47:18 EDT from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

IG - that seems to be what they're saying..

[#] Tue Mar 30 2010 14:55:48 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Tue Mar 30 2010 15:13:43 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

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



[#] Tue Mar 30 2010 15:15:07 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Di Mär 30 2010 11:38:34 EDT von IGnatius T Foobar @ Uncensored
You 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



[#] Tue Mar 30 2010 15:50:03 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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 ;)

[#] Tue Mar 30 2010 15:58:51 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Yowza. That's exactly what they're doing.

http://www.lenzg.net/archives/295-Berkeley-DB-now-supports-SQL-again.html

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.

[#] Wed Mar 31 2010 10:37:50 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.


[#] Wed Mar 31 2010 10:46:14 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Mar 31 2010 10:46:53 EDT from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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???

[#] Wed Mar 31 2010 11:53:09 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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

ridiculously expensive.

TADA!!!!
See? It's not even that it's too smart or slow, it's just plain expensive.

Go to page: First ... 61 62 63 64 [65] 66 67 68 69 ... Last