It’s less important which exact conventions you choose to follow – but this page has a few suggestions.

The benefits of using a naming convention are more to do with human factors than any system limitations – but this does not make them any less important.

Table Names

Table names are plural, field name is singular

Table names should not contain spaces, words should be split_up_with_underscores.

The table name is limited to 30 bytes which should equal a 30 character name (try a DESC ALL_TABLES and note the size of the Table_Name column)

If the table name contains serveral words, only the last one should be plural:
APPLICATIONS
APPLICATION_FUNCTIONS
APPLICATION_FUNCTION_ROLES

There are pros and cons to adding a prefix or suffix to identify tables-

Pros: If most access will be made via VIEWS then prefixing all the tables with T_ and all the views with V_ keeps things organised neatly, you will never accidentally query the wrong one.

Cons: Suppose, your naming convention is to have the ‘_TAB’ suffix for all tables. According to that naming convention, the APPLICATIONS table would be called APPLICATIONS_TAB. If as time goes by, your application gets a second login, perhaps for auditing, or for security reasons. To avoid code changes, you will then have to create a View or Synonym that points at the original tables and is confusingly called APPLICATIONS_TAB.

Of course if all your code was written against Views in the first place then you skirt right around that issue.

Field Names

Ideally each field name should be unique within the database schema. This makes it easy to search through a large set of code (or documentation) and find all occurences of the field name.

The convention is to prefix the fieldname with a 2 or 3 character contraction of the table name e.g.

PATIENT_OPTIONS would have a field called po_patient_option

PATIENT_RELATIVES would have a field called pr_relative_name

ABSENCES would have a field called ab_start_date

In a large schema you will often find two tables having similar names which could result in the same prefix. You can avoid this by thinking carefully about the name you give each table – and documenting the prefixes to be used.

For very complex systems (thousands of tables) consider alternatives e.g. a prefix/suffix to identify the Application module.

Keeping names short: Oracle places no limit on the number of columns in a GROUP BY clause or the number of sort specifications in an ORDER BY clause. However, the sum of the sizes of all such expressions is limited to the size of an Oracle data block (specified by the initialization parameter DB_BLOCK_SIZE) minus some overhead.

Primary Key Fields - indicate by appending _pk

e.g.

PATIENTS would have a primary key called pa_patient_id_pk

REGIONS would have a primary key called re_region_id_pk

And so on…the name of the primary key field being a singular version of the table name. Other tables containing this as a foreign key would omit the _PK

so
CLINIC_ATTENDANCE might then have a foreign key called ca_patient_id
or alternatively: ca_patient_id_fk

Tables with Compound PK’s, use _ck in place of _pk

Notice that where several tables use the same PK as part of a compound foreign key then the only unique part of the FK fieldname will be the table prefix.

View Names

View names are plural, field name is singular

View names should not contain spaces, words should be split_up_with_underscores.

While it is common to prefix (or suffix) all views with V_ or VW_, a strong argument can be made that neither are really needed.

One of the easiest ways to boost the performance of an application is to provide, at an early stage in the design, a carefully tuned set of views, then write all the application code against those Views.
Giving your Views friendly easy names will promote their use by developers and end-users, this in turn will mean fewer badly written queries and more use of ‘shared SQL’ which will improve the cache hit ratio.

For very large systems, it can make sense to prefix tables/views with the application module name, so a database holding data for both Widget Production and Human Resources data might prefix everything with either HR_ or WP_

Index names

Name the Primary Key index as idx_<TableName>_pk

e.g.
PATIENTS would have a primary key index called idx_patients_pk

Name a Unique Index as idx_<TableName>_uk

e.g.
PATIENTS would have a unique index called idx_patients_uk

Where more indexes are added to the same table, simply append a numeric:

idx_<TableName>_##

Where ## is a simple number

e.g.
PATIENTS would have additional indexes called idx_patients_01, idx_patients_02,…

Note – Conventions that attempt to use the column name as part of the index name become unmanageable as soon as you have multiple columns appearing in multiple indexes.

Constraints

Primary and Unique constraints will be explicitly named.

Name the Primary Key Constraint as pk_<TableName>

e.g.
PATIENTS would have a primary key index called pk_patients

Name a Foreign Key Constraint as fk_<TableName>

e.g.
PATIENTS would have a Foreign Key constraint called fk_patients

Note – in general each constraint should have a similar name to the index used to support the constraint.

Other Fields

Without getting carried away, you can also apply a suffix to non key fields where this is helpful in describing the type of data being stored.
e.g.
A column used to store boolean (Yes/No) values can be given a _yn suffix: retired_yn, superuser _yn, driver_yn

In lookup tables an easy way to identify the main text field is to name it as a singular version of the tablename
e.g.

asset_types.at_asset_type_id_pk   (Primary Key)
asset_types.at_asset_type         (Text field)
asset_types.at_network_yn         (boolean)

SQL

Type all SQL statements in lowercase, being consistent with capitalisation improves the caching of SQL statements. A common variant is to put only SQL keywords in capitals.

SELECT
   em_employee_id_pk,
   em_employee,
   ab_start_date
FROM
   employees em,
   absences ab
WHERE
   absences.ab_employee_id=employees.em_employee_id_pk;

You already have a unique prefix worked out for every table, so use the same thing when an ALIAS is required – this makes the SQL much easier to read.

Always list tables in the FROM / WHERE clause in desired join order – even with CBO you are giving the Query Optimiser less work to do.

PL/SQL

Prefix scalar variable names with v_
Prefix global variables (including host or bind variables) with g_
Prefix constants with c_
Prefix procedure or function call parameters (including sql*plus substitution parameters) with p_

Prefix record collections with r_ (alternatively suffix with _record)
Prefix %rowtype% collections with rt_ (alternatively suffix with _record_type)

Prefix pl/sql tables with t_ (alternatively suffix with _table)
Prefix table types with tt_ (alternatively suffix with _table_type)

Suffix cursors with _cursor
Prefix exceptions with e_

If a pl/sql variable is identical to the name of a column in the table Oracle will interpret the name as a column name.

Packages
Prefix package names with PKG_

Write one package for each table – named PKG_TABLENAME, put all other code that logically belongs to the schema, but not to any particular table in a single Schema package PKG_SCHEMANAME.
If, as is likely, more complex grants are required for different groups of users then create an additional package for each workgroup – these should contain no code just wrappers that call procedures/functions in the other packages.
This gives a level of separation between the basic code and the user security/grants and makes it easier to change one without breaking the other.

A pl/sql function name like PAYROLL.TAX_RATE the word PAYROLL could refer to either a schema or a package name.

Edit Replace

If you apply a naming convention and then decide to rename something it may be possible to use Edit-Replace to update the associated code. But consider these two fieldnames:

area_codes.ac_code
region_area_codes.rac_code

The columns may be unique but one is a substring of the other!

Instance

Oracle database instance names are limited to eight characters. The first two or three characters of the name should reflect the Application, with the remainder indicating the nature of the instance.
e.g.

Live instance   SSLive
Test instance   SSTest
Train instance  SSTrain
Data Warehouse  SSdw
Staging Area    SSsa

Data Files

Name Data files so that they identify the instance and the tablespace.

Each filename should end with a two digit numeric value starting with 01, that is incremented by 1 for each new datafile added to the tablespace.
Use the extension “.dbf”
e.g.

SSLive_temp01.dbf
SSLive_rbs01.dbf
SSLive_clinical01.dbf
SSLive_clinical02.dbf

Tablespaces

Avoid naming tablespaces according to time periods.
(Oracle never forgets a tablespace and SMON will scan the list of tablespaces in TS$ every 5 minutes) For a partitioned datawarehouse, try to adopt a strategy of recycling the tablespace names.

Redo Logs

The redo log is a separate file (not in the tablespace)
Name Redo Logs so that they identify the instance, group and member number of the log. Use the extension “.log”
e.g.
SSLive_redo_01.log

For more detail on the physical placement of files see Oracle Optimal Flexible Architecture (OFA)

Documentation

Lastly – write and maintain a data dictionary for all data elements – rather than just dumping the Oracle data dictionary into a text document or an Entity relationship diagram – you should also be defining the business meaning of each data item.

Summary

RDBMS naming conventions can become the subject of endless debate – here are a few last things to consider:

Does your naming convention make names longer or shorter?

PURCHASE_ORDER_DATE versus PO_DATE

Will you have novice users writing SQL against the database?
If so will they understand the meaning of things like PO_DATE

Is the naming convention documented somewhere that everyone can find? If you arent planning to change it very often, drop the text right into a tableSELECT * from Naming_Conventions;

Related:

Ask Tom – Argues against the column prefix
Oracle-Base.com Naming conventions
SQL convention from Philip Greenspun
Reddick Naming convention (hungarian notation)
Joe Celko – 10 Bad Habits
SQL Server Naming conventions
Oriolecorp – File Naming, password conventions
SQL formatter – Online SQL beautifier
Q189220 – Microsoft support for spaces in fieldnames
Standard ISO-11179 – Rules for defining data elements
Optimal Flexible Architecture (OFA)

Ruby on Rails (or simply “Rails”) is an exciting new framework that developers, DBAs, and system administrators can use to quickly develop Web applications. The framework is open source and rapidly gaining in popularity. It allows you to prototype and develop Web applications with database integration in a fraction of the time possible with other frameworks.

Most of the Rails examples and tutorials available today involve the creation of a new database schema with tables and columns that adhere to structures and naming conventions that the framework expects. These tutorials also assume a rather simple object-relational mapping that is not feasible when working with legacy schemas. However, both the framework and Oracle Database offer features that can be leveraged to allow the creation of Web applications that are integrated with legacy schemas.

This article describes the techniques for creating a Web front end to the Oracle demonstration schema HR. The code available for download with this article includes a complete Ruby on Rails Web Application that was developed on the HR schema running on Oracle Database 10g Express Edition (XE).

The downloaded application works on Windows or Linux. Linux users should convert all backslashes to forward slashes when performing commands described in this article.

Why Ruby on Rails?

Numerous platforms are available for Web development, including Microsoft .Net, Java 2 Enterprise Edition, and PHP. Furthermore, Oracle Application Express (formerly HTML DB), a feature of Oracle Database 10g (also available standalone), is widely considered an ideal platform for quickly developing Web applications with Oracle Database integration. So why has there been so much interest in a new platform using a relatively unfamiliar language?

By its design, Rails allows extremely rapid development of Web applications. It accomplishes this by adhering to conventions rather than forcing a developer to make all of the configuration decisions up front. Once Ruby and the various required packages are installed, you can create a minimal Web application by running less than half a dozen commands and editing one file (database.yml). Included code generators or libraries address many of the most common tasks in Web development. The Ruby language has the object-oriented capabilities of a language like Java but can also be used for creating simple scripts. The range of capabilities of the language enables you to create applications without having to resort to numerous divergent technologies to accomplish the tasks at hand.

Rails has gained an almost legendary reputation for promoting rapid application development. Part of the way this goal has been accomplished is by requiring adherence to set coding standards and naming conventions. Besides being required by the Rails framework, these standards and conventions are generally good coding practices.

Conventions that relate to legacy schema integration with Oracle and Rails include the following:

• Tables are named in using the plural form of the model they represent. For example, an “employee” model maps to an “employees” table.
• All tables that contain data that will be updated contain a primary key called “id.”
• In the case of Oracle Database, this primary key is incremented using a sequence with a name based on the table it increments. A table named “employees” that contains an “id” will be incremented by a sequence named “employee_seq.”

There are many ways to proceed with creating Rails applications that run against legacy schema. Some of the techniques involve the use of Rails features; others involve the modification of underlying database objects. Rather than attempt to describe every possible way to proceed, the demo Web application is an attempt to leverage the power of both Oracle and Rails in such a way as to provide a reasonable solution that is clear, quickly developed, and easily maintained.

The Rails community characterizes the Ruby on Rails framework as “opinionated.” This term is intended as a positive description, indicating that the design of the software promotes adherence to standards and practices. However, such a goal raises the concern that the framework will limit or constrain application development. Our application includes the implementation of a few requirements that illustrate the flexibility of the framework.

The Ruby on Rails framework provides the tools needed to rapidly construct a Web application on a new or a legacy database schema. Consider the output of rake (a Ruby build utility), which provides some idea of the effort involved in creating this project:

C:\hr_rails\hr>rake stats
(in E:/ruby_apps/hr_rails/hr)
+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers              |    15 |    14 |       0 |       0 |   0 |     0 |
| Controllers          |   243 |   193 |       7 |      35 |   5 |     3 |
| Components           |     0 |     0 |       0 |       0 |   0 |     0 |
|   Functional tests   |   440 |   315 |      10 |      50 |   5 |     4 |
| Models               |   177 |   149 |       6 |       5 |   0 |    27 |
|   Unit tests         |    50 |    35 |       5 |       5 |   1 |     5 |
| Libraries            |     0 |     0 |       0 |       0 |   0 |     0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |   925 |   706 |      28 |      95 |   3 |     5 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 356     Test LOC: 350     Code to Test Ratio: 1:1.0

Fewer than 30 classes and 400 lines of code were required to develop this application!

Installing and Running the Web Application

Installation of Oracle Database XE, Ruby, Rails, and the OCI8 packages are prerequisites for installing this application. Because describing each process would require a series of articles. I will simply refer you to installation resources:

• Installing Oracle Database XE
• Installing Ruby and Rails
• Installing OCI8 (“PHP OCI8 Extension” section)

After installing these items, download and unzip the hr_rails.zip file, which contains all the code resources associated with this article. The extracted files have the following directory structure shown to the right (Figure 1).

Figure 1: Directory Structure

The directory structure is worth noting as it is a standard structure for all Rails applications. The name of the application (hr, in this case) appears as the root directory. The models, views, and controllers directories within the app directory contain the bulk of the application code. The config directory contains the database.yml file (used to configure database connections) and the routes.rb file (used to define the page that will serve as the index to the application). The public folder contains directories with Web resources, including scripts, images, and stylesheets. Although it’s not discussed in this article, a test directory contains resources related to unit-testing the application.

With the software installed, the schema created, and the Rails application configured, the application is ready to run. From the hr directory, run:

ruby script\server

This command stars WEBBrick, a Ruby Web Server that is included with the installation. In a Web browser, enter the URL of the Web application that will be running on port 3000—for instance, http://localhost:3000.

Sample pages as they appear in the application are listed below:

Figure 2: Main Page

Figure 3: Regional Compensation Report

Figure 4: Employee Listing

Figure 5: Employee Edit

Next, let’s take a look at database and schema configuration for the application.

Database and HR Schema Configuration

The SQL*Plus Client (or Oracle Instant Client Software) must be installed on the server where Rails is installed. A TNSNAMES.ora entry referencing the database containing the HR schema to be used must be created. For those new to Oracle, the TNSNAMES.ora file contains the connection information used to connect to an oracle database. The database could be on the same machine or on a remote server. Connection information includes the server name, database name and database port in use. This information is used by the Ruby OCI8 package to allow Rails to communicate with the database. The OCI8 layer is a layer written in Ruby that utilizes the underlying Oracle database configuration (specified in TNSNAMES.ora) to make the database connection.

To create the schema objects required by the Web application, perform the following tasks first:

• Create a new user (designated as HR_RAILS here) Note: The included script will drop the user if it exists and recreate it.
• Grant the new user the appropriate resources and privileges to create its own schema and access the HR schema.
• Modify HR schema in a few areas:
  • Create sequences to populate primary keys.
  • One trigger needs to be modified and another created. The triggers are required due to the job_history table and related constraints. The modified trigger checks to determine if an employee’s job_id or department_id has changed before inserting a history record. The new trigger deletes an employee’s job history record if the employee is deleted. The trigger could be modified to archive this data if required.
• Create synonyms as well as views for the HR_RAILS schema that adhere to Rails naming conventions.

To accomplish these tasks, run the create_rails_db_user_and_privs.sql script and answer the prompts appropriately. For example:

C:\hr_rails\hr>sqlplus /nolog
SQL*Plus: Release 10.1.0.2.0 - Production on Wed Mar 8 12:31:01 2006
Copyright (c) 1982, 2004, Oracle.  All rights reserved.
SQL> @create_rails_db_user_and_privs
Enter the DBA user:
system
Enter the DBA password:
notmanager
Enter the Database Name ( Oracle SID):
xe
Enter the (new) rails user (user will be DROPPED and created):
hr_rails
Enter the rails user's password:
hr_rails
Enter the HR user (to grant the rails user privs):
hr
Enter the HR user's password:
hr
Connected.
.
.
.

A number of commands will be run and objects created. Review the results in the create_db_objects.log file, which is created in your working directory.

Integration and Application Databases. Object-oriented programming expert Martin Fowler makes a useful distinction between application and integration databases. In general terms, an application database is a database that is used by a single application, while an integration database is accessed and utilized by a number of applications. Rails development is oriented toward the development of applications using an application database. The current project shows an approach to utilizing Rails with an integration database.

In this application, rather than directly accessing the schema using the HR user, a new user is created (identified as hr_rails in this article). Having a unique user dedicated to the Rails application provides visibility to the DBA who needs to differentiate between the applications accessing the database schema in question. In addition, Rails encourages the use of table and column names that conform to standard naming conventions. The new schema will contain views that correspond to the underlying HR tables. These views are inherently updatable rather than query-only and so are used for all insert, update, and delete operations as well. In essence, the implementation strives to create an application database schema that is somewhat independent of the integration database schema (to use Fowler’s terminology).

The use of Oracle’s “Inherently Updatable” views provides a useful interface for taking advantage of ActiveRecord’s object-relational capabilities. Again, these views serve to format the table structure and data in a form that is most useful for Rails access. They also isolate the rails application so that there is increased auditing visibility for the Rails database user and other application users that access the HR schema. All the power of Oracle SQL, including Oracle’s extensions to the language and functions, can be leveraged using find_by_sql.

For reference within the application, a portion of an Entity Relationship Diagram can be found as an image on the About This Site page. There is also a link from this page (as well as from the main page) to a page that queries the Oracle Data Dictionary to display the view names along with column names and types.

Changes to the HR Schema

Although the HR schema remains fundamentally unchanged, the application did require some adjustments. I added several sequences that Rails uses to populate primary keys of tables. Sequences of this kind might need to be accessed by other applications and so are included in the HR schema itself.

I modified one trigger that already exists in the HR schema (UPDATE_JOB_HISTORY) to call the add_job_history procedure only if the job or department associated with the employee changes. I made this change to limit the situations when this trigger is called to fields that are actually related to the emplyee’s job history. I added a second trigger (DELETE_JOB_HISTORY) that deletes the employee’s job history records when an employee is deleted. This trigger is required to allow the employee to be deleted because of the way the database constraints are set up. For example, in a production application, the JOB_HISTORY might be archived, or an Employee record might have the status “inactive.”

Development Process

A general outline of the development process used to create the sample application is as follows:

• Create and update the HR schema.
• Create the HR_RAILS user, schema, and database objects.
• Create a Rails application by running the following command:

  rails hr

• Configure the database.yml file so that the development, test, and production connections would connect to the correct database with a valid username and password. The database.yml file included with the application download (found in the \hr\config directory) references a database called XE accessed by the HR_RAILS user using HR_RAILS for the password. These values need to be modified to values that you used when creating the schema. This file is used by the Ruby ActiveRecord class to make database connections.
• Generate “scaffolds” for the tables. These scaffolds—Ruby models, views, and controllers—provide the ability to view, create, update, and delete records on the underlying tables. These scaffolds were created by running scripts that had been created as part of the Rails application.

  ruby script\generate scaffold <name>

• Create a layout for the site. This provides the header, navigations on the left, and the footer portions that you see on each page of the site.
• Modify the routes.rb configuration so that the first page of the site was mapped (rather than having to enter an extended URL).
• Perform multiple iterations involving modifications of models (if additional data is needed), views (trying to make the interface user-friendly and functional), and controllers (to get data to the views). This is the actual manual coding that was completed to change the style of the site and create functionality specific to the application at hand.

Scaffolds. During the development process, a complete Model, View, and Controller for each table was generated. Although the full scaffold was generated for all of the models in use, the final version does not include the full functionality available. A user can view only Region and Country listings. Location, Department, and Employee listings can be viewed as well as inserted, updated, and deleted.

Models. There are similar features to each of the Model classes. Representative examples are presented below. You can consult the code to see the others in detail.

Input Field Validation. The Rails framework seeks to centralize validation code in the Model class. There are a number of benefits to this approach, most notably the fact that all insert and update processing that utilizes the Model class will include the constraints defined and will return a consistent message to the user should the validation rule fail. However, the database itself can (and should) also be used to constrain data. This has the advantage of restricting the data entered into the table by any application or SQL statement. In addition, the View layer can be used to enforce validation by its very design. A well designed GUI will restrict the user in such a way that will prevent him from choosing invalid options. A text field with a set length will prevent strings that exceed the maximum allowable length. A drop down box will prevent a user from entering unacceptable entries in a field that is required to contain foreign key entries.

Employee Model validation ensures that the required fields are included, string data fields do not exceed the maximum length, e-mails are unique, and salaries are numeric. (The views implicitly validate the departments and managers by forcing the user to select data from a drop-down).

validates_presence_of :email, :hire_date, :last_name, :first_name, :phone_number, :salary
validates_uniqueness_of :email
validates_length_of :first_name, :maximum => 20
validates_length_of :last_name, :maximum => 25
validates_length_of :email, :maximum => 25
validates_length_of :phone_number, :maximum => 20
validates_numericality_of :salary,  nly_integer => true

In addition, there is custom validation code in the Employee model to ensure that the salary and commission are set within a valid range:

def validate
     if salary != nil
	  if salary < 1
		  errors.add(:salary, "must be positive.")
	  end

	  if salary > 999999
		  errors.add(:salary,"must be less than 999999")
	  end
     end

     if commission !=nil
	  unless commission >= 0 && commission < 1
			  errors.add(:commission, "must be greater than 0 and less than 1.")
	  end
     end
end

Queries. There is no SQL visible in the code related to the INSERT, UPDATE, DELETE, and SELECT * queries that are used by each of the Model classes.This code is generated behind the scenes. However, a common characteristic of legacy schemas is the requirement of complex SQL to retrieve or summarize data. Rails provides a means to execute complex SQL statements by defining a find_by_sql function in the Model class.

The query to construct the corporate hierarchy is as follows:

SELECT tree.*,
	   LEAD (hierarchy_level) OVER (ORDER BY seq) next_level
FROM (
	 SELECT CONNECT_BY_ROOT last_name top_node_name,
	 		(last_name || ', ' || first_name ||' ('||job_title||')') employee_name,
			emp.id employee_id,
			SYS_CONNECT_BY_PATH (last_name, '->') node_path,
			LEVEL hierarchy_level,
			ROWNUM seq
	 FROM(
	 	 SELECT e.*, j.job_title
		 FROM employees e, jobs j
		 WHERE e.job_id = j.id
		 ) emp
	 START WITH emp.job_title= 'President'
	 CONNECT BY PRIOR emp.id = manager_id
	 ORDER SIBLINGS BY emp.id
	 ) tree
ORDER BY seq

This code is an example hierarchical query created using Oracle SQL extensions. It is used to return data in a structure that produces the corporate hierarchy example. The page that displays the results includes JavaScript that allows the user to “drill down” through the hierarchy. The LEAD analytic function allows access to more than one row without having to use a self-join. The current row in the result set can effectively “look ahead” to the hierarchy level in the next row, which greatly simplifies the JavaScript code used to display the hierarchy.

Figure 6

A number of relationships are defined in relation to the Employee model. An employee belongs to a department and reports to a manager. At the database level, foreign key constraints exist that reflect these relationships. The Rails framework also specifies that these relationships are one-to-many. Manager is a field within the Employees table itself.

belongs_to :department
belongs_to 	:manager,
		:class_name => "Employee",
		:foreign_key => "manager_id"
belongs_to :job
has_many :department
has_many :managed_employee,
	     :class_name => "Employee",
	     :foreign_key => "manager_id"

These relationships set up a number of convenience methods that allow the programmer easy access to related data through the model objects.

Controller. There are relatively few modifications to the generated controller objects. The main controller has methods added for the main and about views. The employee view includes a couple of additional calls to models used to populate manager and department drop-downs. The remaining code is simply a portion of the automatically generated scaffold.

The config\routes.rb file was modified so that http://localhost:3000 maps to the main page for the application.

View. All of the pages in the site have a common header, left navigation bar, and footer. These are consolidated into a single layout file. By default, Rails looks for a layout called <controller_name>_layout.<xml or rhtml> in the /app/views/layout directory. However if you create a layout called application in the layouts directory, it will be used by controllers that do not have a layout based on the controller name.

The views take advantage of a number of Rails classes designed to minimize the amount of code that appears in a view. The numeric data was formatted as currency using the number_to_currency helper or the number_with_precision helper.

Rails also includes some JavaScript libraries that provide a number of services related to AJAX support and DOM manipulation. Although these are not used extensively, there are visual effects that are used to make the images on most of the pages disappear if they are clicked. A few additional JavaScript functions are included, which allow the mouseover button effects and the corporate hierarchy drill-down.

Advanced Oracle Functionality

The sample application takes advantage of the Rails ability to automatically generate the trivial SQL statements that are required to insert, update, and delete by primary key as well as to select * from a table. However, several queries that use Oracle SQL are included as well. The region.rb model contains SQL used to create the regional compensation report (GROUP BY ROLLUP) as well as the schema report that lists the views that the application uses (LAG OVER). The employee.rb model includes the query used to construct the corporate hierarchy. This query uses CONNECT BY to perform a recursive search as well as LEAD OVER.

Conclusion

HR will continue to provide a popular schema for the demonstration of SQL functionality. As demonstrated with this application, tt also serves as an example of how Ruby on Rails can be used to create Web applications that utilize legacy schemas.

source: http://www.oracle.com/technology/pub/articles/saternos-rails.html