Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Source vs. the Database Vendors

Hemos posted more than 8 years ago | from the the-battle-is-joined dept.

Databases 183

bhmit1 writes "BusinessWeek has another spread on open source this week. Among them is an article about open source vs. the database vendors which focused on how businesses are looking to save money with open source (rather than using the source to innovate). From the article: "The databases work fine, but as data volume grows, so do the checks to Oracle, IBM, or Microsoft. Many users aren't clamoring for more features, and some don't even use the bells and whistles they already paid for. They would happily trade some to get their hands on the source code and a better deal." Disclaimer: that quote came from Sony."

cancel ×

183 comments

Sorry! There are no comments related to the filter you selected.

from sony (-1, Offtopic)

Amouth (879122) | more than 8 years ago | (#14651260)

wow they really are going out to their way to shove drm into anything arn't they.

ok bashing done.

personaly i agree most of the bess wishles arn't ever used.. i just one something that is fast and small

I like my 3 CD DB downloads from oracle (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14651264)

Why would I want a small download from mysql?

Re:I like my 3 CD DB downloads from oracle (4, Interesting)

hey! (33014) | more than 8 years ago | (#14651322)

Do you know what hell is?

Hell is having a product you have to explain to the customer.

Customers don't understand databases, so they're not likely to understand the difference between MySQL and Oracle. And, ironically, that might mean MySQL is where they ought to be. This isn't to disparage MySQL at all, but I'm just saying you can't explain the difference between MySQL and Oracle, you shouldn't pay the difference.

You may or may not pay for your lack of knowledge later.

Re:I like my 3 CD DB downloads from oracle (1)

CastrTroy (595695) | more than 8 years ago | (#14651595)

This is usually only the case when the person buying the product isn't the person using the product. Granted this seems to happen more than it should, but it shouldn't. Why do people have such a problem admitting that they don't know something, and just asking the people who do know.

Re:I like my 3 CD DB downloads from oracle (0)

Anonymous Coward | more than 8 years ago | (#14651602)

Customers don't understand databases, so they're not likely to understand the difference between MySQL and Oracle.

Funny, neither do web designers. :o)

ZING!

Re:I like my 3 CD DB downloads from oracle (2, Interesting)

jellomizer (103300) | more than 8 years ago | (#14651421)

When people pay for a product (or get one that is sopposed to be buisness class) they want a app that looks impressive on their bookshelf. A huge box filled with CDs. Any App work 10k has to have at least 10 CDs of data. When I was a kid running a BBS I saved up to buy Desqview for DOS. The app cost me $200 many months of chores. When I got it and took it out of the box I had a single 3 1/2 floppy. It woked but needless to say I felt a little disapointed. Espectially with some of the games I had took 6 of those floppies, and the game was only $20. Now after I have done programming I realize the value in making a small app that works well. But at the time and many management type they want to feel that got what they paid for.

Obvious (5, Insightful)

Anonymous Coward | more than 8 years ago | (#14651277)

... which focused on how businesses are looking to save money with open source (rather than using the source to innovate).

Duh. Isn't that the #1 draw for the majority of OSS users out there? Sure there are some that are in it for the politics and others who actually try to contribute, but let's face it, the majority of people use it because it's free (as in beer).

Re:Obvious (4, Interesting)

hey! (33014) | more than 8 years ago | (#14651369)

It's certainly the only reason businesses choose OSS, or proprietary software. Net present value of TCO over the planning horizon.

Until now, the free databases lacked accessibility for "drive by" business users. You don't have time to explore every option, even if it might lead to a better decision. Install Unix to check this thing out? Not today thank you.

MySQL as it now stands is probably the simplest real RDBMS for the casual shopper. It's just as easy as MS SQL server, and MS is the only vendor who understands the importance of the casual shopper. Postgres is not far behind.

Re:Obvious (4, Interesting)

IANAAC (692242) | more than 8 years ago | (#14651413)

MySQL as it now stands is probably the simplest real RDBMS for the casual shopper. It's just as easy as MS SQL server, and MS is the only vendor who understands the importance of the casual shopper. Postgres is not far behind.

Actually, have you tried installing the latest "light" versions of boh Oracle and DB2? They're dead simple to install and administer. Not to mention writing the actual apps. They now have pretty much drag-n-drop GUIs for app creation. I think most vendors are now realizing the importance of this group of buyers.

Re:Obvious (1)

hey! (33014) | more than 8 years ago | (#14651592)

Well, yes, they're getting there by process of imitation.

But they still aren't there yet. For example, try to figure out how to buy the mobile version of DB2. Or exactly which Oracle license you need.

By contrast, under MySQL things couldn't be simpler for users. Developers just have to grasp the dual licensing scheme, which isn't asking much.

Re:Obvious (1)

IANAAC (692242) | more than 8 years ago | (#14651763)

Well, yes, they're getting there by process of imitation.

Who are they imitating? Certainly not the MySQL folks, and certainly not for drag-n-drop db creation and development. To my knowledge, there is nothing comparable in the opensource world to these two companies' development products. I truly would love to see something similar (particularly for Postgresql), but to date I've not found anything.

Re:Obvious (2, Insightful)

thsths (31372) | more than 8 years ago | (#14652643)

> Actually, have you tried installing the latest "light" versions of boh Oracle and DB2? They're dead simple to install and administer.

I have tried Oracle, and I was not happy with the installation. Debian is not supported, so you have to fool the install script to go ahead anyway. I needed a hard disk update because I was running out of disk space (several GB necessary). The installation went fine, but it doesn't tell you what its doing.

So now I have several java application web servers, some of which seem to be essential for "user friendly" maintenance. I have a listener, and a database. And guess what? None of these parts start up automatically after a reboot. Figuring out how to restart it took ages. And I am still having problems with my connection definitions.

MySQL on the other hand couldn't be simpler. mysqld and libmysql.so, that's it. Hostname:port, user+password specifies your database connection. Lots of nifty tools around, in just about any language.

If you believe in KISS, MySQL beats Oracle any day.

Re:Obvious (2, Interesting)

squoozer (730327) | more than 8 years ago | (#14651486)

This is a really good argument for letting developers decide the technology rather than managers. Personally I would generally choose Postgres because I like the way it works and I have a good knowledge of it. MySQL would be up there on my list as well. I've used SQL Server (and just about all the other commercial offerings) and found it to be good but over complex for a lot of applications. Any developer that is writting detabase driven apps should be at least familiar with most commercial databases and Postgres and MySQL and able to make a decision about which to use.

Re:Obvious (1)

Eric Giguere (42863) | more than 8 years ago | (#14651882)

MySQL as it now stands is probably the simplest real RDBMS for the casual shopper.

Actually, easy installation and great out-of-the-box performance has always been a hallmark of SQL Anywhere [sybase.com] . Feel free to download the free developer edition [sybase.com] yourself and see. (Yes, there are Linux and Unix versions available, not just Windows.)

Eric
Redscowl Bluesingsky [cluelessabout.com]

Re:Obvious (2, Insightful)

KingoftheGreensdotCo (952345) | more than 8 years ago | (#14651953)

I think MySQL has a long ways to go before it will really be a contender. I know that is used widespread for small web setups, but before version 5 it really didn't have many of the standard features the bigger players had such as stored procedure support or even sub queries. my $0.02...

Re:Obvious (1)

pthisis (27352) | more than 8 years ago | (#14652510)

It's certainly the only reason businesses choose OSS, or proprietary software. Net present value of TCO over the planning horizon.

Simply untrue.

1. Businesses aren't about minimizing expected TCOs, maximizing expected profits, etc. Those are one factor, but things like cost-certainty, worst-case scenarios, etc are also very important.

E.g. if solution A has a 95% chance of costing $100,000 for the next 6 years, and solution B has a 100% chance of costing $106,000 for the next 6 years, but solution A has a 5% chance of costing $200,000 over the next 6 years--what do you do?

_Rationally_ (and I use that term in the economic sense) solution A has a lower expected cost and is the right choice.

In the real world, if you know that $200,000 would severely impede your chances to make money, or put you into bankruptcy, etc and $106,000 would not massively affect the business, you would probably go with solution B.

Cost-certainty is a major factor in OSS decisions.

2. Businesses don't act for only business reasons. Sometimes they make a choice because the owner or someone in a purchasing position loves a product or philosophy, or isn't the authority on a product but trusts a tech leader's judgement (who themselve doesn't make completely rational decisions). Sometimes they make a choice because somebody has a family member selling a product, or owes someone a favor.

I'd say that trusting some internal techie with product evaluation, when that techie happens to be a fan of a particular product and doesn't do a fair evaluation of what's the best tool for the job, is a major factor in most technology decisions both for OSS and for commercial products.

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#14652947)

It's certainly the only reason businesses choose OSS, or proprietary software. Net present value of TCO over the planning horizon.


Shortsighted and oversimplifiying.


Better to say "better expected return on investment than any alternatives".


There may be cheaper ways to put software on computers (as Microsoft is happy to point out in the get-the-facts campaign). But that (and your cheaper being the only reason claim) only look at the denonimator of the ROI equation. To show how oversimplified your TCO example is, consider that the TCO of a poor employee is often lower than the TCO of a strong one. But theh latter (just like open source software) has a much greater ROI.

Re:Obvious (2)

DrSkwid (118965) | more than 8 years ago | (#14651476)

nope

$0 is nice but I bought my first copy of Slackware [slackware.com] long before I could download it, I even had to copy it to (I think 22) floppies from cdrom so I could install it.

And even after I have downloaded them, I've paid for FreeBSD [freebsd.org] , plan9 [bell-labs.com] and Inferno [vitanuova.com] .

Free as in Freedom is more important than you give it credit for.

Just one business case is that one can mitigate risk by having multiple OS vendors to choose from. I know that if my chosen OS goes kaput or gets litigated out of existence then I won't go with it. And it doesn't cost me a fortune to try out the alternatives.

Re:Obvious (1)

TheRaven64 (641858) | more than 8 years ago | (#14651485)

See here [informit.com] and here [informit.com] . The bottom line is, of course, the most important incentive for a business but the FSF's four freedoms can each contribute to that final total. For many businesses the freedom from vendor lock-in is worth more than the zero purchase-price.

depends (4, Insightful)

stoolpigeon (454276) | more than 8 years ago | (#14651492)

I think it depends upon the scale. There are probably many small users out there looking at OSS databases to save money on licensing. And these types will be very happy to jump on board to a 'free' proprietary product. But there are some large companies with the resources and the desire to leverage access to the source code. A good example that comes immediately to my mind is Fujitsu's involvment with PostgreSQL.

Re:depends (1)

mcrbids (148650) | more than 8 years ago | (#14652765)

I think it depends upon the scale. There are probably many small users out there looking at OSS databases to save money on licensing. And these types will be very happy to jump on board to a 'free' proprietary product.

I don't know about this - as a small-company vendor myself, one of the main reasons I use OSS solutions anywhere possible is that "it can't get taken away" by changes in the licensing scheme. My license won't "expire" and the product won't be "EOL'd" as is so often the case with proprietary solutions. (Think: VB6)

There are many examples of this: PHP5 has been out for years, but PHP4 is still well supported, and is even the default (for example) on RHEL. Apache 1.x is still supported for security updates, and still represents a large percentage of the install base.

Postgres (the database on which I depend) is open enough and free enough, that even if the existing developers decided to hang up their hat, I'm quite confident that enough people in the community would step up to the plate to continue its support and development; in fact, I think this has already happened, in a sense, several times. Another example is the recent debacle with XFree86.org and X.org.

So, as you can see, it's not just cost. I'm very leery of Oracle's "little guy" offering, because it didn't exist before. I recognize that it's simply a way for Oracle to get their foot into my door, and I'm going to avoid it where a free-license, "they can't take it away" option exists.

Re:depends (1)

stoolpigeon (454276) | more than 8 years ago | (#14652881)

good point. though my last job that I just left a little while ago was still using VB 6 heavily. They can pull the plug on future support, but unless you plan on your stuff being around for more than 10 years, it's not that drastic. They don't take it away, they just stop giving it out.
 
Now at that job, the management was leary of OSS and I was always pushing it hard. Why? Well, they wanted the backing of a known name. Me, I got tired of just what you bring up, getting locked in. It really annoyed me to be stuck depending on what some company would do. When we started having problem with writing office automation code in vb6 on xp and 2000- the ms answer was to upgrade from office 97. But the company didn't want to spend the money. I was working on getting everything moved to open office before I left. I don't know what they'll end up doing.

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#14651619)

The #1 reason, at least for me, is the fact that the only goal of the software is to have happy users. So, no adware/malware, no proprietary format lock-in, no redirection to portal websites...
That is for me the most important freedom !

Not only free beer (1)

DrYak (748999) | more than 8 years ago | (#14651889)

the majority of people use it because it's free (as in beer).


This, and also because OSS is a way to avoid lock-in marketing techniques used by non-beer software providers.
Enterprises, specially, are not intersted only because it's free (beer) for them to use an opensource software, but also because it'll still either be free or damn cheap to switch to something else that better suits their needs,

Vendor lock? (0)

Anonymous Coward | more than 8 years ago | (#14652861)

This, and also because OSS is a way to avoid lock-in marketing techniques used by non-beer software providers.

Isn't it really the other way around? If you choose say PostgresSQL and then go in and make heavy mods, haven't you just locked yourself into PostgresSQL? Perhaps even deeper than you might have if say the source were not available to you (so you had to work around it). Let's say the Postgres guys decide to adopt GPLv3, if that causes problems, you are either stuck with the older non-v3 version, or you have to move to something else. How is this any different than vendor lock?

Re:Obvious (1)

molarmass192 (608071) | more than 8 years ago | (#14652044)

Well, I don't know if we're in "the majority" but we use OSS specifically to enable us to do deep customizations. Cost is not a factor in this, we spend a lot of jack on MS and Oracle as well. The vast majority of the customized code is customer facing. It's a sad reality, internal users (employees) we tell to "like it or leave", but we need to differentiate our wares for our external users (customers) or they will ignore/leave/whatever. OSS is a differentiator for us, not an economic advantage. On that note, we do use Linux (mostly) vanilla in a cluster of disposable servers, and that is partially a cost thing but also because Linux fits very nicely in clustered setups.

Re:Obvious (1)

elgaard (81259) | more than 8 years ago | (#14652117)

Yes, and even most of those that end up contributing, start using OSS because it is free as in beer.

I certainly could not have afforded a commercial Unix when I installed my first Slackware.

Large Wallets + Small understanding = nothing new. (5, Interesting)

peterdaly (123554) | more than 8 years ago | (#14651281)

In my work experience, I have concluded that the vast majority of "big name" database users vastly underutilize the features that the big bucks pay for. Many companies that generally only need a step up from MS Access but get sucked into Oracle or DB2 thinking that's the logical next step.

In addition, many database users don't have a realistic understanding of what constitutes a lot of data. I've met quite a few people that think a 10k row database is huge, and anything in the 1 million record range is absolutely gargantuan! To me, anything less than 1 million records is downright tiny. Seriously, many of these users don't need an "enterprise" RDBMS for scalability reasons, which is what leads many customers to open their wallets. Something like Postgres or MySQL would be more than adequate for their needs.

That is not to say there are not users who need the enterprise features, but it amazes me the amount of money that is dumped into features that most small to medium size deployments don't even use.

It is very educational to see how Oracle for example is used in real world deployments. Open source aside, I have seen many where the user may have been better served by just using a properly setup MS Access or FileMaker database!

-Pete

Re:Large Wallets + Small understanding = nothing n (1)

jellomizer (103300) | more than 8 years ago | (#14651319)

Well large is subjective. To a small company 10k of data is large. And when someones sells their apps for Large Database they jump on it because their database is big for them. Even though they would be better off with the smaller Database server because the algorithms are based for processing smaller values.

Re:Large Wallets + Small understanding = nothing n (1)

CastrTroy (595695) | more than 8 years ago | (#14651422)

You're a little bit off there. To a company with very little data, 10K of data is large. There's nothing saying that a small company can't handle lots of data if they do it in an organized manner.

Re:Large Wallets + Small understanding = nothing n (1)

(A)*(B)!0_- (888552) | more than 8 years ago | (#14651473)

"To a small company 10k of data is large."
No it's not. The size of the company is unrelated to the amount of data they have.

A more appropriate and true statement is: to a company whose largest database numbers 10,000 rows, 10,000 rows is a lot of data. But that's trivially obvious.

Re:Large Wallets + Small understanding = nothing n (2, Insightful)

smitty_one_each (243267) | more than 8 years ago | (#14651375)

I have concluded that the vast majority of "big name" database users vastly underutilize the features that the big bucks pay for.
Has anybody else encountered projects for database-driven websites where the script monkeys want to use the database like text file system accessed with SQL, and do all of the logic in script on the web server? I suspect that people understand procedural code most readily, and despise thinking in the set-theoretical terms of SQL. I used to be that way, until I started realizing that I can blow off a lot of coding/debugging by eschewing state and writing as much in SQL as possible.
Then there was that one Java project, where the database schema mapped directly to the inheritance hierarchy of the object model. Booting the application server took longer than booting the operating system. While no raging Java fan, I can't help but think that particular issue was coder ignorance writ large. Wrote the test plan, got out of that swamp ASAP.

Re:Large Wallets + Small understanding = nothing n (1)

erbmjw (903229) | more than 8 years ago | (#14651756)

Then there was that one Java project, where the database schema mapped directly to the inheritance hierarchy of the object model. Booting the application server took longer than booting the operating system. While no raging Java fan, I can't help but think that particular issue was coder ignorance writ large.
I've seen that problem before - in fact I've had to help correct that problem before - I thought that my brain was going to fry sometimes while I was reading the code ;)

Re:Large Wallets + Small understanding = nothing n (1)

Xugumad (39311) | more than 8 years ago | (#14651871)

I wrote an application like that once (I was young and foolish). But I'm better now, I swear (we spent most of summer removing that, and a few other screwups)...

Re:Large Wallets + Small understanding = nothing n (1)

Fujisawa Sensei (207127) | more than 8 years ago | (#14652011)

This isn't just a Java problem.

Mapping the Database hierarchy directly to the java class files is not necessarily a bad thing. It becomes a bad thing when you try to load and access it. :-P Meaning that you have to be careful and consciencious about how you manipulate things and where your transaction/session boundries. The use of entity beans is the greatest offender of this, followed by hibernate abuses. At long as you do not manipulate, or perform a minimun amount of manipulation, (like inserting primary and foreign keys), within the transaction boundries. It can become very efficient, depending on the design of the database. But if you are slopppy one mistake and your performance will crater.

My gripe is when people create 2 sets of nearly identicle class hierarchies, one to map to the database, one as data transfer objects, then proceed to copy one tree to the other everytime they hit the database. The more I see stuff like that the more I wonder why not just use JDBC, or Spring JdbcTemplate.

Re:Large Wallets + Small understanding = nothing n (1)

bloobamator (939353) | more than 8 years ago | (#14652080)

The real advantage to taking the business logic out of the db is: scalability. The db will always have much more limited scalability than the middle tier. It's much easier and less expensive to throw more app servers into production, than it is to throw more db servers in.

Re:Large Wallets + Small understanding = nothing n (1)

Doctor Faustus (127273) | more than 8 years ago | (#14652271)

The real advantage to taking the business logic out of the db is: scalability. The db will always have much more limited scalability than the middle tier. It's much easier and less expensive to throw more app servers into production, than it is to throw more db servers in.

Yeah, but updates should still be propagated to all the other app servers, leading to the same basic problems as in the lower tier. I have to think that the only reason the middle tier is more scalable is that the data integrity standards are lower.

Re:Large Wallets + Small understanding = nothing n (1)

commanderfoxtrot (115784) | more than 8 years ago | (#14652732)

Absolutely right.

The database is almost always the limiting factor- you can chuck in more web servers easily, but to expand the DB gets very complicated very fast.

Even when you work with decent mainframes, as I do.

It's the data... (4, Insightful)

Colin Smith (2679) | more than 8 years ago | (#14651451)

The user says "This is vital". IT staff start adding zeros to the price tag of the application. Seriously nobody in the IT dept is ever going to suggest something like mysql or postgresql for something like the corporate accounts or other financial transaction backends because people like IBM and Oracle guarantee that when the power goes out, the transaction completed, or it didn't happen at all.

And if you've paid for Oracle/DB2 and you're training your staff on and using Oracle/DB2 anyway then it doesn't make a load of sense to introduce different RDBMS systems that your DBAs and administrators are completely unfamiliar with, especially when you've got that Oracle box sitting there underutilised.

Ultimately you're right, 95% of apps could be served perfectly well by mysql, postgresql, msaccess, filemaker etc. Corporate IT depts should really create two categories of RDBMS systems, vital and casual. The vital ones being the core business operations and casual being everything else.

 

I've been fighting to get this done. (3, Interesting)

khasim (1285) | more than 8 years ago | (#14651899)

The user says "This is vital". IT staff start adding zeros to the price tag of the application.
Yep. And it is up to the requesting user to justify spending that money to the CFO.

It is not IT's job. IT just gives everyone the pricing based upon how many 9's of availablility you want and the database/server licenses.

If the user balks at that, the database can be put on the far less expensive PostgreSQL/mySQL server.

The downside is that the database people need to become familiar with TWO different databases (or more depending upon the other apps).

The upside is that the company saves a LOT of money in licenses and such.

Re:It's the data... (2, Interesting)

jadavis (473492) | more than 8 years ago | (#14652249)

because people like IBM and Oracle guarantee that when the power goes out, the transaction completed, or it didn't happen at all.

What kind of guarantees do they actually provide? For all of Oracle, IBM, and PostgreSQL the likelihood of a hardware error is far greater than the likelihood of a software error that leaves the database inconsistent.

So what, will Oracle pay you money if a software failure occurs? What about a hardware failure?

From a technical standpoint, PostgreSQL is probably more trustworthy when it comes to data integrity. Oracle is often installed on better hardware, but that's not the fault of PostgreSQL.

Re:It's the data... (3, Interesting)

Lumpy (12016) | more than 8 years ago | (#14652586)

The user says "This is vital". IT staff start adding zeros to the price tag of the application. Seriously nobody in the IT dept is ever going to suggest something like mysql or postgresql for something like the corporate accounts or other financial transaction backends because people like IBM and Oracle guarantee that when the power goes out, the transaction completed, or it didn't happen at all.

you are very wrong. MANY companies depend on MySQL in the ways you mention and by spending the cash you saved into hardware I also can guarentee that the transaction completed or it didn't when the lights go out.

It's called decent hardware, decent Backup, decent UPS. my servers can run a FULL 45 minutes on UPS before they haveto start shutdown proceedures. coupled with Battery backup RAID cards and a raid 51 and I got huge stability in hardware for the cost of the DB.

You act like nobody but some 13 year olds with a website use MySQL. I suggest you take a look at the mysql website and educate yourself with their information.

Re:Large Wallets + Small understanding = nothing n (1)

Lonewolf666 (259450) | more than 8 years ago | (#14651463)

Sometimes, it is an attempt to get the greater reliability that is frequently attributed to the "big" systems. Justified or not, RDBMS like Oracle or DB2 have a reputation of being less prone to crashing or data loss.
This said, I would probably go for somthing like Postgre or Firebird myself. But NOT Access, I've heard from our service department that the Access databases of a certain device tend to crash when they grow beyond 1 GByte.

Re:Large Wallets + Small understanding = nothing n (2, Interesting)

squoozer (730327) | more than 8 years ago | (#14651519)

I agree 100%. I have worked on plenty of development jobs where management wanted to use SQL Server (normally) or another big name database because they thought they had a lot of data. Typically we were storing a few hundred products and maybe 10000 orders. I voiced the opinion that that wasn't much data and an OSS database such as Postgres or MySQL would easily handle it. I've never recieved such dirty looks. I think the managers want the prestiege of using a "real" database.

Re:Large Wallets + Small understanding = nothing n (0)

Anonymous Coward | more than 8 years ago | (#14651568)

I don't think the database size is the main deciding factor (any more). The main factors are:

  • Is the DBMS trusted? Is it well known?
  • Do the developers have work experience with the product?
  • Are good tools available?
  • Performance? Stability?
  • Is it scalable (clustering) in case it's needed?

Databases that fit in this description since a long time are: Oracle, MS SQL Server, DB2. New on the list are: MySQL, PostgreSQL. Wikipedia link: List of RDBMS [wikipedia.org]

And maybe some will be added to the list in the future, like Firefird, and who knows H2 [h2database.com] .

Ease of use? (0)

Anonymous Coward | more than 8 years ago | (#14651685)

Ease of use is important as well. Or maybe not (see Oracle).

Re:Large Wallets + Small understanding = nothing n (1)

AnotherDaveB (912424) | more than 8 years ago | (#14651574)

Many companies that generally only need a step up from MS Access but get sucked into Oracle or DB2

Google Adwords uses MySQL [blogspot.com] .

Foxpro (0)

Anonymous Coward | more than 8 years ago | (#14652057)

Many companies that generally only need a step up from MS Access

Correction. You misspelled MS Foxpro [microsoft.com] .

Re:Foxpro (0)

Anonymous Coward | more than 8 years ago | (#14653017)

Foxpro is a horrible piece of trash that should have been left in the late 80's.

Not everyone cares about Coding... (4, Insightful)

jellomizer (103300) | more than 8 years ago | (#14651282)

It may surprise you but most people who use open source applications do not change the code. Even the ones who know how too, don't. Why, because they don't have the time. They download it try it, if it does what they need they use it, if not then they try an other product, if they cannot find an Open Source tool that does the job then they see if there is a commercial one that does. Programming takes time, even an open source application, time costs money, so if paying 2k for MS SQL Server vs. 3 weeks of development, to get the functionality they need they will just get MS SQL and they will save money. Plus this time could be used by the programmers to create business critical code (Which earns $$$), vs. IT Infrastructure code (which costs $$$, but may save $$$$ in the future). As some of your open source developers may or may not realize your cool feature may not be used by anyone buy yourself. Heck I have a hard time to get people to used Stored Procedures in their SQL, needless to say trying to get them to use the more advanced features.

Re:Not everyone cares about Coding... (1, Insightful)

phooka.de (302970) | more than 8 years ago | (#14651498)

Heck I have a hard time to get people to used Stored Procedures in their SQL, needless to say trying to get them to use the more advanced features.


Stored procedures are BAD BAD BAD, I'm glad you have a hard time promoting those. Why?


- You can't easily migrate to another database-vendor. Maybe you want to switch. Maybe you have to because of technical reasons. Maybe you have to because your company is being bought by another, which uses a different system and wants to maintain only one platform. Whatever the reason, your stored procedure is going to really, really hurt.


- Usually, there is only one database but several application servers. You want to take load off the database because it scales not as well as the application servers, of which you can always add another rack full of. So maybe it takes twice as long on the application servers to do what your stored procedure do - but you have a dozend application servers running and only one database. You really, really want to avoid the bottleneck on the database.

Re:Not everyone cares about Coding... (1)

shakah (78118) | more than 8 years ago | (#14651738)

Stored procedures are BAD BAD BAD...
So if you have an personnel database and your app/database must handle job changes, and those job changes consist roughly of:
  1. taking the person out of the current job ;
  2. adding a "job history" row for the old job ;
  3. putting the person into the new job.

Are you sincerly claiming that a stored procedure is not appropriate in this case? Excepting a pathologically poor stored procedure implementation, your "do it in the app server" approach if anything puts the same load on the DB regardless of how many app servers you have. Beyond that, the stored procedure practically guides you to a clear, clean, and maintainable implementation (along the lines of do_job_chage(emp_id, old_job_id, new_job_id)), lets you easily modify what a job change entails, etc.

Re:Not everyone cares about Coding... (1)

Doctor Faustus (127273) | more than 8 years ago | (#14652337)

Excepting a pathologically poor stored procedure implementation, your "do it in the app server" approach if anything puts the same load on the DB regardless of how many app servers you have.

For updates, the app-server approach will put *more* load on the DB, because data has to be sent to the app server, and SQL coming back from it has to be parsed.

For reads, caching the data elsewhere can be a big gain. I've gotten 75% speedups in batch jobs by preloading data at the beginning of the process.

Re:Not everyone cares about Coding... (1)

finnif (945981) | more than 8 years ago | (#14651838)

- You can't easily migrate to another database-vendor. Maybe you want to switch. Maybe you have to because of technical reasons. Maybe you have to because your company is being bought by another, which uses a different system and wants to maintain only one platform. Whatever the reason, your stored procedure is going to really, really hurt.

It just depends on where you want to do the work. If your SQL is in your app, you still need to port it. If your SQL code is in your SP, you still need to port it. I don't use SPs, but contrary to the conventional wisdom, stored procedures are not inherently evil, and some employers require them. Granted, you can avoid writing much SQL at all these days using ORM solutions, with a massive performance hit.

You want to take load off the database because it scales not as well as the application servers, of which you can always add another rack full of. .... You really, really want to avoid the bottleneck on the database.

Again, different strokes for different folks. Doing a big join on the DB or sending enormous amounts of results over a wire. Pick your poison.

Re:Not everyone cares about Coding... (4, Informative)

GebsBeard (665887) | more than 8 years ago | (#14651930)

That this gets modded insightful is an embarrassment. Every DBA worth two shakes of a dead rats ass can tell you putting stored procedures in the DB cuts down on network traffic and improves application responsiveness. Every time a query is passed across the network it has to be compiled to p-code. Multiply that by X users and the system grinds to a halt. Ease of implementation and clarity also shoot through the roof with proper use of stored procedures. And the scalability problems you speak of don't exist, since you can instance your database just like your app server.

The Slashdot hive mind may not like the idea of being tied to a particular database or vendor but in the Real World businesses choose their databases carefully and stick with them for a long time, often forever. With this in mind you exploit every single option available when programming and stored procedures along with proper filesystem layout, column indexing and schema design are key to a high performance database.

Re:Not everyone cares about Coding... (1)

Doctor Faustus (127273) | more than 8 years ago | (#14652310)

in the Real World businesses choose their databases carefully and stick with them for a long time, often forever.
There are two very different cases, which tends to lead to people talking past each other. Basically, database portability is important to software companies (who don't want to restrict themselves to selling to Oracle shops), but not to companies working on in-house systems.

Re:Not everyone cares about Coding... (1)

Da Schmiz (300867) | more than 8 years ago | (#14652528)

There are two very different cases, which tends to lead to people talking past each other. Basically, database portability is important to software companies (who don't want to restrict themselves to selling to Oracle shops), but not to companies working on in-house systems.
Mod parent up. This is perhaps the most insightful comment in this entire sub-thread. FWIW, I think these days in-house systems (which would include hosted systems with a web front end) are a larger segment of the market. Maybe embedded is bigger, but you're not going to use Oracle in an embedded environment. Well, not usually, anyway....

Re:Not everyone cares about Coding... (1)

Lumpy (12016) | more than 8 years ago | (#14652659)

In the world of 100BaseTX this is a non issue.

maybe back in the days of token ring your argument made some sense.

With a quad 3.66Ghz xeon server and fiber to the switch there is ZERO performace difference between all stored proceedures and client side queries.

I know.. I recently proved this fact to the Sr DB admin who started in the early 80's here that his ideas may have been relevant before, but are becoming moot.

Storing a date as X days cince an epoch is stupid today and only causes hell for others later. store it as a frigging date that is readable and easily dealth with. hell do it as a text if you want.

Storage space is not an issue anymore. (the epoch is now 6 digits. I can store a readable date in that same space.)

More and more people want access to the data and obfuscating it with epoch dates and other silly things to save space are far less valuable than making it easier for Mafasa in Finance to easily deal with the data in Crystal Reports himself.

Re:Not everyone cares about Coding... (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14653007)

Putting logic in the database is always bad idea for the reasons the parent post stated. Your argument for lowering network IO is nonsense in most programming languages as connected, scrollable record set only push the data over the wire when it is requested. Further the optimisation to p-code is also taken care of by good database drivers. In Java a prepared statement used with a decent JDBC driver will be fully compiled and optimised at the database level while maintaining application code portability.

Combine this with a decent object relational technology like Hibernate and you can swap database vendors by changing a single configuration file.

I work with Big Blue Chip "Real World Business" everyday and they swap databases for many reasons including the following :
  - Mergers and Aquisitions lead to two database vendors of choice, overtime the merged entity wants to move to a single vendor
  - Vendor price negotiations: if the vendor knows they can swap dbs at the drop of a hat they tend to price accordingly
  - They want to switch to a free open source database (we are seeing this more and more in govt).

I guess you are a DBA... better start looking for another job because nobody needs dbas anymore. Systems Administrators yes, DBAs no.

If Only the SQL 2003 Standard Was Followed (1)

Cruxus (657818) | more than 8 years ago | (#14652168)

Phooka.de (302970) [slashdot.org] wrote:

- You can't easily migrate to another database-vendor. Maybe you want to switch. Maybe you have to because of technical reasons. Maybe you have to because your company is being bought by another, which uses a different system and wants to maintain only one platform. Whatever the reason, your stored procedure is going to really, really hurt.

The problem is right now none of the relational database management system vendors follow a common syntax for these kinds of advanced features. The SQL 2003 standard specifies the proper syntax for stored procedures and stored functions, yet the actual implementations diverge with their own SQL dialects (Oracle's PL/SQL, Sybase and Microsoft's Transact-SQL, etc.). Not even MySQL follows the standards to the letter (for example, AUTO_INCREMENT is not the standard way to create an automatically incrementing field of data).

After taking my first database class for computer science, I was truly shocked by two things: this lack of standardization support (no doubt to encourage vendor lockin) and the sheer kludgery of SQL syntax.

Re:If Only the SQL 2003 Standard Was Followed (1)

KingMotley (944240) | more than 8 years ago | (#14652362)

Don't blame the SQL Vendors, blame the SQL Standards which are always 5-7 years behind what the database vendors actually implement featurewise.

Re:Not everyone cares about Coding... (1)

Da Schmiz (300867) | more than 8 years ago | (#14652287)

Funny how this argument always comes up....

Stored Procedures can be bad, but they also can be very good. I regard SPs as somewhat like inline assembler in C/C++ code -- it can give you *massive* performance boosts. Of course, there are times where the costs (lack of portability, requires more knowledge of relational theory, etc.) outweigh the benefits, but those are mostly for small databases. When you use 10M+ or even 1B+ row databases, doing table scans (which could take hours or even days) for a simple select join isn't going to cut it, and you are really going to need the optimizations you can get from writing the SQL yourself. And if you're going to be writing database-specific SQL, you might as well store it in the database.

Plus, big databases like Oracle compile SPs and save the execution plan so the SQL text doesn't even have to be interpreted again. Doing all your SQL dynamically to keep database independence is like saying you should write your hardware drivers in JavaScript so you can have platform independence. Plenty of things can be written in JavaScript, but not everything. Use the right tool for the job.

Finally, a properly built database will scale very nicely, thank you. People have problems with overtaxing their database servers when all they're doing are giant SELECT * FROM X queries where the database server has to schlep all the data across to the application server before you can do anything with it. Moving the data across the network costs way more than the actual join/query syntax will, especially if you happen to actually understand the relational data model...

Re:Not everyone cares about Coding... (1)

jadavis (473492) | more than 8 years ago | (#14652345)

Stored procedures are BAD BAD BAD

Do you realize what other features you give up when you give up stored procedures/functions?

-user-defined aggregates
-user-defined types
-functional indexes on user-defined functions
-set-returning functions

Sometimes you need these things for reasonable efficiency. Especially functional indexes! And user-defined types are an important part of the relational model.

Re:Not everyone cares about Coding... (1)

KingMotley (944240) | more than 8 years ago | (#14652499)

Stored procedures are BAD BAD BAD, I'm glad you have a hard time promoting those. Why? You can't easily migrate to another database-vendor. Maybe you want to switch. Maybe you have to because of technical reasons. Maybe you have to because your company is being bought by another, which uses a different system and wants to maintain only one platform. Whatever the reason, your stored procedure is going to really, really hurt.
Heh, I'd have to completely disagree there. By using stored procedures exclusively in an application, you abstract the database inconsistancies from the application. If you want to replace the database (or run on multiple databases), then just call the new database's stored procedures passing the same parameters that you always have. It shouldn't require a change to the application, plus you get reduced network traffic, increased responsiveness, and decrease the load on the database.

Re:Not everyone cares about Coding... (1)

ocbwilg (259828) | more than 8 years ago | (#14651977)

It may surprise you but most people who use open source applications do not change the code. Even the ones who know how too, don't. Why, because they don't have the time. They download it try it, if it does what they need they use it, if not then they try an other product, if they cannot find an Open Source tool that does the job then they see if there is a commercial one that does.

Absolutely. I'm a perfect example. Where I work we needed a new helpdesk system. Our original solution was built by one of our devs in his spare time on MS-Access. It worked fine, but we wanted something a little more scalable, that had a web front-end, and automatically processed emails from users. When I started evaluating applications I started with OSS first, and ended up going with RT on MySQL before I even talked to commercial vendors. Now we have a solution that does everything that we need (now), and I've saved thousands of dollars. If we want to eventually modify the code we can do so, but since none of us know perl it's not very likely that will happen.

I personally love OSS precisely because it is usually free (beer). Now if we could just get our software vendors to start transitioning to supporting open source databases, I might be able to get rid of the 3 Oracle and 3 MS SQL servers that I have.

Uh, yeah... (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14651318)

Disclaimer: that quote came from Sony.

See, this is why I rarely get my submissions accepted -- I have too much dignity to throw in a moronic closing line like that one. By the way, you idiots continue to not have the slightest idea what "innovate" really means...

Other open source databases. (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14651321)

Call me when either MySQL or PostgreSQL support .OGG files. Until then I will be using iOracle.

Can't hear you... la-la-la (5, Interesting)

Billosaur (927319) | more than 8 years ago | (#14651337)

The wild card in all of this will be whether big, successful tech companies get behind the upstarts. Linux hit prime time only when IBM, Oracle, and others got behind it, rewriting their software to make it compatible and convincing worried CIOs that it was robust and reliable enough to entrust their business to it.

A company such as SAP (SAP) could be pivotal. The German software giant is locked in an applications war with Oracle, but the bulk of companies running SAP applications run them on Oracle databases. So even when SAP wins an application deal, it's often making money for its archrival. That doesn't sit well with ultracompetitive SAP, which already has a burgeoning partnership with MySQL. Closer ties there could mean more SAP applications on MySQL databases. Elsewhere, Red Hat (RHAT) has endorsed both MySQL and Postgres, as did Sun Microsystems (SUNW) last November.

So Oracle has now become Microsoft, pretty much resting on its laurels and claiming that its users are more than happy with them, while all-the-while, their users are shopping for cheaper and better solutions. If SAP were to out-and-out declare they like MySQL better and shift most of their DB usage there, Oracle would have a very large amount of egg on their face.

Let's face it: when you become the dominant leader of your industry, you tend to forget what got you there and you take it for granted you will always be there. I've used Oracle, MySQL, and Sybase, and I find the latter two to be a lot easier to work with than Oracle. Oracle is trading solid dependability for tricks and gimmicks, and in the end, no one wants to pay that kind of money for things they don't need or won't use.

Re:Can't hear you... la-la-la (2, Insightful)

C_Kode (102755) | more than 8 years ago | (#14651741)

and in the end, no one wants to pay that kind of money for things they don't need or won't use.

Exactly. If you don't *need* Oracle, don't use it. On the other hand; If your database is the life blood of your business and downtime can cost your business it's life. You would be a fool not to use it.

Oracle is what it is and you pay for what it is. I use a mix of many different databases, but our most critical and complexed applications run Oracle. Why? Because the only way you will lose data in a Oracle database is if you shouldn't be managing an Oracle database.

Open Source + the Database Vendors (3, Interesting)

Doc Ruby (173196) | more than 8 years ago | (#14651352)

I'd love to develop my apps with Postgres, then deploy to Oracle or DB2 with an automated tool. If Oracle or IBM distributed a free (beer) one, I'd include it in my project plans. And if there were an open source tool for comparing performance of my app on each of those databases in real tests, I'd be more likely to make the switch - provided the tests showed an advantage.

Re:Open Source + the Database Vendors (4, Informative)

LurkerXXX (667952) | more than 8 years ago | (#14651457)

You ARE joking, right? Oracle is free to use for development, just not production. If you really use Oracle, you should already know this.

Re:Open Source + the Database Vendors (1)

Doc Ruby (173196) | more than 8 years ago | (#14651883)

You ARE reading my post, right? Oracle is not open source, which is more important when I'm developing an app than just no price. And the free (beer) migration tool needs no price more than open source, because using it might result in my not using Oracle, depending on the results. The testing tool needs open source more than no price, because I need to see whether the tests are rigged to favor Oracle.

If you really read the posts, and really develop apps, you should already know this. If you just want to flame on Slashdot, I guess you're free to do that regardless.

Re:Open Source + the Database Vendors (1)

LurkerXXX (667952) | more than 8 years ago | (#14652325)

"I'd love to develop my apps with Postgres, then deploy to Oracle or DB2 with an automated tool. "

Why is it important to that the DB be OSS for you to develop your app if, as you said, you are going to migrate it to Oracle or DB2?

Both Oracle and DB2 provide migration tools to themselves from Sybase, MS SQL, Informix, MySQL, as well as each other.

If your real goal is to deploy to Oracle or DB2, it seems it would make more sense to start with a DB that both have easy migration paths from. Starting with either Oracle (which has a fee development version) DB2 (which IBM has a free version of), MS SQL (which MS has a free version of) or MySQL (worst option IMHO DB wise, but hey, it's OSS).

Re:Open Source + the Database Vendors (0)

Anonymous Coward | more than 8 years ago | (#14651714)

IBM does have the free DB2 offering: http://www-306.ibm.com/software/data/db2/udb/db2ex press/download.html [ibm.com]

Re:Open Source + the Database Vendors (1)

Doc Ruby (173196) | more than 8 years ago | (#14651948)

I'm not asking for a free (beer or speech) DB2, though that's got its own merits. I'm asking for a free (beer) migration tool, and an open source testing tool to reduce my risks when considering deploying to a commercial database.

Re:Open Source + the Database Vendors (1)

ocbwilg (259828) | more than 8 years ago | (#14652027)

I'm not asking for a free (beer or speech) DB2, though that's got its own merits. I'm asking for a free (beer) migration tool, and an open source testing tool to reduce my risks when considering deploying to a commercial database.

I think that the reason you got the responses that you did were simply because most people are of the opinion that you should develop for the target platform on the target platform. Not only is it easier, it saves steps, and it makes sense.

Re:Open Source + the Database Vendors (1)

Doc Ruby (173196) | more than 8 years ago | (#14652239)

Except that the commercial target platforms have closed source. Open source's best advantage is for developers. Even if only the query client source is open, leaving the DB server source closed, that's a big advantage. Postgres source is open, so it's a big help for developers.

Open source also helps decide which platform to develop on. Practically all commercial databases trade efficiencies for completeness - bloatware. Open source allows developers to trim bloat while retaining required features.

So I can develop on generic Postgres, then decide whether to deploy to a stripped Postgres, Oracle, DB2, or other. In order to do so, I need to strip Postgres (or use others' stripped versions), migrate to the other candidates, and test the resulting platform. To do that, I need the Postgres source, which I've got, a migration tool, which I'd rather not pay for if its results don't bear fruit, and a testing tool, with open source I can inspect for rigged results.

Most people don't do anything like that. And most applications are low quality. My techniques produce high quality apps. I want the process to be easier, not only for me, but for others - so everyone can produce that quality.

Re:Open Source + the Database Vendors (2, Informative)

obnoxio (160712) | more than 8 years ago | (#14651755)

Re:Open Source + the Database Vendors (1)

Doc Ruby (173196) | more than 8 years ago | (#14652360)

Now, how about the free (beer) migration tool I asked for, and/or the open source testing tool that is all that I asked for?

I'll also gratefully accept sacks of $50 bills, but I didn't ask for that, either.

Re:Open Source + the Database Vendors (1)

luiss (217284) | more than 8 years ago | (#14652142)

DB2 Express-C [ibm.com] is free (as in beer).

Re:Open Source + the Database Vendors (1)

ducttapekz (879839) | more than 8 years ago | (#14652799)

I haven't seen anyone mention one thing yet: Oracle XE. [oracle.com]

This is a free database with most of Oracle's enterprise functionality. It will hold giant amounts of data, it has full XML support, and it will run on a developer's machine if needed.

Hands on source code (5, Insightful)

five18pm (763804) | more than 8 years ago | (#14651378)

From the article: They would happily trade some to get their hands on the source code and a better deal.

How many are there who would actually look at the source code of a database, work on it rather than develop new applications based on it? If database A works, then they are going to stick with database A until conditions change drastically. It hasn't happened now and doesn't seem like it will happen in the near future.

Re:Hands on source code (3, Interesting)

slim (1652) | more than 8 years ago | (#14651533)

From the article: "They would happily trade some to get their hands on the source code and a better deal."

How many are there who would actually look at the source code of a database, work on it rather than develop new applications based on it?


Let me rephrase the excerpt from the article:
"Some users would happy forego certain features present in commercial databases if (1) it means reduced cost and (2) you access to the source code."

Why stick with expensive Oracle or DB2 if PostgreSQL does the job reliably enough and it's free? That's a no brainer.

I think you're asking, "why even look at the code if it's working?". Absolutely right. If it ain't broke, don't fix it.

But, if there's a feature missing that you require, then for certain businesses -- not all -- it may well make sense to add code yourself. A tech company may underutilised coders on the payroll: it may be cheaper to get them to code and support that feature than it is to sack them.

A large corporation (Sony, 3M, etc.) might need to deploy that feature in hundreds of places. Paying someone to code it gives them a lot of bang for the buck.


If database A works, then they are going to stick with database A until conditions change drastically. It hasn't happened now and doesn't seem like it will happen in the near future.


Successful businesses always look to reduce costs. If database A works, database B is $10,000 per year cheaper to license and support, the migration will cost $20,000 and you expect to continue using the system for over 2 years, then (cashflow allowing) it's a no-brainer to move. The only thing stopping you would be lack of business agility.

Re:Hands on source code (1)

Zerbs (898056) | more than 8 years ago | (#14651565)

yes, that's exactly right. The truth is, while an open source C compiler may appeal to C programmers because it's written in C, the people who administer, design, and implement database solutions have more important things to do than look at C source code of their database. A number of them only have enough C like knowledge to do shell scripting in Unix/Linux.

Re:Hands on source code (1)

DrSkwid (118965) | more than 8 years ago | (#14651737)

Something I have found important is that there are some who would actually look at the source code of a database, work on it rather than develop new applications based on it.

Well (2, Insightful)

Toreo asesino (951231) | more than 8 years ago | (#14651452)

I think most businesses crave accountability & reliability more than anything.

I'd be more comfortable running a system running a vendor dbms rather than an Open Source implementation - just because when shit hits the fan (which it invariably does), at least there's ultimately someone responsible for it.

Don't get me wrong; we run mySql for all small-midsize operations, but the bigger systems run Oracle purely because of this reason.

Re:Well (2, Insightful)

slim (1652) | more than 8 years ago | (#14651674)

I'd be more comfortable running a system running a vendor dbms rather than an Open Source implementation - just because when shit hits the fan (which it invariably does), at least there's ultimately someone responsible for it.

But MySQL is a vendor DBMS if you want it to be. You can buy the product and support from MySQL.com [mysql.com] .

However, even if we invent a hypothetical Open Source product where paid support isn't available, there are circumstances where I get really fed up of the "we can't use that, what if it breaks" attitude.

I've just moved from horrifically risk averse backwater within a Fortune 500 corporation, to an environment where maybe just once in a while you can say "No, you don't need paid support for that piece of Open Source software: if it breaks we have the expertise and resource to fix it within 24 hours".

Sometimes that's not enough -- sometimes you're risking tens of thousands of dollars and you want insurance against that. Sometimes, though, it *is* enough, and it's right to stop and make that decision.

Re:Well (1)

Toreo asesino (951231) | more than 8 years ago | (#14651779)

Fair enough. It's all about what you feel comfortable with. There's a lot of justification in using an open-source dbms of course, but there's also a point where I wouldn't want to push my luck. The point is, if my system breaks because of thier screw-up, I'll want to know heads will roll higher up than R&D. It's the execs which ultimately suffer for screw-ups in paid software rather than geeks.

Re:Well (1)

slim (1652) | more than 8 years ago | (#14651957)

The point is, if my system breaks because of thier screw-up, I'll want to know heads will roll higher up than R&D.

We're agreeing with each other :)

The key to this is to make an explicit and documented risk assessment, document acceptable downtimes and all that tedious project manager-y type stuff.

That way, if you specify an Open Source component, it breaks, there is downtime but you fix it, you can point at the documentation you produced.

"We documented that there was a small probability that an undiscovered flaw in this component could cause disruption, that the impact would be this, and that we would expect to fix it within n hours. You signed it off and accepted those risks."

Making money is all about evaluating and accepting risks. Of *course* your management may read your risk assessment and decide they'd prefer to mitigate the risk with a commercial support contract. It's all part of the balancing act.

Re:Well (1)

Toreo asesino (951231) | more than 8 years ago | (#14652109)

I guess we are more or less. I think I can sum it up with a conversation I had with a director once... him: What back-end are we using for this [insert big system-name here]? me: Well, there's two which spring to mind - Oracle or mySql him: Oracle - i've heard of them! Who makes the other one? me: Well, it's open-source, but it's supported by the MySql company.... him: [blank look] me: It's much cheaper! him: Do I give a shit? I see the Oracle building every day going to work! They must be good! And with that, we 'chose' Oracle.

Re:Well (1)

psycho8me (711330) | more than 8 years ago | (#14651688)

I believe that mysql sells support.

Short Term Gain Is KING! (4, Insightful)

Saeed al-Sahaf (665390) | more than 8 years ago | (#14651525)

which focused on how businesses are looking to save money with open source (rather than using the source to innovate)

This is a surprise? Maybe "back in the day" innovation was a significant part of the average business plan in the United States, but those days are long gone in today's business world where short-term financial gain is the only objective. Realistically, the only innovation going on today it that which is related to military use. Sad, really.

Re:Short Term Gain Is KING! (1)

jadavis (473492) | more than 8 years ago | (#14652482)

It sure doesn't seem that way to me. It seems to me like the pace of technological innovation is increasing and reaching consumers faster. You can probably find a few examples of mismanaged companies, but many companies still have huge research budgets and bring that new technology to consumers very quickly.

Think about how quickly multi-core processors are making it into the market. Is that because of short-term thinking? What about a company like IBM putting billions into Linux development, is that short-term thinking? What about the billions invested by drug companies to create better medications, that allow AIDS and cancer patients to live much longer than before?

But who will my boss shout at? (2, Funny)

Malnathor (588724) | more than 8 years ago | (#14651616)

If we use an open source app my boss will have no one to call up and shout at when things go wrong. Thus, any suggestion to use an open source DB will be pissed on.

SAP (2, Funny)

stephenMF (547151) | more than 8 years ago | (#14651807)

At my company we are making a move to MySQL in order to accomplish what SAP cannot do for our assembly lines. This involves keeping track of incoming and outgoing material. SAP will still keep track of what happens with the finished goods, and received parts. Why we keep SAP probably has something to do with the corporate jacuzzi.

That's not why Google uses Mysql (0)

Anonymous Coward | more than 8 years ago | (#14652272)

I recently blogged about a talk given by Greg Stein (a googler) where he briefly discussed why they use mysql [blog-city.com]

MySQL at $40 million per year. And that's fine. (4, Informative)

Animats (122034) | more than 8 years ago | (#14652567)

So MySQL generates only $40 million in revenue per year. That's OK. That's enough for perhaps 400 people. How many programmers do you really want working on a database? Beyond 50 or so, they'll probably add more bugs than they fix. And they'll be tempted to put stuff in the database that shouldn't be there.

Of course, this is a problem for Oracle. Building Larry Ellison's house cost far more than MySQL generates in profit. I drive by the place all the time. Under construction, it looked like a mall. Oracle stock dropped from $50 to $12 while the house project was underway.

It's all about the DBA (1)

setrops (101212) | more than 8 years ago | (#14652712)

We use MySQL, Postgres, SQL Server, Oracle and DB2.

Out of all of these product, the best DBA we have is an Oracle guy. He really knows his stuff. It is the smoothest and easiest to program for because he can answer the questions we ask. He's also a really good programmer, so he can debug the stupid mistake done by the contractors(Ok, I might have made some dumbass stuff myself).

If I had my choice, I'd use Oracle everywhere and promote him to manage it all. He has shown me that no matter what you use, it;s only as good as the support you get from your DBA.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?