Slashdot Mirror
Oracle To Offer A Free Database
An anonymous reader writes "ZDNet News reports that Oracle is likely to announce a free version of its Oracle 10g Database. Oracle Database 10g Express Edition will be free for development and production use, and could even be distributed with other products. What does this mean for the future of MySQL and PostgreSQL?" From the article: "By introducing a free entry-level product, Oracle intends to get more developers and students familiar with its namesake database, Mendelsohn said. Those customers, Oracle hopes, will eventually upgrade to a higher-end version."
I've been meaning to ask this for a while on Slashdot, but how many people here use a SQL database as part of a hobby or for fun?
I currently have PostgeSQL running on my Tiger box. I initially installed it just to experiment with SQL and database normalization, but now I keep my comic book inventory on it. (I know that this is like swatting a fly with a nuclear weapon but I enjoy using PostgreSQL and it is FREE software.)
As for Oracle's announcement, I think that it can be a good thing, provided you are willing to live with their restrictions and only need support for Linux (x86?) and Windows.
Oracle also has a number of certifications that make it very attractive in certain industries like defense, healthcare, etc. I work in the medical field, and a free 4GB-max "validated" Oracle database is a huge boon to a wide variety of medical ISV's. Given that's it free to redistribute, the OSS/proprietary thing kind of takes a backseat for a lot of these ISVs.
.NET's layered data architecture.
By the same token, I also don't think it's going to drive sales in the way they think it will. Databases are slowly but surely going commodity, at least at the lower end of the market, and this merely reinforces that trend. And along with that, there's an increasingly robust set of tools to obviate the differences between these database for most uses that don't demand extreme peformance, from Hibernate and ORM packages to ADODB and other database-independence layers in PHP to
As a Postgres user, I'm hopeful that Sun's proclaimed interest in Postgres will result in this kind of "validation". However, given Sun's reputedly somewhat lackadaisical commitment to staffing OOo, I'm not holding my breath. With Postgres' extensibility and extremely high-caliber core developer base, I think a strong commitment to validation by Sun could make it a real contender in the medium enterprise space. Validate it, clean up a few features (notably auto-vacuum and passable auto-tuning, maybe some multi-master replication), throw in a simple deployment for ORM or database indirection, and you've effectively moved that commoditization up one layer from the small website developer level.
In the long run, I don't see how this gets Oracle out of the need to transition its core revenue off of its database licenses.
What I've seen a lot of are databases designed by programmers - good programmers too, these guys weren't slouches. They didn't have any formal training in databases or maybe they hadn't paid attention. Programmers tend to approach database design by thinking, "what data structures do I need to get out of this?" Someone more experienced in database design approaches the problem by thinking, "what relationships are here and how do I model them?"
Here's a real-world example. A web-based application that I was hired to extend and maintain included a system for users to exchange the lesson plans they created on the site with other users. In doing this, the users built up something like a buddy list. "These are the people that I often share with." Or you can think of it as being like an address book.
With me so far? OK, the programmer (who was very sharp - probably better at this than I am) approached the database thinking, "what data do I need from this thing," and decided that what he needed was a comma delimited list of userIDs. So he physically stored the buddy list in the database in like a char(500) as a comma delimited list.
That was actually great for what he was doing. He was just showing a user their buddy list. Unfortunately, that isn't normalized. So, there is a question you can ask which can't be answered by the data. That question is, "how many people have userID 50 as one of their buddies?"
See, the correct way of doing this is to have a many-to-many relationship which you implement with a table containing just two columns, userID and BuddyID. So if I'm user 12 and users 13,14, and 15 are my buddies, I have three rows in that table:
UserID BuddyID
12 13
12 14
12 15
Now if I need to ask, "how many people have userID 50 as one of their buddies" I can do select count(*) from X where BuddyID = 50
BTW, I actually fixed this one not by normalizing but with a hack. I appended 0 to the front and back of the buddy list, then I could do select count(*) from user where buddylist like '%,50,%' But hacks aren't how I make my living. I'd prefer to do things the right way. What my boss wanted was, every time you look at this page it shows you who has you set as a buddy. Kind of like what Slashdot does with the "fans" page. If it was normalized, that would be a scan of an indexed column. It would be lighting fast. so fast the page would practically load before you even clicked the link. But doing a "like" on a big char field is slow.
There are I'm sure still other questions that the un-normalized database cannot answer. Also there are problems with deleting users and, the big one, overflowing that char(500). "How many buddies can a person have?" I was asked. "It depends" I said. If all my buddies are low number IDs, I can have a lot. If my buddies are high number IDs, I can have fewer. It's all just huge mess! Of course, it worked according to the original specification though.
I have a lot of respect for the guy who wrote it. And I'm not tooting my own horn either. I've have other people look at databases I've designed and just torn them to pieces. This is just one example where I just happen to know that he did it the wrong way.