Language:
switch to room list switch to menu My folders
Go to page: First ... 60 61 62 63 [64] 65 66 67 68 ... Last
[#] Mon Mar 29 2010 17:21:43 EDT from LoanShark @ Uncensored

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


oh well... throwing the baby out with the bath water is not really the first or best solution, nor is throwing away all semblance of software engineering best practices such as loose coupling, separation of concerns, and familiar high-level abstractions. it's really not a choice, it's something you do because you've run out of better options.


I would say... look at MySQL first if Oracle is too expensive, or any of the other open source options... I'd always take a good long hard look at optimizing the SQL based solution before throwing the baby out.

[#] Mon Mar 29 2010 17:37:47 EDT from LoanShark @ Uncensored

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

some thing our parent company is doing to optimize performance: (1) cache. they are developing an alternative to memcached (implements the same protocol) but has a natively clustered architecture. This will be open sourced eventually. (2) solid state disks. the i/o bandwidth and latency is so much better with solid state, that they were able to replace a cluster of 9 servers with like 1 or 3, and each machine needed less RAM.

[#] Mon Mar 29 2010 17:43:27 EDT from LoanShark @ 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 them; and if your app gets big, sooner or later your dbms will deadlock while enforcing the constraints.


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

[#] Mon Mar 29 2010 19:00:56 EDT from the8088er @ Uncensored

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

PC3-17600 DDR3-SDRAM (triple channel 192-bit) memory clocking in at


Although it's not triple chan, you can get 4 GB of PC3 17600 at Newegg for $190 shipped.

8 GB in Quad Channel (which I would think would be faster than triple channel) is $400 + shipping.

[#] Mon Mar 29 2010 19:06:09 EDT from Peter Pulse @ Uncensored

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

Kobayashi Maru: Build your software on top of a database platform so complicated that it will take all your time to maintain it, leaving you no time to get any real work done. Or hire a DBA who's job performance is measured by the correctness of the database, not the progress of your application development nor its performance.

[#] Mon Mar 29 2010 19:59:48 EDT from LoanShark @ Uncensored

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


I think that's a pretty ridiculous comparison. You can hire people and measure their performance by whatever you want to. Performance might be one of those. However the fact of the matter is that in a typical organization, NOBODY's performance is measured by software performance. Software performance is a team metric, not an individual metric, as you know perfectly well. While I'm on the subject: just rapid prototype on HSQL, and deploy to whatever you want. There is more than one way to skin a cat, and you don't have to wait for your DBA's at every step of the way (not that it's really such a hindrance even if you did.)

[#] Tue Mar 30 2010 08:33:39 EDT from IGnatius T Foobar @ Uncensored

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

In my experience, the problem is not databases, but rather DBA's. I don't know why, but they tend to be extremely rigid thinkers. Everything has to be done "by the book" even if empirical evidence shows that some other way yields better performance, shorter development time, or whatever.

(And then they'll do something stupid like put a "select * from *" on every screen.)

[#] Tue Mar 30 2010 09:04:55 EDT from dothebart @ Uncensored

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

plus make you use all the non portable stuff you've never needed before.



[#] Tue Mar 30 2010 10:45:00 EDT from LoanShark @ Uncensored

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


Oh yes, the big bad evil DBA, who wants to "make you use nonportable stuff." (Huh? WTF?)

[#] Tue Mar 30 2010 11:38:34 EDT from IGnatius T Foobar @ Uncensored

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

You know, like all of that HP-RISC assembler that you tend to find in stored procs. (?)

[#] 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?

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