Java Tutorial - Java Script :
Selection
Although there is no wrong choice, we still must make a selection and be able to justify our reasons. In this case, we select MySQL. Our justification for this is as follows.
At the time of this writing MySQL clearly seems to be the most widely supported open source database project available. This minimizes our risk. PostgreSQL is easily eliminated because of its limited Windows support. Although SAP DB is a powerful option, it has a smaller following than the other products, which can pose difficulties when trying to purchase learning materials or hire programmers who are experienced with the product and technology. Although Firebird has an excellent development community, MySQL resources are more plentiful and easier to find.
Finally, MySQL has been documented by several independent sources to perform as well as any commercial database product in the market. This means that we do not have to compromise performance to use an open source solution. MySQL benchmarks their product against others and publishes these benchmarks regularly. The other products have not documented their performance quite so well
.
This does not mean of course that MySQL is the best choice for every project. In our case, we are focused on developing new code in a Java enterprise environment. This allows us to address database platform limitations through software design. MySQL gives us quite a bit of flexibility in terms of designing a system for performance or accepting a reduction in performance when data integrity is paramount. However, its lack of support for stored procedures means that many database access rules will need to be enforced in places other than the database. Fortunately for us, our focus on delivering a Java platform provides us natural places to enforce these rules (for example in Enterprise Java Beans). In a broader language-heterogeneous environment, the cost ofthis approach is that core business rules need to be developed and enforced in each language that accesses the database.
There is another consideration to take into account. When developing a software project, there is a lag between the time development starts and the time the product is delivered. During this time, the platform itself is going through changes. With a little foresight and planning, development projects can anticipate these changes and plan to leverage them just in time for deployment. This is one reason that platform developers provide early beta access to their products: application developers using the platform can come out with applications that leverage a platform’s strengths at the same time as the platform is released to production. This can be risky if the platform is not delivered on schedule, so a risk-mitigation strategy in these cases is warranted. In our case, we recognize the fact that the MySQL team has identified these shortcomings (like lack of stored procedures) within their product and expect to incorporate them in the next major release. In the mean time, we will design our software for the most current stable version of the platform available.
If your project has specific requirements for triggers and stored procedures to be supported in the database, then MySQL may not be the right choice for you and you should look more closely at the other offerings. Remember that no single choice is always the right choice to meet every need. In our case, MySQL meets our current needs.
So the bottom line is that we select MySQL for the quality, depth, and breadth of the support available for the platform due to its current dominance as an open source database and for the flexibility it offers for creating highperformance applications
