BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

 
 

What is EnterpriseDB?

Oracle Tips by Burleson Consulting
 

I first discovered EnterpriseDB in May 2005.  It was in beta when I read a description of it in an on-line news article.  I decided to download the database and give it a test run.  I wrote about that experience on my blog.

I will give you some highlights here but you can use Google and read the whole article if you'd like to:

         Type the following string into the Google search engine to find more information:          enterprisedb my first look lewisc

The very first thing I noticed was that EnterpriseDB did not support packages.  As a long time Oracle developer, everything I code is encapsulated in packages.  It is just good programming practice.  Not having packages did not bode well.

After a little further research, I discovered that it also did not support user-defined functions.  I was kind of bummed out by that.  Not much in the way of compatibility as far as I could tell.

However, in this very early beta product they already supported PL/SQL style syntax, as opposed to PostgreSQL's PL/pgSQL syntax, provided excellent trigger support and, much to my surprise, DBMS_OUTPUT existed and worked like I expected.

I took a second look at it for Beta 2 in July 2005.   In this short time span, user defined functions became supported and ETL services and Replication were added.   That was a very positive sign for me.  Not only that they added the functionality that quickly but also that they were addressing the high priority issues first.

EnterpriseDB has continued to improve regularly.  The basics are all there.  Package support has been added. 

I want to make the point here that Oracle has been working on PL/SQL for 15 years or more.  EnterpriseDB is starting SPL from scratch.  They do get the benefit of an educated development community asking for the important stuff but it is all new coding for the database.  Eventually everything will be there but it does not happen overnight.

In some of my reviews of the product, I ran into issues with compatibility.  In one case, the documentation was not clear and in another I had a data type mismatch, kind of a PostgreSQL vs. Oracle way of looking at things.  Support was very helpful in clearing it up for me. 

Migrating trivial applications between major databases is no big deal for the most part.  In my professional career, though, I have worked on very few trivial applications.

My concern, and I think the concern of anyone thinking of migrating, is how compatible is it and what are my options when I hit something that does not compute? 

EnterpriseDB has been available for only a couple of years, and only one year of that was not as a beta product.  In that time it has added massive amounts of Oracle compatible functionality.  With the addition of packages in 2006, on top of the already existing SQL and PL/SQL syntax compatibility, my reservations about EnterpriseDB have been removed.  EnterpriseDB is already mostly compatible and that compatibility is getting stronger every day.

I cover migrating in great detail later so that will not be covered here.  In the second half of this book, I examine many of the differences between Oracle and EnterpriseDB, in addition to many of the compatible points.

One thing I did in several of my reviews was to check the effectiveness of support.  As I said above, I did hit a few issues.  I opened some bug reports on the EnterpriseDB online forum and got a very fast response.  The support technicians were all knowledgeable and seemed eager to get me up and running.

I can say for a fact, the people at EnterpriseDB are eager to get EnterpriseDB as compatible as possible as quickly as possible.  I even had a chance to exchange emails with Denis Lussier, the EnterpriseDB architect and co-founder, and even more surprising, I exchanged some emails with Andy Astor, the CEO and co-founder.  That is what I call support!

So let me answer my own question, "What is EnterpriseDB?"  EnterpriseDB is a company.  EnterpriseDB, the company, produces a database also called EnterpriseDB. 

EnterpriseDB is a contributor to open source.  EnterpriseDB develops software, employs open source developers, and funds PostgreSQL work.  EnterpriseDB also offers improvements they make back to the PostgreSQL community.

EnterpriseDB is a high performance, enterprise class, Oracle compatible database.  It provides Oracle compatible syntax for SQL and PL/SQL, and in the hopefully near future, your OCI applications as well.  This compatibility extends to PostgreSQL and ANSI syntax.

EnterpriseDB also provides an enterprise class platform for all of your applications.  EnterpriseDB provides replication, system management tools, cross-platform developer tools, and migration tools.

EnterpriseDB is built on the decades of development of PostgreSQL and its ancestors.  That gives it enterprise class reliability and scalability. 

EnterpriseDB takes advantage of the extensive Oracle client and Oracle developer communities to assign the priorities to its roadmap.  EnterpriseDB is incorporating the enhancements and features that real-world customers want and need.

What EnterpriseDB is not may be more important.  It is NOT an Oracle clone.  The architecture is different as it is the PostgreSQL architecture with enhancements, the implementation of data types and operators is different, the object implementation is different, and the way you would partition a table is different.  However, the code syntax and the over all development environment is COMPATIBLE.  That is the key word.  The road to get there may not be the same but it is the same destination.

EnterpriseDB does not support 100% of everything Oracle does.  That may be the goal but at this time it does not.  I have found that there are workarounds for almost any issue you may have.  Just as the compatibility has seemed to increase exponentially over the last couple of years, I expect that over time we will find fewer and fewer missing pieces.

EnterpriseDB is not open source.  It is based on Open Source.  You can buy the source but you cannot sell the source.

 

 

This is an excerpt from the book "EnterpriseDB: The Definitive Reference" by Rampant TechPress.


Expert Remote DBA

BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call
BC Remote DBA today.

 

 

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.



Hit Counter