The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
The bitter-sweet taste of agnostic database schemas

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Robby Russell

Posts: 981
Nickname: matchboy
Registered: Apr, 2005

Robby Russell is the Founder & Executive Director PLANET ARGON, a Ruby on Rails development firm
The bitter-sweet taste of agnostic database schemas Posted: Sep 27, 2005 10:08 AM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Robby Russell.
Original Post: The bitter-sweet taste of agnostic database schemas
Feed Title: Robby on Rails
Feed URL: http://www.contegix.com/rss/feed.xml
Feed Description: My reflections on programming with Ruby, Rails, PostgreSQL... and learning how to run a business...
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Robby Russell
Latest Posts From Robby on Rails

Advertisement

If you know me at all by now… you might know that I am a huge fan of PostgreSQL. Coming to the Rails camp was a bit of an eye-opener./ Working with PostgreSQL used to save me quite a bit of work and let me sleep at night. I have dealt with the problems that many developers face while working with MySQL. Like many of us in the Open Source world, I was exposed to MySQL more often than PostgreSQL. For several years, I convinced myself that MySQL was awesome because it was fast… but speed isn’t always the most important factor in the technology world. Otherwise, we’d all be coding in C. What PostgreSQL provided to me as a developer was better relational integrity. Foo cannot exist unless Bar does, or vice versa. ON DELETE CASCADE was a godsend and saved me quite a bit of work when building an application. Triggers… Procedural Languages… oh so beautiful.

PostgreSQL was (and is) the Open Source database server that both the Enterprise DBA and Developer could agree on.

Enter Ruby on Rails

At first, I just ignored my instincts and jumped in head first. Pluralization? Primary keys named id? Blasphemy! Yet, I moved forward. After a few days of consistently reminding myself of these new-fangled conventions (I even printed out a little cheat sheet and taped it to my monitor)... I was hooked. Rails worked with PostgreSQL. Let me say that again.

RAILS WORKS WITH POSTGRESQL!

Don’t freak out. Yes, the person who started the Rails project is a MySQL fan... but Rails is database agnostic. It’s true.

I wanted to write an entry to clear up a few myths about Rails.

  • Table names are not forced
  • Primary Key field names are not forced
  • Foriegn Key field names are not forced
  • Legacy databases can work with Rails
  • Active Record (like much of Rails) can be customized for your particular application’s needs

I was, and still am, concerned about trusting Active Record with handling my relational data… because in some cases it wasn’t doing what it should.

In the past, you might have found me advocating the addition of business logic in your database server, whenever possible. It is the gate keeper. The key master. It is not meant to be flexible with your data. If business rules are to change, you change them there so that if you have one or more INPUT streams into your database, the data will not get into your server unless your business rules are met. PostgreSQL even provides you with a nice ERROR message, which some other servers do not. If you can control everything through one INPUT stream (Application Database), then putting these constraints solely in your database abstraction layer is a-ok. However, if you are interfacing with your server through a variety of avenues (Integration Database), you probably already know that your system is going to be a pain to maintain in the long run. So, what are you to do?

Handling Legacy systems is going to be a headache, regardless of what you do… but you can’t always rebuild the whole thing and migrate your data. Add that to your Someday-Maybe list.

When you’re adding new pieces to your application, start by using good tools, frameworks, and practices. For example, try your best to follow the Application Database path to pragmatic enlightenment. Begin working on a new layer for your legacy database. Add on web services that use this layer. Refactor your existing applications. Can they use these new services? ReThink everything. That is… if you have the time and resources to do so.

If you are questioning whether or not to put your business logic in your database abstraction layer, stop. Just do it™. But, do it with caution. Test it. Test it well. I’ll admit that I still add some constraints into my database schemas—I am not ready to give up that extra layer of data security. But, that’s just me. :-)

PostgreSQL works with Rails!

Read: The bitter-sweet taste of agnostic database schemas

Topic: Rita Mapping Previous Topic   Next Topic Topic: Snarky PostgreSQL Humor

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use