×

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 Database Underdogs

Hemos posted more than 12 years ago | from the all-the-news-that's-fit-to-print dept.

Programming 154

implex writes "Interactive Week had an article called "Data Underdogs" which they compare offerings of present Open Source Databases with present commercial offerings. In one part they mention ...On the other hand, MySQL developers now have a much-needed transaction management system: NuSphere last month made its Gemini transaction manager for MySQL available as open source code on mySQL.org, a site that the company recently launched. Complicating matters, though, is NuSphere's blood feud with MySQL AB, a Swedish company that runs a competing open source development site for MySQL code at www.mysql.com. No mention of the fact that MySQL AB actually created the product was interesting."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

154 comments

Open Source Databases (5, Interesting)

standards (461431) | more than 12 years ago | (#2114475)

Instead of focusing in on the available solutions, the article simply spits out the idea that MySQL and Postgres are weak pretenders.

The FACT is that these databases are excellent solutions to a large number for MOST database problems. Sure, like all DBMSs, they can always use more features. But I don't want my DBMS to turn into an uncontrolled monster like Oracle.

For 99% of the applications out there, Postgres and mySQL fits the bill. If you're doing large scale distributed payroll using SAP, then I suggest you go with a big name...

But if you're an average-sized business, Postgres is a full-featured solution today. It is an inexpensive, fully-capable solution.

If you're into writing Oracle PL/SQL, a proprietary procedural extention to SQL, go with Oracle. (Note: PL/SQL doesn't work with Sybase or DB2 or anything else.) If you're into TransactSQL, another proprietary SQL extension, go with Sybase. Once you get into TransactSQL, you'll NEVER migrate out without expense. In fact, my shop, an Oracle shop, doesn't PERMIT developers to use the PL/SQL ewxtensions. We learned our lesson after migrating from proprietary MS-SQL-Server extensions to Oracle!

And if you need a big company to support your 20,000 person payroll, go with IBM's DB2. Again, another fine DBMS.

But for the average shop? Save your money and go with PostgreSQL.

Re:Open Source Databases (2, Informative)

evolspit (202035) | more than 12 years ago | (#2118926)

>If you're into writing Oracle PL/SQL, a proprietary procedural extention to SQL, go with Oracle.

Don't forget about PL/pgSQL [postgresql.org], the procedural language for Postgres. This was written with Oracle converts in mind ;)

Develop with PostgreSQL; deploy with whatever (3, Informative)

brlewis (214632) | more than 12 years ago | (#2133879)

One problem with proprietary DBs is that their docs will steer you toward non-standard SQL even when standard SQL will work. For example, Oracle will teach you to use NVL and Sybase will teach ISNULL, when COALESCE works in both databases.

The solution is to develop with PostgreSQL regardless of what your deployment DB will be. Their docs favor standard SQL. The code you develop will work with the proprietary DBs as well.

Re:Develop with PostgreSQL; deploy with whatever (1)

FatHogByTheAss (257292) | more than 12 years ago | (#2119391)

+++The solution is to develop with PostgreSQL regardless of what your deployment DB will be. Their docs favor standard SQL. The code you develop will work with the proprietary DBs as well.+++ Baloney. Their docs specificaly state they aren't SQL-92 compliant, and they don't try to be. Go ahead and create a cursor with updatable columns in Postgres, then come back and blabber on about "standard SQL."

[people who actually read my post, skip this] (2)

brlewis (214632) | more than 12 years ago | (#2113773)

If you actually read my post, you'll notice that I never claim that they implement all of SQL-92. I won't bother restating myself as the original post was quite clear.

P.S. Cursors with updatable columns did not actually work in MSFT SQL 6 until some time long after the marketing literature claimed they did. With PostgreSQL, you can expect more accuracy as to what is/isn't implemented.

Re:Open Source Databases (2)

duffbeer703 (177751) | more than 12 years ago | (#2145308)

If your company refuses to allow PL/SQL procedures, most people would question your technical competence.

What are you using for stored procedures? Java, C?

Databases are not black-boxes, and if they are treated as such, whatever applications come out of it will not be optimal and will never be scalable.

Code forks... (4, Insightful)

UncleOzzy (158525) | more than 12 years ago | (#2114890)

What's the problem here? We've got and open source database that's being developed in two somewhat different directions by NuSphere and MySQL AB ... seems like in the end it'll lead to two different, but each (for their intended applications) excellent products. I just don't see a problem.

Maybe I'm just being dense (first reply: "Yes, you're fscking dense!")

Re:Code forks... (0, Flamebait)

SamBeckett (96685) | more than 12 years ago | (#2112281)

What's the problem here? We've got and open source database that's being developed in two somewhat different directions by NuSphere and MySQL AB ... seems like in the end it'll lead to two different, but each (for their intended applications) excellent products. I just don't see a problem.

Maybe I'm just being dense (first reply: "Yes, you're fscking dense!")

Yes, you're fucking dense.

Re:Code forks... (0)

Anonymous Coward | more than 12 years ago | (#2133010)

The only problem is the hypocrisy of the open source and free software movements. Everybodies Free except some are more free than others.

Re:Code forks... (2, Insightful)

dup_account (469516) | more than 12 years ago | (#2144510)

We all know that (needless) forking is really bad on a project. It makes more sense to have the base MySQL, and NuSphere stuff be add-ons/patches. At least until every gets together on what's going on.<p>
I think that NuSphere tried (is still trying) to muscle in on MySQL and become THE MySQL company. I sort of see it like the Sybase/M$ thing. For a long time M$ just resold Sybase stuff. Then they decided they didn't need Sybase anymore so they dumped them and put their marketing behind M$ SQL Server. No hardly anyone reconizes that Sybase wrote the core of M$ SQL Server......<p>
I think we all need to support MySQL AB as the original authors of MySQL. The people who risked their butts to bring it to us. I also think we should all tell NuSphere that they should be grateful to MySQL AB and learn to play nicely. (Unless they want to be view in the same negative light as M$)

Open source vs. Commercial DBMS's (1)

mystery_bowler (472698) | more than 12 years ago | (#2118880)

It's been my experience that the only thing really holding the major open-source DBMSs back were exposure and solid transaction management. I hope that, by now at least, many DBAs have at least heard that there are alternatives to Oracle and SQL Server. As a programmer and database designer, I know I've been trying to keep my co-workers' and employer's eyes open to the possibility of having to use an open-source DBMS when the need arises.

It seems to me that implementing MySQL doesn't seem any more difficult that getting an Oracle database built. Although, I must say I've gotten spoiled by the GUI that's available in Microsoft's SQL Server Enterprise Manager. It's damned nice.

I guess the long and short of it is that it's good to have an alternative to Oracle, which is, in my opinion, overpriced for what it is. As long as products like MySQL keep getting better, they'll continue gaining ground as not just "alternatives" to pricey DBMSs, they'll become the DBMSs of choice.

Re:Open source vs. Commercial DBMS's (2, Informative)

Palshife (60519) | more than 12 years ago | (#2139343)

I must say I've gotten spoiled by the GUI that's available in Microsoft's SQL Server Enterprise Manager. It's damned nice.

I assume you've heard of/used phpmyAdmin [sourceforge.net], a PHP web application that reminds me alot of the interface to MSSQL Enterprise manager (though not as full featured, I'll admit). Anyway, it's something to check out if you're interested. Saves alot of time on testing and prototyping.

ttam

growing trend.. (4, Insightful)

TechnoVooDooDaddy (470187) | more than 12 years ago | (#2118927)

Actually, I've noticed a growing trend in the crowd of programmers I run with is not to care about the implementation platform.. SQL is SQL, and you don't do transactional based stuff on the platform anymore, you abstract away from that into your middleware, and do things the way you want to. In REAL LIFE programming, you often don't have the chance or opportunity to spec out what your back-end platforms are, you have to deal with what's given, or what's legacy at Company XYZ Inc. You also are often dictated a programming langauge for the project whether it be java, c, cobol, perl, python or whatever. The real value lies in being able to adjust to whatever the PROJECT calls for, and being able to implement on just about any platform you need with strong good design patterns. MySQL and Oracle both do exactly the same thing from my point of view, hold data in a relational format for storage and quick retrieval. Putting too much logic into the database only serves to slow things down in the long run. Nasa Switches from Oracle to MySQL [mysql.com] shows us why Oracle putting all those bells and whistles in their product may lead to a weakening of their marketshare ultimately. The fact is, bells and whistles cost memory and processor, and there's a balance between the two that Oracle seems to be blithly ignoring.

Re:growing trend.. (3, Funny)

popeydotcom (114724) | more than 12 years ago | (#2140930)

It's the RMC (Right Mouse Click) crowd. With MSSQL came RMC - backup, RMC - add data file, RMC - almost anything.

Anyone can become a DBA, just like anyone with IIS can become a webmaster.. *cough*

Re:growing trend.. (2)

guinsu (198732) | more than 12 years ago | (#2147231)

Its funny how Linux people want the internet and computers to become the great euqalizer. But if its a Microsoft product that does that, all of a sudden its bad.

Re:growing trend.. (5, Insightful)

duffbeer703 (177751) | more than 12 years ago | (#2144603)

SQL is not SQL

There are four tiers to the SQL-92 standard, and even commercial RDBMS vendors to not conform to all of them.

Oracle, Informix, DB2, MySQL all have different optimizers and differing concurrency schemes. Oracle does not lock a row for reading when another transaction is writing a row. Informix will perform table scans on certain queries where DB2 will not.

This "growing trend" you are talking about must be coming from inexperienced programmers working on trivial or single-user applications. In REAL-LIFE the security of data and usability of the client are paramount.

The fact that you would even say that MySQL and Oracle do the same thing displays your complete lack of knowledge regarding what modern commercial database products are capable of. Leaving all the programming logic in the hands of applications developers re-invents the wheel, escalating costs while introducing more bugs into the system.

Abstracting away transactions?? (3, Insightful)

TurkishGeek (61318) | more than 12 years ago | (#2157008)

I don't think you can "abstract away transaction related stuff" from the RDBMS. Please correct me if I'm wrong; but I believe that you simply can not start with a RDBMS that does not support transactions; and slap a transaction processing middleware on top of it to instantly have a database application with transactions.

The standard transactional interfaces that are increasingly becoming popular nowadays (like JTA) depend on the database supporting transactions; most likely in the form of an XA-conformant programming interface.

OS DB 3% - can that really be? (3, Interesting)

Kraft (253059) | more than 12 years ago | (#2124838)


But mirroring the success of Apache and Linux will be no small feat for the three most popular open source databases - InterBase, MySQL and PostgreSQL - which combined represent less than 3 percent of the market, according to even the most optimistic estimates of the suppliers themselves.

Did this number strike anyone else as too low? This is the first time I have seen any percentages on OS DBs. Alright, 3%, but of what? Does this mean that less than 3% of all bytes stored in any database are stored in an OS DB? That may be, but I cannot believe that less than 3% of all databases running are OS.

The thing is, when I started studying computer science, we only ever worked on mSQL boxes. My first job used Postgres and the second used mySQL. Anything I work on myself is mySQL. Granted these jobs have all been webrelated, but when you think about how many ISPs offer mySQL/Postgres preinstalled (not to mention linux distributions, if that counts), 3% seems rediculous.

Well I suppose MS Access runs on one or two computers out there... that might raise the non-OS score.

Re:OS DB 3% - can that really be? (3, Insightful)

mikera (98932) | more than 12 years ago | (#2111602)

Well, when people talk about market share it is usually by revenue, and given the low price of Open Source databases I'm actually surprised it's even as high as 3%.

But 3% of revenue might actually add up to a fairly substantial proportion of installations.

Re:OS DB 3% - can that really be? (2)

Kraft (253059) | more than 12 years ago | (#2146790)

Doh. and thanx. This never even occured to me... measuring the success of OSS (ie. free) in terms of revenue seems a bit too weird :)

Re:OS DB 3% - can that really be? (1)

mrbnsn (24209) | more than 12 years ago | (#2132692)

"Market" is a word that refers to a place where things are bought and sold.

When a product has 3% of a market that means that 3% of the total amount of money exchanged for that category of product is given in exchange for the product in question.

Now, you may argue, with considerable justification, that market share is a meaningless metric of open-source software acceptance, but for the mass of humanity that isn't still living with their parents, markets are what put food on the table.

Re:OS DB 3% - can that really be? (2)

mgkimsal2 (200677) | more than 12 years ago | (#2145090)

Think of how many VB-based desktop apps are out there - figure that probably 70-80% of them bundle some form of the Jet engine, and/or use Access locally. That's been spreading for *years* and if you count that, 3% of the market for MySQL, PostgreSQL and others doesn't sound too far out. Of 'web-related' databases, I'd figure MySQL and PostgreSQL are probably a lot higher - certainly in the double digits.

Great Articles on Drugs -- Thanks. (1)

Futurepower(tm) (228467) | more than 12 years ago | (#2157236)


COMPLETELY off-topic, but thanks for the link to the articles on drugs. (See the web address given by Kraft, above.)

We have the drug laws we do, I think, largely because there are members of our society who want to have gun battles. Most of our drug prevention laws don't prevent.

Re:Great Articles on Drugs -- Thanks. (2)

Kraft (253059) | more than 12 years ago | (#2138193)

Thanx for pointing it out. You know that it is a whole feature they did... AFAIR if you click "next" on the bottom of the page, you will go through all the articles they wrote on the topic. I tried submitting this to /. but no luck.

If anyone else feels like submitting it, then please go for it.

Creating dynamic Web sites with PHP and MySQL (1, Interesting)

Anonymous Coward | more than 12 years ago | (#2125105)

Take a look at this [ibm.com] if you want to see php and MySQL working together. It shows you how to use two open source, cross-platform tools for creating a dynamic Web site.

Focus on profits (2, Interesting)

telbij (465356) | more than 12 years ago | (#2135976)

The article seems to claim OSS DBMSs aren't as succesful as commercial solutions. Unfortunately, it follows the typical capitalist ideal that something has to make money to be succesful.

OSS flies in the face of American ideologies, and this is just another example of big corporations not seeing the value.

Certainly Oracle is much more robust than MySQL right now, but I think the OSS ideology of trying to make the best product will eventually beat out the ideology of trying to squeeze as much money as possible. Technology will prove to be the end of traditional free-market theory, I think, because there is no longer a solid commodity with value. Things can be copied, so value has to be placed on the creators, not the product.

One thing the article didn't mention . . . (5, Insightful)

micromoog (206608) | more than 12 years ago | (#2139298)

The article mentions that the extreme complexity of database management systems is a barrier, which is true. There is one other thing the commercial vendors have that is a big challenge for the "underdog" OSS vendors: trust.

Companies keep everything on database systems. Hundreds of geek-hours must go into the design of a database application for a company. Whatever system a company chooses, they must be reasonably sure the system will:

  • almost never fail
  • be supported by a stable company and
  • integrate well with other systems, into the future.
A smaller price tag may be a good start to target smaller companies that don't rely heavily on database applications, but the reason Oracle can charge $15k/CPU for 9i Standard: the reputation is worth it.

Re:One thing the article didn't mention . . . (3, Interesting)

Jason Earl (1894) | more than 12 years ago | (#2116460)

One of the things that I like best about PostgreSQL is the fact that the developers are brutally honest about the software. The core PostgreSQL developers have always been quite frank about which parts of PostgreSQL were ready for production, and which parts were kludges, or were largely untested. The problem with commercial databases, even good ones like Oracle, is that the people who know where the rough edges are aren't talking about them. That sort of honesty goes a long way towards building my trust.

PostgreSQL has an amazing featureset, especially considering its price. I think that fairly soon Oracle is going to wake up to the fact that the database is becoming a commodity market, and quite frankly, they aren't likely to be competively priced.

Re:One thing the article didn't mention . . . (4, Insightful)

rakjr (18074) | more than 12 years ago | (#2157462)

"extreme complexity of database management systems is a barrier," this can be taken two ways:

It takes an 8 ton gorilla of a database system to get the job done.

It takes alot to manage an 8 ton gorilla of a database system.

I believe the first may be true depending upon the needs, but the second is a given. What has not been stated is that the more complex the database system is, the more likely there will be errors on the part of those implementing the system if they are not fully trained. In some ways, the difference is similiar to the difference between operating a truck verses operating a jet plane. Both are designed to get stuff from one place to another, but the number of controls on a jet plane and the amount of data being produced by various meters is considerable.

People really need to weigh two parts of the issue.

Does our task require a jet or will a truck suffice?

Are we willing to pay for proven jet pilots, or is it safer to pay for an equal number of proven truckers. The key point here being "proven."

To often I am seeing agencies who buy into the idea that the only "real" solution is the jet. This is a humorous thing to see when the jet is only used for trips across town...

Re:One thing the article didn't mention . . . (2)

Hard_Code (49548) | more than 12 years ago | (#2138892)

The obvious solution is to buy the jet and then hire taxi cab drivers to fly it. Duh.

Re:One thing the article didn't mention . . . (3, Interesting)

Jason Earl (1894) | more than 12 years ago | (#2142760)

My old boss had a saying:

You only need an aircraft carrier if you are landing fighter planes at sea. If you are just going fishing, a rowboat is fine.

Oracle is nice, but it is completely overkill for most projects. PostgreSQL has many of the same features, including all of the referential integrity features that make Oracle so nice to develop for, and it comes with a fishing boat price.

Oracle experience (4, Informative)

truthsearch (249536) | more than 12 years ago | (#2139454)

I only have experience (but lots of it) with Oracle and - unfortunately - SQL Server. Until SQL Server 6.5, I think it sucked compared to Oracle. But now they're more on level, although Oracle has always, and still does, handle huge data warehouses much better.

That aside, I worked for years with a 4TB data warehouse for a major credit card company. It was Oracle (7?) on a Sun E10000 (22 processors, 1GB ram) and it was screaming. We barely used any "advanced" features that were unique to Oracle. But what impressed me was Oracle's support. They had an office a few miles away and would send DBAs over to help out. Our DBAs were excellent, but when it came to very low-level tweaking, these Oracle DBAs knew their stuff. They would mess around with the OS to keep it as efficient as possible. And if there was ever any kind of failure or error, they came over to check it out.

Now granted, my company paid big bucks for the support, but at the moment that sort of support can't be found for an open source dbms. These were highly skilled experts in the database they supported. I realize (partly from the article) that the current goal of open source databases is to grow in the low-end market - smaller systems and such - and I'd bet they'd stand up to large warehouses. But one big advantage Oracle and DB2, and to a much lesser extend SQL Server, have is their support. You can have a highly skilled technician in your office very quickly if you need it, beyond the support of a consultant could provide. I'd like to see that kind of support in open-source companies. That's when I think they'll give closed-source databases a true run for their money... literally.

Re:Oracle experience (2)

whjwhj (243426) | more than 12 years ago | (#2113465)

This is no doubt why Red Hat is getting into the DB game: So they can sell support for PostgreSQL.

I worked in a smallish Sybase shop for a while (tiny I suppose in comparison to a major credit card company) and I remember our DBA running around tweaking this and tweaking that to get the DB to run more efficiently. What struck me is that we had maybe 6 or 7 logical DB's all on one machine with no single table exceeding a million rows -- and he spends all day tweaking? Why didn't the damn thing just sit there and run? Why the need for all the tweaks? Sybase exposed so much configuration detail that even a competent DBA is bound to shoot themselves in the foot once in a while. Seems to me a decent DB system should hide and deal with as much complexity on it's own as possible.

Re:Oracle experience (2)

truthsearch (249536) | more than 12 years ago | (#2135862)

Why the need for all the tweaks?

Job security.

Seems to me a decent DB system should hide and deal with as much complexity on it's own as possible.

From the software developer's perspective, I agree. From an admin perspective, the more customizations available, the better - just like in an OS.

Re:Oracle experience (3, Informative)

duffbeer703 (177751) | more than 12 years ago | (#2136645)

Your DBA was running around tweaking all day because he was supporting a poorly designed application that was completely unoptimized.

Because so many developers have a notion (prominently displayed in this story) that "SQL is SQL" many apps running on a database run horribly inefficient queries that bog the database down.

Studies have consistently found that80-90% of database tuning needs to take place in the application. The database tuning portion mainly consists of tweaking memory and parallel query options.

Re:Oracle experience (0)

Anonymous Coward | more than 12 years ago | (#2156991)

Only 1GB of RAM for 22 processors and a 4TB data warehouse?!?!?! Sun RAM may be expensive, but for fuck's sake...all that $$$ on a 22 CPU E10000 and probably not enough RAM to buffer a single entire index...

MySQLs day will come (1)

popeydotcom (114724) | more than 12 years ago | (#2140301)

Two things.

A lot of commercial apps have plugins for whatever DB you want to use. Once they wise up and provide plugins for DBs like RedHat DB, Postgres, MySQL and so on, we'll start to see higher market saturation.

The second thing which will help is when we get more commercial apps ported to Linux.

This is already happening. The product I use every day - SAP [sap.com] is available (commercially) for Linux. They support all the big DB vendors including Oracle, MSSQL (ok, not on Linux), Informix, DB2, and their own (open source) database SAPDB [sapdb.org].
I'm doing my bit, my site runs on PHP/MySQL.

Re:MySQLs day will come (0)

Anonymous Coward | more than 12 years ago | (#2120586)

nd their own (open source) database SAPDB.

Actually, I believe that SAPDB is just a renamed ADABAS, which SAP purchased to round out their product offering. This is not to say, however, that SAP is not continuing development on SAPDB, as it makes sense to develop a database that works even better with their products.

OT Question (0)

Anonymous Coward | more than 12 years ago | (#2140321)

I am not a DB developer but, I think I notice something that I would like clarified.

It seems to me that database developers and the database applications that they produce use a totally different type of logic than other developers do. So often I see database applications that are enormously convoluted, very redundant and excessively complex. Furthermore, the actual logic itself seems twisted. They jump through hoops and hurdles to arrive at solutions that seem to require very simple formulas.

My question is, why is this? Is it a result of the DBMS itself? Is it a result of different training and methodologies? Is it a result of the developers being even more eccentric than program developers? It just seems like most often there is a much simpler way of getting the same result.

Re:OT Question (2)

beanerspace (443710) | more than 12 years ago | (#2123177)

I don't know if there is a short answer to your question. To understand what the deal and difference is, requires several levels of knowledge.

For example, think of what it would take to organize your files. Then think of what it would take to automate the organization of files.

In other words, not only do you need to know what a relational database is, but also you need to understand it within the context of a database system. The article does an adequate job of keeping the discussion mostly on the former.

In other words,

some of your confusion may be over how databases view the world.
AND/OR

Some of your confusion may be how database systems implement databases.

It's boring, it's expensive, it's long winded, but it explains just about every aspect of a datase ad.nauseum, "An Introduction to Database Systems [amazon.com]" by C.J.Date.

Re:OT Question - Short Answer (2, Funny)

snatchitup (466222) | more than 12 years ago | (#2140217)

My question is, why is this? Is it a result of the DBMS itself? Is it a result of different training and methodologies? Is it a result of the developers being even more eccentric than program developers? It just seems like most often there is a much simpler way of getting the same result.

The answer is that our database applications are more complicated because they actually do something useful.

Versus OpSys (5, Interesting)

Root Down (208740) | more than 12 years ago | (#2141590)

"Databases are dramatically more complicated than any Web server or operating system technology."

The above is a quote from senior marketing director Bob Shimp, from the article. I will give him the Web Server - which is not to say that it is not complex, but likely not as complex as a robust relational database. I cannot do the same for the OpSys. There is a dramatic difference in the levels of complexity between a monolithic single-user non-multitasking operating system (such as DOS) and a multiprocessing distributed parallel asymmetric (etc etc) OpSys. The quote is not grounded in any sort of evidence, and I have serious doubts as to whether the 'marketing director' would have ever encountered a kernel that did not come from a bag marked 'Orville Redenbocker'. It is simply misguided and misinformed, and the general intent seems to be in undermining confidence in Open Source DBs. (... furthering the myth that open source is 'unreliable'.) Threatened? He likely should be.

I'd like to see an object data model (ODM) open source database come into the scene. Now that would cause a ruckus, challenging both the bottom line and validity of the relational model!

Re:Versus OpSys (3, Interesting)

micromoog (206608) | more than 12 years ago | (#2139359)

I'd like to see an object data model (ODM) open source database come into the scene. Now that would cause a ruckus, challenging both the bottom line and validity of the relational model!

Yeah, all the companies would immediately say "Let's base the future of our business on new and untested technology! Better yet, let's buy it from an unknown vendor!"

Please. The reason relational databases are still very much the dominant technology is that they work, they work well, and they've been working well for decades.

Re:Versus OpSys (2, Insightful)

Root Down (208740) | more than 12 years ago | (#2142402)

Did I say immediately? No. Given the course of programing languages over the last 20 years, object models seem the not too distant future for database applications. Whether they work well or not is a question of both preference and application requirements. Of course new vendors will not leap at the chance to use an unfamiliar database model, and the money backing the relational models upon which several major DBs are based is pressing for it to stay that way. Of course people in support of the ODM are on the fringe right now, but so were Linux users just a few years back. If we stuck with the dominant model in all things, we'd have never progressed.

Re:Versus OpSys (1)

jallen02 (124384) | more than 12 years ago | (#2142158)

PostgreSQL already allows for inheritance in the DB, so it loosely is already object oriented... :)

Jeremy

Re:Versus OpSys (1)

denshi (173594) | more than 12 years ago | (#2143784)

I'd like to see an object data model (ODM) open source database come into the scene. Now that would cause a ruckus, challenging both the bottom line and validity of the relational model!
It might affect the bottom line, but unless an ODM can bring a rigorous assault on relational math, it will do jack shit to relational validity. Last I checked, 'open-source' is not a formal theoretical attack.

Relational is a theoretic description of how to store data, validate it, normalize it. There is no corresponding theory in OO, there is only the developer's style or taste. RDBMSes correctly fill the need for validated data storage for multiple applications written in different languages. ODBs are bound to one programming language, and one object model. RDBMSes query data and return sets; ODBs navigate through object pointers according to the style of the object model. What this all leads to is that RDBMSes are general purpose data stores, whereas ODMs are limited to use by 1 client application as an object store -- an ODM is a glorified embedded DB.

There is a distinction here between OO in programming languages, which is a fine way to structure code, and OO in databases, which is simply a misnomer -- a stored object has no behavior, it's just data. ODMs are really Network Model databases, which were disposed of in the 70s. Go read the theory and the history.

InnoDB (4, Insightful)

flamingcow (153884) | more than 12 years ago | (#2142152)

MySQL has two table types that support row-level locking and transactions. One is tied up in this contractual mess, but the other, InnoDB [innodb.com] has no such issues, and may even be faster for many purposes.

Re:InnoDB (4, Informative)

oingoboingo (179159) | more than 12 years ago | (#2128079)

One is tied up in this contractual mess, but the other, InnoDB has no such issues, and may even be faster for many purposes.

We did recently quite a bit of Perl development using MySQL and InnoDB tables, and they worked (surprisingly) well. Having transactions (finally!!) in MySQL is a huge blessing.

Somewhat related...while the article mentions that MySQL and Postgres don't have the large application development support infrastructures that the bigger commercial database have, they can be a lot quicker to prototype and develop with because of their relative simplicity.

We're in the middle of migrating our application to DB2 on RS/6000, and I have to say I'm missing MySQL's simplicity of administration and configuration...you can try out a lot of new ideas quickly with MySQL, whereas a big chunk of our time at the moment is spent poring over DB2 manuals for obscure command switches and SQL options (the LOAD utility can be a barrel of laughs for newcomers)...of course if our DBA was a little more competent, but that's a different story :-(

(And yes I do realise DB2 is much more powerful/robust...I'm talking about ease of development and rapid prototyping!)

Re:InnoDB (0)

Anonymous Coward | more than 12 years ago | (#2118610)

With regards to DB2 verses MySQL, you could say the same thing about Windows versus Linux. Windows is much simpler for rapid development and prototyping.

DB2 v PostgreSQL (3, Interesting)

/dev/zero (116295) | more than 12 years ago | (#2126631)

I've moved a major (~8GB) database from DB2 to PostgreSQL for a client. It runs faster and is easier to feed and administer now. I'm in the process of moving a similar-sized database and app from MS SQL Server to PostgreSQL for the same reasons (plus the openness of PostgreSQL and Linux).

I really like DB2, it's very powerful, robust, and scalable. But it requires a fair amount of admin expertise and time. Not so much as Oracle, but much more than PostgreSQL.

What, frankly, suprised the heck out of me was the fact that nearly all of my queries (this is an audit system, OLAP, not OLTP) ran between two and four times faster under PostgreSQL. That adds up pretty quickly!

As far as the application development support infrastructures, I'm not really sure what is meant by that. The current implementation of stored procedures in PostgreSQL falls short of what DB2 provides, I'll grant. But support for C, Java, Perl, PHP, Python is all there. It's a pretty high-speed/low-drag setup, IMHO.

The set of problems for which PostgreSQL is the best solution is expanding pretty rapidly. I won't pretend that it's the be-all RDBMS, I don't think such a thing exits. I would say that it's worth a serious look for many situations.

Gordon.

Re:DB2 v PostgreSQL (2)

duffbeer703 (177751) | more than 12 years ago | (#2113783)

In other words, instead of reading some redbooks or, heaven forbid, the DB2 manual, you spent all that time migrating an application to a totally different platform!

It must be great to be a consultant!

Re:InnoDB (3, Interesting)

Hrunting (2191) | more than 12 years ago | (#2132281)

One is tied up in this contractual mess, but the other, InnoDB has no such issues, and may even be faster for many purposes.

That might be the understatement of the year. InnoDB touts itself as the "fastest disk-based database" currently on the market. It's a pretty tall-order, but it lives up to it. Our internal benchmarking tests for our application purposes show it to be about 7x faster than an identical PostgreSQL 7.1.2 solution. I've seen reports on the mailing lists that it can be up to 18x faster. You also get the simplicity and maturity of MySQL. The InnoDB benchmark [innodb.com] page has their own benchmarks, which pretty much mirror what we've seen internally.

Of course, MySQL has other drawbacks, namely that it doesn't support triggers or table inheritance or some of the more complex nuances of standard SQL, but the 95% of stuff it does have is very fast, and the other 5% can be handled in code. MySQL isn't popular because it's open-source, though. It's popular because it's good, free, and most importantly, extremely easy and intuitive to use.

Re:InnoDB (3, Interesting)

tzanger (1575) | more than 12 years ago | (#2130810)

It's a pretty tall-order, but it lives up to it. Our internal benchmarking tests for our application purposes show it to be about 7x faster than an identical PostgreSQL 7.1.2 solution. I've seen reports on the mailing lists that it can be up to 18x faster. You also get the simplicity and maturity of MySQL. The InnoDB benchmark page has their own benchmarks, which pretty much mirror what we've seen internally.

Just a quick look at the benchmarks link tells me that they have fsync turned on on Postgres. What exactly is fsync? Every time Postgres touches the disk, it sync()s. Slow? Hell yeah. But you won't lose data in the cache. It's turned on by default.

I realize that Postgres isn't the fastest in the world, but it's not 7x slower on 100k inserts. That's just bad benchmarking. Deceitful even.

If fsync is not on, I apologize. However the link mentions no performance tuning other than buffer pools and log buffers. If Postgres is defeated by 7x (18x?!) in a fair test, I'll concede. However this looks like the MySQL testing benchmarks on mysql.org; bullshit, plain and simple.

Re:InnoDB (just an addendum) (2)

tzanger (1575) | more than 12 years ago | (#2130995)

Of course, MySQL has other drawbacks, namely that it doesn't support triggers or table inheritance or some of the more complex nuances of standard SQL, but the 95% of stuff it does have is very fast, and the other 5% can be handled in code.

The instant you decide to move data and/or referential integrity from the DB into 'code', you've lost the battle. I can't believe someone would even suggest this. Sure, stored procedures are a plus and most times they aren't necessary, but you simply cannot have your integrity checks outside the DB. That's the whole god-damned point of an RDBMS! If your integrity depends on unusual interactions in the data store, stored procedures are often the only way out. And you can't have stored procs that work to enforce integrity without triggers.

If you haven't got the integrity, you may as well be using a hashed filesystem to store your data for all the difference it would make. Hell, the hashed fs would probably be faster since it isn't pretending to be an RDBMS.

Re:InnoDB (2)

dark_panda (177006) | more than 12 years ago | (#2133405)

Maturity? Just how mature is a RDBMS that doesn't even support referential integrity? Sure, it may speed things up sometimes, but do I really want to make my app code twice as big just to handle referential rules that should have been in the database in the first place?

J

Interbase Online Backups / Replication (3, Insightful)

SparkyUK (10333) | more than 12 years ago | (#2142153)

Actually, Interbase can do "hot" backups and has support for replication.

People really ought to look more closely at Interbase. It just works.

Re:Interbase Online Backups / Replication (0)

Anonymous Coward | more than 12 years ago | (#2111056)

Is that the one IBM bought?

Re:Interbase Online Backups / Replication (1)

webmosher (322834) | more than 12 years ago | (#2119835)

My only problem with Interbase (6.0 Borland Server Edition -- Commercial) is that in order to do even simple SQL based manipulation of data, you have to actually physically write the functions into the DB. They aren't there natively (not in 6.0 anyhow). I have only recently started playing with 6.1 Open Source, but after talking to Borland in the past regarding 6.0, I'd be surprised if they "fixed" the issue.

These functions include things as simple as SUBSTR(), but also limit doing things like DECODE() and NVL() (to allow conditional DB selects). MySQL and Postgres support such functions natively, or have a similar native function.

Re:Interbase Online Backups / Replication (0)

JohnHegarty (453016) | more than 12 years ago | (#2130082)

I just run a cron job .. .copy the database file to a backup harddriver... works without any problems cp /database/databasefile /backup/databasefile

The good part (2)

ajs (35943) | more than 12 years ago | (#2142204)

Because of MySQL's design, there's a silver lining here. The Gemini back-end (which, BTW is the guts of the Progress database (NOT PostgreSQL, which is a competing open source database), under a different name, and open sourced) is totally stand-alone in the sense that the MySQL folks just have to continue to support the table management API that they already had for things like Berkely DB and accept bugs from everyone including NuSphere.

Outside of that, they can stick their fingers in their ears and yell, "lalalalala, we can't here you!" all they like at NuSphere, and no harm comes of it. NuSphere for their part can stick their fingers in their ears too, because 99% of their effort goes into the Gemini back-end and their Apache/PHP/MySQL shrink-wrap bundle.

These two can feud all they like, and still work together seamlessly. This is the part of the open source benefit that most closed source types don't get yet. When they do, it's going to rock thier world!

Re:The good part (2)

whjwhj (243426) | more than 12 years ago | (#2146781)

MySQL uses Progess? I had no idea. I used Progress for a short time and found it to be one of the most ridiculous and obtuse pieces of crap I've ever seen. But MySQL? Love it. My recollection of Progress is that it was more of an integrated development environment, with the DB wrapped in with code. Is this not true?

Databases more complicated? (2, Interesting)

andres32a (448314) | more than 12 years ago | (#2142378)

From Oracle: "Databases are dramatically more complicated than any Web server or operating system technology."

Somehow, Oracle is saying that the Open Source comunity is not 'capable' of producing a dominant database...

Re:Databases more complicated? (4, Insightful)

micromoog (206608) | more than 12 years ago | (#2125352)

Oracle is saying that the Open Source comunity is not 'capable' of producing a dominant database

No. The point is that the design of a great DBMS takes a lot more unity than the large-scale projects OSS has tackled previously. In a DBMS, there must be an internal set of standards for everything from datatypes to join optimization logic.

Databases just don't lend themselves to fragmented development the way operating systems do. Frankly, I'm skeptical that an OSS project could (using current development practices) pull together and produce something as capable and stable as DB2 or Oracle.

Re:Databases more complicated? (0)

Anonymous Coward | more than 12 years ago | (#2110697)

I've spent a few years with Postgres as a production database on a fairly big application, and it seems pretty clear that the parts of Postgres that get worked on are the parts that are interesting/challenging/amusing to the developers. I think that's cool...it's what I'd do, and after all, they are (presumably) working on it for the pleasure of working on it.

But...it's that last 2 or 3 percent of not-very-interesting bug fixes, documentation and not quite implemented features that make all the difference. I'm not using Postgres for new projects.

Re:Databases more complicated? (1)

denshi (173594) | more than 12 years ago | (#2112289)

Databases just don't lend themselves to fragmented development the way operating systems do.
Please back up that assertion. While you are doing that, I would like to remind you that the Postgres developers have never actually met in person. Yours is the same argument that every commercial software provider has employed over the last 5 years against free software. I think the truth of the matter, that no one yet knows real theory behind project management, is far more frightening.

In regards to databases, what you have omitted is that the database problem is 2 decades younger than the operating systems problem. The OS problem was solved by the mid '70s. The RDBMS problem has only been 'solved', if you think it has been, by the early '90s. Linux was able to follow much more well-trod ground than Postgres, and I expect the development time of the latter to consequently lag. I have not, OTOH, seen any evidence supporting your assertion.

Re:Databases more complicated? (4, Funny)

Anonymous Coward | more than 12 years ago | (#2115828)

You are evil. OSS can accomplish anything ... well, web browsers are hard! ... I'm sure a database is easy though!

Re:Databases more complicated? (1)

rycamor (194164) | more than 12 years ago | (#2157017)

Moderators -- this had to be a joke. Don't ya get it? I thought it was pretty funny.

Re:Databases more complicated? (2, Insightful)

pmz (462998) | more than 12 years ago | (#2157078)

OSS projects probably could produce something similar to Oracle or DB2, in time, but is there a Open Source market for the features that make Oracle and DB2 special?

For example, how many users of PostgreSQL, MySQL, etc. are planning on setting up a database that can stay available through nuclear attack or power grid failures? Generally, these super-duper robust databases get set up on several "big iron" servers, which means the licensing and administration for Oracle or DB2 just isn't that big of a deal relative to hardware costs, site construction costs, and staff salaries.

For certain projects, paying for Oracle or DB2 can actually save a heap of trouble, since they are so damn capable. This can make them more than worth their price.

On the other hand, I cannot advocate these super databases for small projects. That's where the current OSS databases fit in quite well. Therefore, would OSS really benefit from trying to compete with Oracle and DB2?

Re:Databases more complicated? (2, Insightful)

tconnors (91126) | more than 12 years ago | (#2141492)

From Oracle: "Databases are dramatically more complicated than any Web server or operating system technology."

Somehow, Oracle is saying that the Open Source comunity is not 'capable' of producing a dominant database...

Not being overly qualified on the issue - but I thought they would both involve much the same issues - concurrency (e.g. - SMP in OS's), failsafe (Hot swap raid, clustering, and a few features yet to be developed for linux), reliabilty/stability (Linux has this!), efficiency, etc etc. It seems several Free OS's have solved all the issues that database manufacturers would face - so what are they claiming could be so complex that Free software people couldn't cope with?

TimC.

Re:Databases more complicated? (1)

telbij (465356) | more than 12 years ago | (#2156996)

I think the point is that DBMS code is much more interrelated, requiring all engineers to know fairly well what all the other code is doing. I still think OSS can do it just fine though.

Who cares who MADE MySQL? (1)

Havokmon (89874) | more than 12 years ago | (#2143603)

What's the difference between MySQL AB, and Nuwhatever MySQL?

Aren't we basically looking at a MySQL vs. Postgres situation between the two?

I thought Open Source was supposed to create competition, with the 'best work' winning out?

Isn't this competitive?

I suppose from now on, every Debian article should mention Linus created Linux, and each tool that's mentioned in any article should give credit to the creator. I don't remember any mention of who wrote 'fortune', or Apache, or Perl, when that kid was arrested for code unbecoming of a student.
You just need to chill on your personal gripes.

DB Maturity (2, Interesting)

it's a culture thing (472974) | more than 12 years ago | (#2143896)

I'd agree with the article that the Open Source offerings currently have many limitations when compared to the commercial ones, but this is more due to their lack of maturity than anything else.

We should remember that oracle & db2 have had over 20 years to get to where they are now. Have a look at this article [joelonsoftware.com] to see what I mean about maturity of products.

However the open source community has several advantages and disadvantages over the commercial players. 1. we dont have all the legacy bloatware which makes the commercial offerings so large 2. we're able to design using current best practice, not something which was dreamed up 20 years ago and no longer applies (no I'm not talking about the relational model but things like distributed storage, sans, nas etc).

However, we also don't have the guarentee that the original developers will still be here in 10 years time, working on the software and adapting it for new needs. Admit it, how many people are prepared to dedicate their careers to a single piece of software? not many. so can you understand why commercial companies are less than eager to use open source for critical/production systems?

Best Practices? (2)

duffbeer703 (177751) | more than 12 years ago | (#2121362)

By best practices, do you mean having warring companies in the midst of litigation seperately developing key database features?

Or do you mean not maintaining things like man pages in an operating system?

Re:DB Maturity (0)

Anonymous Coward | more than 12 years ago | (#2136678)

Actually that is not quite correct. DB2 UDB was a completely new product originally put together on OS/2 in the early nineties.

Re:DB Maturity (1)

Asic Eng (193332) | more than 12 years ago | (#2146194)

Admit it, how many people are prepared to dedicate their careers to a single piece of software? not many. so can you understand why commercial companies are less than eager to use open source for critical/production systems?

That's true, but commercial development has the same problems - programmers don't stick around for ever, and it can be tough to maintain someone else's code. (1)

Similar problems apply to companies as a whole, you don't really know how long they will be around either, or whether they'll continue to support their product (at least not for the 10 year timeframe).

That's a good argument to chose the market leader, I suppose, but on the other hand open source has an advantage there too, since at least you can hire someone to fix the problems you're experiencing. Having the source is an insurance in a way.

(1) Everyone is suffering from the documentation problem: either because you're forced to write it, or because the other guy didn't write any. :)

Re:DB Maturity (2)

it's a culture thing (472974) | more than 12 years ago | (#2141102)

commercial development has the same problems - programmers don't stick around for ever, and it can be tough to maintain someone else's code

I agree with the second part (since thats what I'm doing at the moment). However as to the former, companies do have the advantage of stock options and lock in periods.

That's what's allowed Microsoft to gain the position it has done, staff are recruited for a project and they only get their stock options if they stay for 4.5 years or more. This way you can get the same people working on at least 3 releases of a product, so by the end of their tenure they should be able to solve most problems and know the code inside out.

And of course at the end of 4.5 years the company can then offer them even more to stay or go away. 8)

I agree having the source is good insurance but it still costs money to get people up to speed if the documentations crap so firms will always go to the org. which can supply the help required (e.g. support staff, documentation, bug fixes) even if it costs more in the short term.

Since when is "more" worse? (1)

snatchitup (466222) | more than 12 years ago | (#2144310)

The language resembles Oracle's PL/SQL (Procedural Language/SQL), except that PL/pgSQL offers the use of functions only, not procedures. A function call always returns some result,while a procedure may execute certain operations without returning a result. In some cases, database developers prefer using procedures and "stored procedures,"

So call the function and ignore the results. Duh.. But seriously, the article must not be describing the problem correctly. Do these databases have true Stored Procedures, as in your code running inside the RDBMS with the benefits of transaction management? I doubt it.
The open source db's are way, way behind. Like 15 years behind. If you develop an App of any size, go straight to Oracle on Linux. You can use all the Open source tools with it.

Re:Since when is "more" worse? (0)

Anonymous Coward | more than 12 years ago | (#2141939)

Well, PL/PGSQL function definetly run inside the DB with full transaction management. The problem i had with them is that you cant return whole datasets (and afaicr not even a single row). And there are no out-parameters thus making some jobs unessecary hard.

What is a relational database? (2, Interesting)

MilleniumUcita (449338) | more than 12 years ago | (#2144477)

Does that imply a fully fledged Java VM that executes stored procedures in Java?

Is something like PLSQL a mandatory part of something we call a relational database?

Oracle has a maximum view on relational databases, because it is their instrument to dominate adjacent markets; just as the OS is for M$.

PLSQL is something created for the benefit of Oracle, not for the benefit of the customer, who gets stuck in a proprietary language and horrible design consequences.

Sub-Selects (1)

KingAdrock (115014) | more than 12 years ago | (#2150676)

But does MySQL support Sub-selects?

Re:Sub-Selects (1)

frankrachel (224667) | more than 12 years ago | (#2157036)

No Sub-SELECTs, and no UNIONS..

Re:Sub-Selects (2)

irix (22687) | more than 12 years ago | (#2122436)

No Sub-SELECTs, and no UNIONS.

And as a long-time Oracle user, this is what pisses me off every time I use MySQL.

Well, that and the lack of referential integrity constraints, transactions and a sane backup mechanisim, which are the real reasons MySQL is never used in any kind of serious data environment.

Re:Sub-Selects (2)

SCHecklerX (229973) | more than 12 years ago | (#2157225)

Yeah it bothered me too.

You can code around lack of sub-selects though. It just means you are going to have to run more than one query to get the exact data you want.

Re:Sub-Selects (2, Informative)

denshi (173594) | more than 12 years ago | (#2137159)

It just means you are going to have to run more than one query to get the exact data you want.
Thereby ensuring that your application runs slow as hell!! After all, why instantiate all that overhead talking to the DB, searching the DB cache, scanning disc, and returning data once, when I can do it a half-dozen times!!!

The MySQL crowd just continues to remain ignorant of the fact that full SQL-92 support is not wanking, and it is certainly not a perf hit.

has its purposes (4, Insightful)

beanerspace (443710) | more than 12 years ago | (#2153955)


Bah ! I remember in the early 80's when big iron buddies used to point ant laugh at dBase II. What they didn't understand, and what some of the big database boys and users don't understand now, is that larger isn't always better.

Databases like MySQL make it very easy for webhosting companies to offer free databases without loosing their shirts or minds. They make it very easy for students to learn SQL. They're also much kinder on resource.

Yes, I'd love to be able to roll-back pooched transactions, but then I have to commit everything as well. Certainly cascades would be slick, but poorly written, they can shoot your foot clean off. Likewise, I can see all the lame support calls coming in because users don't understand the triggers are attempting to maintain referential integrity on foreign keys.

Within a given context, sometimes smaller is suits the purpose better.

They don't even mention SAPDB! (0, Flamebait)

zby (398682) | more than 12 years ago | (#2153957)

The exclusion of the most robust Open Source database product makes the article complete crap.

Re:They don't even mention SAPDB! (0)

Anonymous Coward | more than 12 years ago | (#2139303)

SAPDB only runs on Linux/i386 and Win32/i386. The development tools (needed to compile the thing) are not yet completely opensourced.

Re:They don't even mention SAPDB! (1)

popeydotcom (114724) | more than 12 years ago | (#2139358)

and how long as SAPDB been opensource? Less than six months.

I agree with you though! >:|

The article misses some important points (4, Insightful)

rleyton (14248) | more than 12 years ago | (#2153961)

Whilst it's a good and interesting article, echoing many of my reservations wrt. open source databases, it misses perhaps the single biggest point that people need support with an agreed escalation process, for the DBMS implementation - often the single most important component in any system

If a database goes wrong (and in Oracles case, my experience is that that's often), and we can't solve it ourselves, we need to be able to get on the phone and speak to somebody who can help. Now, I know that there are companies that offer support for OS DBMS's, but Oracle, Sybase and IBM's round the clock support offering is what i'm after. and getting skilled technicians (possibly the development team itself) involved quickly. OK, so open source offers this as by merit of "use the source luke", but in a corporate environment, this is neither likely or necessarily sensible.

Another, and perhaps more important, aspect to bear in mind (and this is not covered by the article for obvious reasons) is that Oracle, Sybase and DB2 are not the be-all and end-all of RDBMS offerings. There are better, and often significantly cheaper, closed-source offerings out there. One of my current favourites (which I'm working with at the moment) is Clustra [clustra.com] - a DBMS that offers 99.999% availability, scheduled and unscheduled, pretty much out of the box, with Linux as their first released OS for the latest 4.1 offering

So, in a nutshell - Open source support offerings need to be improved, but don't rule out the smaller fish in this crowded, and very competitive pond.

Who said databases were boring?

Linearly scalable, transparently fault tolerant DB (0)

Anonymous Coward | more than 12 years ago | (#2156898)

Will be coming to a Linux box near you this Sept. Features:

1. Fully transactional

2. Linearly scalable clustering

3. transparently fault tolerant. You can shut down a box in a cluster an clients don't notice a thing. 4. MUCH better performance (on a single box) than Oracle, MySQL, Postgress. When it's available in September download it, and prove it to yourself. The announcement will (hopefully) be posted here.

Caution! Bridge out ahead. (1)

Anonymous Admin (304403) | more than 12 years ago | (#2157125)

It has been exceedingly difficult to get mysql evaluated for use in the corporate world due to its open source nature. (yes, the "but, who do we sue? mindset...). Wars like this one will make it even more difficult. Now we have to tell our managers the DB and the transaction processing come from 2 different and warring companies, but dont worry, they will always be compatable with each other... Oh well, back to oracle for even those projects that mysql is fully capable of performing.

Ignorant question... (1)

mjh (57755) | more than 12 years ago | (#2157342)

I know that this is an ignorant question, but I thought I'd ask it anyway. It may have been asked before in other /. articles. If so, my apologies.

In any case, is it true that MYSQL AB doesn't ever integrate patches that they receive into their code? If this is true, then I can't help but worry that they're eventually going to try an establish themselves as a free software company, and then, since they are the original (and only) copyright holder, that they will suddenly decide to re-license mySQL under a non-free license.

mySQL was only recently re-licenced under the GPL, so it's not like this company hasn't ever had desires to control this code.

Help me out. Is this an irrational fear? If not, then I find myself glad that Nusphere has forked a copy, and abided by the GPL. I know that it was kinda in doubt as to whether or not Nusphere was going to do this, but isn't this a good thing if only to protect against MySQL AB deciding to relicense to a non-free license?

<disclaimer>
I am not employed by, nor related to Nusphere or MYSQL AB in any way. I'm just a curious user with a stupid question.
</disclaimer>

Corporate NUSpehere paid FUD? (1)

gerry,Hacker wannabe (23220) | more than 12 years ago | (#2157832)

Anybody notice that {the article mentions/ quotes NuSphere extensively, mentions InterBase (what is it?) prominently}
Mysql.com is mentioned as a competitor rather than an upstream developer.

Who paid for the booze/women?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...