Related
I've been spending a considerable amount of time learning MongoDB as part of the MEAN stack (I'm new to the MEAN stack), and I feel like I'm just barely starting to get the hang of it. Recently, however, my supervisor at work (who's an experienced programmer) suggested I learn relational databases (it could be that it's used by more companies), and I have taken his suggestion to heart since I'm only a junior developer, and would like to move up soon. My personal goal/project is to build a social networking site where one group of users have the ability to search for another group of users (and most likely charge a membership fee). Would the database matter for a project like this? I would love to kill two birds with one stone by learning something (and learning it really well) that could be used in my personal project, and in a professional job.
I'm certainly open to learning more than one language, but I need a starting point, so I need something that will help me accomplish my personal goal. Since I've spent a considerable amount of time with JavaScript (as oppose to, say, Python), having to learn relational databases concerns me. Are there any downsides to just sticking to MongoDB?
Thanks in advance!
The first thing you need is to assess what type of data you are going to deal with (will it be structured, easily represented by tables, or it will be more of the non-structured type).
If structured, RDBMS is the way to go.
Incidentally, as far as I know, the first versions of Facebook were implemented using MySQL (the type of DBMS your boss was referring to).
Farid, as you're a junior programmer, I'd suggest you to learn as much as possible of both approach.
The knowledge acquired on one of them will also help you getting the most from the other (as they both concern data, how to structure it and how to query it).
Also, in the day by day job (unless you specialize only in large sites where scalability is the first concern) you might encounter RDBMS more frequently than NoSQL choices.
Both technologies have pro and cons and, unless you know both sides (at least documenting yourself, if not by direct experience) you might go for one solution when the other could have been preferable.
Well, anyone have concern about learn SQL (and use JOIN), but:
One day, you don't know how, you will use it (or understand it), so perhaps is better take a moment for SQL (it's the most widespread)
MongoDB is good if you development a REST service, but if you want make a social network like project, perhaps is better look at Graph database.
Perhaps that video can help, is an overview of SQL vs NoSQL.
In the database world, we have normalisation. You can start with a design, crank the steps and end up with a normal form of the database. This is done on the basis of the semantics of the data and can be thought of as a series of design refactorings.
In object orientated design, we have the SOLID principals and various other adhoc guidelines towards good design.
Do you think it is possible to define the equivalent of normal forms for OO, such that a series of refactoring steps could move a procedural piece of code (or poorly factored OO design) into a correct (in some well-defined sense) formulation with the same functionality?
(NB. Happy to make this community wiki)
It is a possibility, but highly unlikely.
Context
First, in the days when the Relational Model came out, people who worked in IT were more educated and they esteemed standards. Computer resources were expensive, and people were always looking for the best way to use those resources. People like Codd and Date were giants in an industry where people were high tech.
Codd did not invent Normalisation, we were Normalising our non-relational databases long before Relational came along. Normalisation is a theory and practice, published as the Principle of Full Normalisation. We were Normalising our programs, we considered accidental duplication of a subrotine (method) a serious error. Nowadays it is known as Never Duplicate Anything or Don't Repeat Yourself, but the recent versions do not acknowledge the sound academic theory behind, and are therefore its power is unreallised.
What Codd did (among many things) was define formal Normal Forms specifically for Relational Databases. And these have progressed and been refined since then. But they have also been hijacked by non-academics for the purpose of selling their gear.
The database modelling that was invented by Codd and Chen, and finished by Brown had a solid grounding. In the last 25 years, its has achieved Standardisation and been further refined and progressed by many others who had solid grounding.
The World Before OO
Let's take the programming world before OO. We had many standards and conventions, for modelling our programs, as well as for language- and platform-specific implementation. Your question simply would not apply in those days. The entire industry understood deeply that database design and program design were two different sciences, and used different modelling methodologies for them, plus whatever standards applied. People did not discuss if they implemented standards, they discussed the extent to which they complied with standards; they did not discuss if they modelled their data and programs, they discussed the extent to which they modelled their data and programs. That is how we put men on the Moon, notably in 1969.
Dawn of OO
OO came along and presented itself as if no other programming language or design methodology existed before it. Instead of using existing methodologies and extending or changing them, it denied their existence. So, not surprisingly, it has taken 20 years to formulate the new methodologies from scratch and slowly progress them to the point of SOLID and Agile, which is not mature; the reason for your question. It is telling that more than twenty such methodologies have flashed up and died during that time.
Even UML, which could have been an outright winner, applicable to any programming language suffered the same disease. It tried to be everything to everyone while denying that mature methodologies existed.
Demise of the Industry
With the advent of MS, the attitude of "anyone can do anything" (implication: you do not need formal education or qualifications), that quality and pride of profession has been lost. People now invent things from scratch as if no one on the planet has ever done it before. The IT industry today is very low tech. You kow, but most people reading these pages do not know, that there is one Relational Modelling methodology, and one Standard. They do not model, the implement. Then re-implement. And re-implement. Re-factoring as you say.
OO Proponents
The problem was that the people who came up with these OO methods were not giants among professionals; they were simply the most vocal of an un-academic lot. Famous due to publishing books, not due to peer acknowledgement. Unskilled and unaware. They had One Hammer in their toolkit, and every problem looked like a nail. Since they were not formally educated they did not know that actually database design and program design are two different sciences; that database design was quite mature, had strongly established methodologies and standards, and they simply applied their shiny new hammer to every problem, including databases.
Therefore, since they were ignoring both programming methodologies and database methodologies, inventing the wheel from scratch, those new methodologies have progressed very slowly. And with assistance from a similar crowd, without sound academic basis.
Programs today have hundreds of methods that are not used. We now have programs to detect that. Whereas with the mature methodologies, we prevent that. Thin client was not a goal to be achieved, we had a science that produced it. We now have programs to detect "dirty" data and to "clean" it. Whereas in the upper end of the database market, we simply do not allow "dirty" data into the database in the first place.
I accept that you see database design as a series of re-factorings, I understand what you mean. To me it is a science (methodology, standards) that eliminates ever having to re-factor. Even the acceptance of re-factoring is loud signal that the older programming methodologies are unknown; that the current OO methodologies are immature. The danger, what makes it annoying to work with OO people, is that the methodology itself fosters a confidence in the One Hammer mentality, and when the code breaks, they have not one leg to stand on; when the system breaks, the whole system breaks, it is not one small piece that can be repaired or replaced.
Take Scott Ambler and Agile. Ambler spend 20 years publicly and vociferously arguing with the giants of the database industry, against Normalisation. Now he has Agile, which although immature, has promise. But the secret behind it it Normalisation. He has switched tracks. And because of his past wars, he cannot come out and declare that honestly, and give others due credit, so it remains a secret, and you are left to figure out Agile without its fundaments being declared.
Prognosis
That is why I say, given the evidenced small progress in the OO world over the last 20 years; the 20 or so OO methodologies that have failed; the shallowness of the approach, it is highly unlikely that the current OO methodologies will achieve the maturity and acceptance of the (singular) database design methodology. It will take at least another 10 years, more likely 20, and it will be over taken by some replacement for OO.
For it to be a possibility two things need to happen:
The OO proponents need formal tertiary education. A good grounding in the science of programming. Sure, anyone can do anything, but to do great things, we need a great grounding. That will lead to the understanding that re-factoring is not necessary, that it can be eliminated by science.
They need to break their denial of other programming methodologies and standards. That will open the door to either building OO on top of that, or taking the fundaments of that and merging it into OO. That will lead to a solid and complete OO methodology.
Real World OO
Obviously I speak from experience. On our large projects we use the mature analysis and design methodologies, one for database and another for function. When we get to the code-cutting stage, we let the OO team use whatever they like, for their objects only, which usually means UML. No problems with architecture or structure or performance or bloatware or One Hammer or hundreds of unused objects, because all that was taken care of outside OO. And later, during UAT, no problems with finding the source of bugs or making the required changes quickly, because the entire structure, has documented structure; the blocks can be changed.
I think this is an interesting question, because it presumes that Codd's Normal Forms are actually the definition of "correct" design. Not trying to start a flame war with that statement, but I guess my point is that there are very good reasons that many DB's aren't fully normalized (e.g. join performance) leads me to think that the real-world equivalent of normalization in OO space is probably design patterns or (as you said) SOLID. In both cases you're talking about idealized guidelines that have to be applied with a suitably critical eye, rather than slavishly followed as dogma.
Not only do I fully agree with Paul, but I will go a step further.
Models are just that - only models. The Normalization models used by Relational Databases are only one approach to storing and managing data. In fact, note that while RDBMS's are common for Data Manipulation operations (the standard CRUD), we have now evolved the DataWarehouse for consolidation, analysis, and reporting. And it most definitely does NOT adhere to the normalization models found in DML land.
Now we also have Google with their BigTable architecture, and Apache with Hadoop. These newer modeling systems reflect a change in the landscape, driven by the idea of the DISTRIBUTED database. Normalization need not apply for this club either.
We can apply a successful model ony to the point at which it becomes not-so-successful, or is supplanted by an model which better suits the needs of the designer. Note the many ways we humans have modelled our universe through physics/Astronomy what have you. Modelling attmpts to describe a system in discreet terms, but as the system, or the needs of the system change, so must the model.
OOP is and has been a very, very successfulk way to model computer applications. However, the needs of the application designer are different from thos eof Database designers. MOST of the time, there is a point at which the designer of an application must consider that his program will be interacted with by humans. Unlike the database designer, whose work will (mostly) be expected to interact with other code, the programmer's job is to take the machine and make it accessible to a much more random human-being. This art does not map quite so well to such standards like normalization.
All that said, n-tier, MVC, MVVC, and other paradims DO establish some guidelines. But in the end, the problem-space of application design is usually not as easy to fit into such discrete modelling steps as a relational databse.
Wow. Apologies for the length. If this is a breach of ettiquette here, do let me know . . .
Many developers seem to be either intimidated or a bit overwhelmed when an application design requires both procedural code and a substantial database. In most cases, "database" means an RDBMS with an SQL interface.
Yet it seems to me that many of the techniques for addressing the "impedance mismatch" between the two paradigms would be much better suited to an ISAM (indexed-sequential access method) toolset, where you can (must) specify tables, indexes, row-naviagation, etc. overtly - exactly the behavior prescribed by the ActiveRecord model, for instance.
In early PC days, dBASE and its progeny were the dominant dbms platforms, and it was an enhanced ISAM. Foxpro continues this lineage quite successfully through to today. MySQL and Informix are two RDBMSs that were at least initially built on top of ISAM implementations, so this approach should be at least equally performant. I get the feeling that many developers who are unhappy with SQL are at least unconsciously yearning for the ISAM approach to be revived, and the database could be more easily viewed as a set of massively efficient linkable hyper-arrays. It seems to me that it could be a really good idea.
Have you ever tried, say, an ORM-to-ISAM implementation? How successfully? If not, do you think it might be worth a try? Are there any toolsets for this model explicitly?
Maybe Pig Latin is what you want? According to this article
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf :
"Besides, many of the people who ana-
lyze this data are entrenched
procedural programmers, who find the
declarative, SQL style to be
unnatural. The success of the more
procedural map-reduce programming
model, and its associated scalable
implementations on commodity hard-
ware, is evidence of the above.
However, the map-reduce paradigm is
too low-level and rigid, and leads to
a great deal of custom user code that
is hard to maintain, and reuse. We
describe a new language called Pig
Latin that we have designed to fit in a
sweet spot between the declarative
style of SQL, and the low-level,
procedural style of map-reduce."
There are certainly times and places where ISAM provides the services needed by the application with less cost and overhead than a full-blown SQL DBMS. One downside of an ISAM mechanism is that there isn't necessarily a system catalogue to describe the data; another is that generally there are few user-friendly tools to get at the data. These are both places where the RDBMS provides considerable advantage. The best ISAM (or similar) systems provide transaction support - even XA transactions, sometimes.
Where you need to do complex joins and computations (aggregates, for example), the work done by the DBMS provides huge benefits. Where all you need is access to records, then ISAM could be beneficial.
Security tends to be harder to enforce with an ISAM-based system than with a DBMS. Also, you need to worry about integrity of the files in case of a crash. Most DBMS use a two-process architecture (DBMS client in a separate process from the DBMS server), which provides resilience in the face of the client crashing (or the client PC being turned off). You also have to worry about backup and restore - a competent DBMS has systems in place for providing a coherent backup of a database while the database is in use; it is not clear that ISAM systems would provide that level of integrity.
Overall, given a suitable ISAM mechanism, there would at least sometimes, maybe often, advantages to using an ISAM mechanism in an ORM system instead of a full RDBMS.
I implemented an ORM-to-isam library back in the 1990s that enjoyed some (very) modest success as shareware. I largely agree with what you say about the virtues of ISAMs and I think it better to use an ISAM when building an ORM layer or product if you are looking only for flexibility and speed.
However, the risk that you take is that you'll lose out on the benefits of the wide range of SQL-related products now on the market. In particular, reporting tools have evolved to be ever more tightly integrated with the most popular SQL packages. While ISAM product vendors in the 1990s provided ODBC drivers to integrate with products like Crystal Reports, it seemed, even then, that the market was trending away from ISAM and that I would be risking obsolescence if I continued using that technology. Thus, I switched to SQL.
One caveat: it has been nearly a decade since I was playing in the ISAM sandbox so I cannot purport to be up on the latest ISAM tools and their solutions to this problem. However, unless I was convinced that I was not going to be trapped without reporting tools support, I would not adopt an ISAM-based ORM regardless of its virtues. And that doesn't even cover the other tools available for SQL-based development!
I did my share of dBase, Clipper and FoxPro. However I believe the relational model provided by SQL is infinitely more powerful and useful, and products like Oracle and SQL Server deserve their success in the marketplace.
I'm always surprised why people make such a big deal of creating a mapping layer for the ~80-90% of the cases and writing 10-20% of custom SQL to deal with complex queries (mostly reports) and batch data movement. I must be doing something really good or something really silly by adopting the DAL/DAO model, given the level of hatred against hibernate, active record, etc. - vide Vietnam discussion from earlier.
Multivalue database anyone? (aka Pick) Think XML without the tags. They predate RDBMS by at least a decade, and still going strong if you know where to look.
If you know exactly what you want to do with your data and how you want to do that, pick ISAM. You will be happy because you will have structured your indexes to serve your exact needs. Know upfront that if your needs change, you will want to change your indexing. Data access will be blazing fast.
If you are not sure what uses the data will be put to, or you know your data needs will change a lot over time, pick SQL. You will have the flexibility of ad hoc queries, quick reporting turnaround, data mining, etc.
Both types of databases have matured over the years. Both can have robust servers with live backup, transactions, security, metadata, etc.
Old question, but interesting discussion. The concepts of ISAM are important, the additional features that we're provided in today's RDBMSs (as discussed i.e. backup, consistency, security, metadata) offer us signficant benefits.
With the NoSQL craze (yes I said it...craze) it doesn't mean that we can't model ISAM-like access inside the RDBMS. You'll be sure I'm gonna push off as much logic to the DB as I possibly can, but there are times like "traditional" data gridding/multi-dimensional data interpolation where I'll traverse all necessary records via my own logical index.
If I were designing a oil refinery, I wouldn't expect that materials from different vendors would not comply with published standards in subtle yet important ways. Pipework, valves and other components from one supplier would come with flanges and wall thicknesses to ANSI standards, as would the same parts from any other supplier. Interoperability and system safety is therefore assured.
Why then are the common databases so choosy about which parts of the standards they adhere to, and why have no 100% standards-compliant systems come to the fore? Are the standards 'broken', lacking in scope or too difficult to design for?
Taking this to conclusion; what is the point of ANSI (or ISO) defining standards for SQL?
Edit: List of implementation differences between common databases
In the software industry you have some standards that are really standards, i.e., products that don't comply with them just don't work. File specifications fall into that category. But then you also have "standards" that are more like guidelines: they may defined as standards with point-by-point definitions, but routinely implemented only partially or with significant differences. Web development is full of such "standards", like HTML, CSS and "ECMAScript" where different vendors (i.e. web browsers) implement the standards differently.
The variation causes headaches, but the standardization still provides benefits. Imagine if there were no HTML standard at all and each browser used its own markup language. Likewise, imagine if there were no SQL standard and each database vendor used its own completely proprietary querying language. There would be much more vendor lock-in, and developers would have a much harder time working with more than one product.
So, no, ANSI SQL doesn't serve the same purpose as ANSI standards do in other industries. But it does serve a useful purpose nonetheless.
Probably because standards conformance is of a low priority to database system purchasers. They are more interested in:
compatibility with what they've already got
performance
price
OS support
to name but a few factors.
The same is true of programming languages - very few (if any) compilers support every single feature of the current ANSI C and C++ standards.
As to why bother with standard, well most vendors do eventually bring standard support on board. For example, most vendors support more or less all of SQL89. This allows the vendor to tick a (relatively unimportant) check-box on their spec sheet and also allow people like me who are interested in writing portable code to do so, albeit having to forgo lots of bells and whistles.
See the article "IS SQL A REAL STANDARD ANYMORE?" for a discussion about the current (2005) issues of the SQL standard.
Indeed, the ANSI SQL standard is not often followed. Just read SO: most SQL threads never refer to the standard while, for instance, discussions on network protocols often include the actual quote, chapter and verse of the relevant RFC.
I always suspected that one of the reasons is the fact that the SQL standard is not freely distributable. Simply getting it is not trivial. Various unofficial copies float around.)
Another reason is that it is a very complicated text and poorly organized. It uses a strange vocabulary (such as "authID" instead "user"). You need books just to understand the standard ("A guide to the SQL standard", C.J. Date, Hugh Darwen -
Addison-Wesley).
Mimer SQL has great standards support, yet it is pretty unknown. It is in production in several large sites, mostly in Sweden. But I think a lot of sites are migrating to others.
Detailed support statments:
SQL-99
SQL-2003
PSM
Database triggers and functions according to SQL:1999
Binary and Character Large OBjects (BLOB/CLOB/NCLOB) support according to SQL:1999
Multi-database transactions (two-phase commit) conforming to Open Group's XA-standard
Support for Java ME CDC Foundation Profile and Java ME CLDC/MIDP
I don't know the history of ANSI SQL specifically. But it seems that many times in software development, standards are written after the major players have already implemented their own proprietary versions of things. Once a company is invested in its own way of doing things, it's really hard to justify changing or removing features people have come to rely on just to adhere to a standard. Web standards are a primary example of this phenomenon.
A few years ago, one of the worst industries as far as pipes and connectors being mutually compatible was firefighting equipment. There were literally dozens of mutually incompatible hose to pump connections. When mutual aid became commonplace among fire fighters, they had to bring along dozens of adaptors to be able to interoperate their equipment.
On September 11, both police and firefighters had private wireless networks for intercommunicating among their people. But, guess what? The two systems were not mutually compatible. So there were needless delays in communicating information from one kind of public safety servant to another.
If you go back far enough, you can find a time in New York City where about half the electric grid was DC, favored by Edison, and the other half was AC, favored by Westinghouse.
Standards sometimes come about by themselves, and are called de facto standards. More commonly, standards have to be set forth by a body specifically empowered to make it happen. As to the SQL standards, some of the largest vendors pre date the standard. In order to comply with the standard, they would have to put in engineering expense that doesn't benefit their existing client base. Worse yet, they might end up being incompatible with their own prior product.
Full compliance with the SQL standard might yet happen, but it's unlikely. Even if it does, there's a delay time between the evolution of a new SQL standard and compliance with it.
IMHO, the DB vendors push forward the ANSI SQL standards to include new features & constructs within their field much more than ANSI telling the DB vendors the "one true way".
The DB market is driven by features, scalability and cost. It is not a commercial priority to forego and delay a technical advantage (i.e. partitioning, pivot, UPSERT, replication) by waiting for ANSI to ratify the syntax. By the time that has been done, there is already a significant installation of the proprietary syntax.
That being said, most DB vendors have improved their core "ANSI SQL" support greatly in the last few years. (SQL Server with the SELECT FROM INFORMATION_SCHEMA and Oracle's ANSI joins actually working as well as native joins under the CBO)
According to the HSQLDB manual, it is the most standards compliant RDBMS.
Almost all syntactic features of SQL-92 up to Advanced Level are supported
SQL:2008 core and many optional features of this standard
The real reason: most "developers" are client-centric coders, and therefore neither understand nor care about Dr. Codd's 12 rules. This is also why MySql, which isn't a relational database in any significant manner, is frequently seen in webKiddie development. Such developers only want rudimentary SELECT, UPDATE, DELETE parsing. They eschew constraints of any kind, preferring to "do it in the application". Reactionary 1960's applications are what you get.
Most of them are pretty compliant. But here's the bad news, IMO - standards breed mediocrity. Vendors want you to get locked into their extensions, and there's often good reason to do to nonstandard things. Realistically, how likely are you to dump Oracle for SQL Server, or vice-versa? Unless you build a product that your cusotmers may use against other databases, you as an enterprise are unlikely to swap out DB's. Too painful.
Companies usually tend to use one vendor to avoid having a jungle of different and possibly incompatible systems to support. It's also a lot cheaper to train your developers/system engineers in using one database vendor's tools than in 3 different sets of tools. Later on, this company may then grow large enough to buy some of its competitors. This would mean another entirely different set of tools that you'd have to manage, integrate, etc.
That's a lot of work.
Imagine that instead of that, you have a portability layer so that you really don't care what's beneath. That would be a lot better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We're living in a golden age of databases, with numerous high quality commercial and free databases. This is great, but the downside is there's not a simple obvious choice for someone who needs a database for his next project.
What are the constraints/criteria you use for selecting a database?
How well do the various databases you've used meet those constraints/criteria?
What special features do the databases have?
Which databases do you feel comfortable recommending to others?
etc...
I would think first on what the system requirements are for data access, data security, scalability, performance, disconnected scenarios, data transformation, data sizing.
On the other side, consider also the experience and background of developers, operators, platform administrators.
You should also think on what constraints you have regarding programming languages, operating systems, memory footprint, network bandwidth, hardware.
Last, but not least, you have to think about business issues like budget for licences, support, operation.
After all those considerations you should end up with just a couple of options and the selection should be easier.
In other words, select the technology that suits the best the constraints and needs of your organization and project.
I certainly think that you are right on saying that it is not an obvious choice given the wide number of alternatives, but this is the only way I think you can narrow them to the ones that are really feasible for your project.
My selection criteria (mainly programming centric):
Maintenance: How are updates/hotfixes installed?
Transaction control: How it is implemented
Are Stored Procedures supported?
Can you use exception handling in Stored Procedures?
Costs
As a benefit: Can you use recursion on Stored Procedures? (E.g. in SQL Server 2000 the recursion stops after 32 passes IIRC)
For most people in a corporate environment the choice comes down to "the one we have".
Since you seem to be fortunate enough to have a choice, I'll take a quick run through the questions and maybe pose a few more at the end.
The biggest criterion may be cost. Do you want/are you prepared to pay for your DBMS platform? If not, then Oracle, MS SQL Server, Sybase and others are probably out, although if you're not building a commercial app then there may be some wiggle room. Also, platform - can you run the software on your hardware?
Other dimensions for consideration might include expected number of concurrent connections, transactional vs mostly reads, size, availability and I guess lots of others.
"Special features" are, in the main, to be avoided - in my cynical world-view they're intended to lock you into a platform. So something like Oracle's PL/SQL is a feature that, while powerful (and likely to mean the need for extra CPU power at more licensing cost) is not portable. If you expect extremely high volumes then partitioning may be useful, I suppose.
I have worked with Oracle, MS SQL Server, MySQL, PostreSQL, SQLite and Sybase that I can think of. I'd happily recommend all but Sybase, about which I have some concerns these days (I could easily be wrong, but personally I think the money could be better spent elsewhere) but not all for the same applications.
Ideally, I like to have the warm feeling that it doesn't really matter what DB platform I'm using because I can port easily. With a good abstraction layer between data and business logic, I should be able to develop locally against, say, the excellent SQLite and implement painlessly on, for example, Postgres. With something like ActiveRecord from Rails coupled with a little awareness of things like differences in reserved words, this is almost completely cost-free.
Surely the most compelling factor is the expertise of you or your team...or the pool of resource you are likely to hire in the future. I would tend to go with the grain most of the time, using MySQL in a LAMP team and SQL Server in a MS team, since either of these products is capable of doing everything necessary even in a high-load environment.
The benefits of any other database are going to be marginal compared to the pain of learning how to use it well. The only exception to this, in my opinion, would be in a high-demand environment where:
a. the obvious choice has been tried and is failing
b. the benefits of scaling multiply the marginal benefit to such a degree that it will be worth the cost of using something unexpected.
I would assume the need to hire at least two and preferably three excellent DBAs with long term familiarity with the new database.
And first I would try to hire them for the technology that was failing, because it is more likely to be the way it's used than the technology itself that is causing the problem.
The existing answers are great. It's worth bearing in mind that Oracle now has an XE version of it's 10g database which is available for free and comes with Application Express, a great web based development environment.
It is limited, 4GB HD, 1 GB Ram and uses only one CPU. This is enough to run smaller system though and can be upgraded easily at a later date if necessary. Oracle can be one of the toughest to learn but is also one of the best to have on your CV :-)
I think SQLServer from Microsoft also has a 'starter' type database. Don't discount the commercial products - if you are going to bet your company on a database technology I would rather be using a product from Oracle or Microsoft personally. Thats not to say there is anything wrong with Open Source.
Spend a while evaluating them :-)
Linux, Web Hosted - MySQL (PostreSQL maybe)
Mainstream SME - MS SQL
Big Iron (banking etc) - Oracle
Thinking about anything other than those three is masturbation - any of the other databases becomes a discussion about niche products to solve particular problems that you probably haven't encountered yet. If you choose anything other than the three above you will -
Struggle to find people to work on the project or keep the database going
Struggle to motivate your decision without an academic discussion
Someone will curse you, your ancestors and your lineage a few years down the line - and replace your choice anyway.
Niche databases are not where architectural strides are made - it is technologies like middleware, messaging, cloud services etc where you can afford to (and should) go out on a limb to find good products.