Ruby on Rails chases simplicity in programming

TalkBack 19 of 34:

Next »

« Previous

• Thread View
• Flat View

Multiple database vendors

Your point is a completely valid one.

The approach I've taken in the past and generally use even if there is only a single database vendor is creating separate modules for each possible database but all using an identical interface making them interchangeable. The client application isn't concerned with the database in the slightest or how it retrieves the data. Even other methods of retrieving the data like webservices could be used if the requirement ever arose.

If a database supports stored procedures, I say always use them. It can be extra work, but worth it when changes need to take place. When stored procedures are not available (e.g. MySQL 4.x) dynamic queries are used and embedded as a resource rather than just inlined or in a separate file that can be tampered with easily.

Just like everything else, nothing in the technology world is "one size fits all." The best solution varies greatly depending on what you're trying to accomplish.

Posted by: Yensi717   Posted on: 11/01/05 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
• Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now
• VMware Infrastructure: A Guide to Bottom-Line Benefits VMware Frustrated by the costs of maintain ever larger data centers?or building ... Download Now