Why Ingres Is the
Best Bet to Woo Oracle Users"> There are three aspects to migration: migrating the schema itself, migrating the data and migrating the application. Theres nothing in SQL Server thats not provided in Ingres. Theyre very comparable, [because] their origins are fairly similar. Obviously its the same for MySQL. Which is a subset of what other databases provide, anyway.And DB2?Absolutely not. And Shift2Ingres actually has provided basic capabilities for DB2 as part of their solution. Its not complete [yet,] so we didnt evaluate it. Theyre working to extend their solution to support DB2 also, which is obviously great news. The framework they put in place is fairly extensible and should accommodate other database migration. Between CAs prioritization of Oracle migration and EnterpriseDBs Oracle customization of PostgreSQL, it seems that Oracle is really No. 1 on the open-source hit list. We clearly see Oracle as being an area we could exploit, that perhaps none of the other open-source databases could. The assumed priorities or prize rewards were based on the complexity of solving the problemas we perceived it, at least. Oracle was most difficult, which is why we rewarded the biggest prize [for that migration tool]. What makes Ingres capable of exploiting Oracle in ways that other open-source databases cant? We obviously are very familiar with PostgreSQL: It has the same origins as Ingres. However, PostgreSQL has retained original architecture we put in place for both Ingres and PostgreSQL. There are some issues from a scalability and performance perspective. [PostgreSQL] uses an architecture that uses what we would call a processor per. For each connection to the database, it spawns an entire process for that connection. Thats a fairly big task that takes up a lot of resources and memory and so on. You can only scale that to a certain level and it becomes difficult to manage beyond that. The more modern approach is to use a threaded architecture. PostgreSQL and Ingres developed before any real threaded architectures were in place. It was a process-per model [architecture] before. We re-architected Ingres when threaded architecture came to be. It allows you to scale in a much more linear fashion. PostgreSQL has an inherent issue. [On top of that, EnterpriseDB CEO] Andy Astor is touting Oracle compatibility, but I dont believe PostgreSQL supports PL/SQL. I dont think EDB does. I know PostgreSQL doesnt. What theyve provided is compatibility at the schema and data-type level. Which has what kind of negative impact? Theres a set of standards developed around SQL that are controlled by ANSI and the European board. That defines the syntax of SQL and not how statements should be implemented or interpreted. What Oracle has done is expand that. The SQL layer, or what ANSI defines as SQL, is expandable, and almost all database companies have put extensions into SQL or added their own data types. Oracle built on a string-based database platform. Oracle has taken advantage of the fact that they store everything as strings and has built certain functions that allow them to do things fast because they do everything on the string level. The incompatibilities [are] of the syntax of statements, not in the execution of statements. What EDB has done is say OK, Oracle has defined a set of data types, and they just mimic those data types and SQL constructs. Its unlikely to be exactly the same as Oracle, but theyre interpreting things in the same way. Next Page: CA is lining up applications to run on Ingres.